> Discovering modules is not the problem in my opinion - maintaining them in a longer-term perspective is....
Discovery is a problem. You can't discovery modules which are actively maintained and have LTS On Sat, Dec 15, 2012 at 1:36 PM, panyasan <[email protected]> wrote: > 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 > -- 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
