My experience (ROR, etc) is that large frameworks and plugin systems actually increase code rot and maintenance dramatically. Rails versions much faster than ruby, and even stable, community-seal-of-approval plugins that do basic things get left in the dust. For example, acts_as_authenticated and acts_as_attachment were de facto modules written by core ROR community members, and I was forced to haul them out and rewire several apps in order to continue basic maintenance and development when they got deprecated. In other words, the new stuff in these systems does not work with the old stuff, because the system itself has to evolve. Conversely, the php apps I've created out of libraries and my own code require almost no maintenance to continue upgrading, because there is no middle layer of code between me and the language constantly shifting around under me. Better than large systems are patterns and coding standards that are widely disseminated, to help ensure libraries can easily inter-op with each other. The event and stream API's (well, hopefully the stream api ;) ) are examples of these in node. I'm excited that npm will crack the discoverability problem, I think that would be a first for a package management system. But if various community institutions want to maintain lists of recommended modules, I don't see anything wrong with that, though I think node-core should avoid an "official" list.
Panyasan, out of curiosity, what is wrong with express and the various auth libraries, etc? All of the pieces you describe exist as libraries, how exactly does this not fit the bill of having generic pieces without being a monolithic system? Ted On Dec 15, 2012, at 4:44 PM, greelgorke <[email protected]> wrote: > 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 -- 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
