Its difficult to choose modules. - what's the best module - which one doesn't require maintenance yourself. - which one will have long term support.
I've found I had to simply write a lot of modules myself and stop using other peopes modules because they wern't stable enough or properly maintained. On Sat, Dec 15, 2012 at 10:54 PM, Ted Young <[email protected]> wrote: > 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 > -- 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
