in fact we have allready several "stacks" for web development, which are
something like ou wish: the connect-stack including express and comatible
stuff like passport. flatiron is another one. there are even frameworks on
top of them preselecting stuff, like all the ror-clones: geddy, tower,
railways etc. all the stuff is allready there, with freedom and
preselection.
but as said before, node don't claim to be chimera making everything
possible. there are some classes of usecases where node just fits, and
classical web development is not that case. we dont even have this problem.
our problem is to know, which case is better solved by node, and then to
find the right modules.
i think that a thing like an application server is just one solution to the
problem: (1)how to find the right libraries, (2)integrate them and
(3)ensure they evolve and are maintained.
1: improve the search and combine it with ranking including usage
statistics, reputation and activity of the project. there is workinprogress
on it.
2: simplify apis, split them into smaller one, follow conventions and
patterns like callbacks and streams. in the end of the day we all depend on
core libs, so make them as smalles denominator in your api. and we do it
already.
3: this is the community thing, want to ensure maintanace and progress?
contribute and give the community something back! you can do it with
workforce or sponsoring. this is how node evolved. but for sure we need
more communication at creating of packages. too foten happens that two or
more libs arise only because the maintainers cant work together, because of
detail discussion.
Am Samstag, 15. Dezember 2012 22:36:41 UTC+1 schrieb panyasan:
>
> Hi Ben, hi everybody,
>
> while I appreciate all the answers including the critical ones, I think
> only Ben really understood what I was aiming at. Probably the term
> "application server" was not appropriate. I didn't ask for a big monolithic
> system. My claim was that web applications have a certain set of features
> in common (some of which are in the list in my post), which are really
> generic ("the boilerplate"). It makes absolutely no sense to implement them
> again and again, maintain them, write tests, etc. when they could really be
> bundled together and maintained by a community of people who need this
> functionality. If you're a professional, full-time developer, you're
> probably best of with creating this kind of stuff yourself. But my argument
> was that a lot of potential is lost because of the fragmentation ("the
> freedom to choose") in the node module ecosystem. Discovering modules is
> not the problem in my opinion - maintaining them in a longer-term
> perspective is....
>
>
>
>
> Am Samstag, 15. Dezember 2012 20:30:16 UTC+1 schrieb Ben Noordhuis:
>>
>> On Sat, Dec 15, 2012 at 7:52 PM, Mark Hahn <[email protected]> wrote:
>> > I'm sure many would appreciate such a comprehensive large framework.
>> > I and many others in the node community would not.
>> >
>> > One characteristic of the node "philosophy" is freedom. The freedom
>> > to plug existing small modules together like a lego set. The freedom
>> > to easily write our own modules. The freedom to swap out modules for
>> > others as better ones come along. The freedom to make our
>> > architecture unique while not writing code from scratch or even using
>> > boilerplate.
>> >
>> > If I had to live within the constraints of J2EE or ROR or even
>> > Express, I would find another job. My architecture migrates quickly
>> > from project to project with each one more awesome than the last. Any
>> > existing framework would be outdated within a year as far as I am
>> > concerned.
>> >
>> > It is a new world..
>>
>> A node.js "application server" is something Bert Belder and I have
>> been discussing.
>>
>> The proliferation (and wildly varying quality) of modules and
>> frameworks seems to be holding back node.js to some degree. I talk to
>> a lot of developers and it's one of the most common complaints:
>> "There's too much choice, we don't know what to use."
>>
>> The idea is to have a curated list of modules with appropriate
>> stability and support guarantees. If you find a bug, we'll make sure
>> it gets fixed in a timely manner; you won't be at the mercy of the
>> module author.
>>
>> That gives the developer a stable, known-good base to start out with
>> while preserving the freedom to use whatever he wants. It should also
>> take away the cold feet that some businesses have.
>>
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
