well, we should distinguish a bit. Devs coming from web-frontends probably never used or even heard about the concept of streams, and it is causing troubles for them. on the other side, backend devs are used to shared state, threads and all the magic stuff around isolating concurrency in to more abstract models, i.E. actors, green threads, stm etc. many of them never used or heard about the concept of the single-threaded event loop. then, there are devs, which managed to not bother about threads, callbacks, etc, mostly because they used one "silver-bullet" framework, that hid every thing away from them. i guess they will have the hardest way to use or do node. ever wondered about questions like "how do i structure my project in express?"
i think node makes it easier to learn it's api by reducing itself to a few core modules. i think it's a nice good way how node exposes relatively low-leve api's in a relatively high level manner. but the thing with "let userland handle the rest" makes it harder to enter the eco-system. I don't think that we have real problems with nodes philosophy or it's api. the biggest problem is the entry path to it. RoR success is mainly related to the opinions it have in it. it leads the way. Express does it too, but it's way less opinionated. I do not know many mvc-frameworks on top of RoR, but there are several on top of express. here is it. there is no "userland" out there, that handles the rest. there is a "doersland". the node philosophy is for the "do"ers, and it offers too few to them who are "use"ers. i think it's worth to think about how to bridge the node-philosophy into the "use"ers-land, because the ideas of this philosophy still valid in userland as well. Am Sonntag, 28. April 2013 18:17:28 UTC+2 schrieb Isaac Schlueter: > > > I don't think that node will go mainstream by trying to convert > mainstream > > developers to the callbacks and streams paradigm, simply because it is > > too hard. > > This is a judgement that is not substantiated by any evidence whatsoever. > > The evidence suggests that most node users, beyond the initial > learning curve, have a pretty easy time with streams, events, and > callbacks. Compared to the learning curve of, say, Haskell or Clojure > or Erlang or even C (which are all pretty popular, and at least C is > as "mainstream" as it gets), it's a trivial hurdle. When users come > from the front-end, where these concepts have already been around for > ages in various forms, it's even less of a hurdle. While the > peculiarities of system internals and TCP are a bit new for many, of > course, Node's API is much easier to pick up quickly than any web > browser's. > > The evidence I'm referring to is the increasing rate of growth of our > module ecosystem, Node developer jobs being filled, and companies > using node in their products, vs the comparatively low rate of these > questions on the mailing list, irc, issues, and stackoverflow. > > It is a minority that has serious trouble with this, and they tend to > learn quickly, and never have trouble with it again. (As shown in > this case by this thread, where Slobodan grokked the answers quickly > and moved on while we all debated the best way to answer his question > :) > > Node is pretty obviously on the path to mainstream-ness, and patterns > that deviate from its minimal set are pretty fringe. (The least > fringe alternative control-flow pattern is Promises, by a long shot, > helped by the fact that it has considerable uptake in the front-end JS > world.) > > > On Sun, Apr 28, 2013 at 7:22 AM, Bruno Jouhier > <[email protected]<javascript:>> > wrote: > > Hi Nuno, > > > > Your post is helpful. I'll try to challenge it in a constructive way. I > > think that most of disagreement comes from a different perspective on > means > > and ends. > > > > From your perspective, node is an end in itself: you **do** node; you > build > > streams; you write callbacks; etc. For you, adherence to node's core > > philosophy is paramount. > > > > From my perspective, node is just a means to an end: we **use** node. > For > > us, the end is to more our product forwards. Node is just one piece of > the > > puzzle we are assembling (an important one). For us, node's core > philosophy > > is "interesting" but it is not binding. > > > > Our team is growing and when I'm bringing new people on board I'm not > > teaching them callbacks and streams; I'm teaching them streamline. This > is > > because I need them to get up to speed quickly and I also need to have a > > code base which is simple, robust, easy to maintain and homogeneous. > They > > can still learn callbacks and streams on their own and I'm encouraging > them > > to be curious but our internal coding standard is streamline. > > > > Also, I considered node's philosophy when architecting our new system. > But I > > have difficulties to fit what we are doing into the streams and pipes > > paradigm. It does not feel "natural" and I don't see what benefits I > would > > gain. For me, it is much more natural to architect our system as > classical > > modules that **consume** streams than as streams that would be piped > into > > each other. I find the pure asynchronous nature of node very appealing > but I > > find the streams & pipes philosophy less appealing. Maybe there is also > a > > question of maturity: the asynchronous APIs are something we can very > easily > > build upon today (in part thanks to streamline); the streams & pipes > looks > > more like an experiment in progress, which may turn out to be a real > > breakthrough but which would be introducing too much complexity for us > > today. > > > > I also have a different perspective on node's APIs. I followed the > > discussions on the new streams API and I was always amazed by the very > > strong focus on the "building streams" side. I find this very complex > and > > fragile. In our system, we very rarely build a stream but we consume a > lot > > of streams. So we have a small wrapper that gives us a very simple API > to > > consume streams. We are not following the core philosophy but it does > not > > really matter for us. What matters is that we can build our product. > > > > Now, when a person comes the the mailing list with a question, I wonder > what > > his perspective is. Does he want to **do** node, or is he just trying to > > **use** node to build something? If his goal is to **do** node, then > yes, > > Mikeal is right with his hard line: people should not blur the message > and > > give him advice that may distract him from node's philosophy. But what > if > > all he wants is to **use** node, maybe in ways that are not completely > > aligned with node's core philosophy, like we do? should we stick to the > hard > > line, or should we let him explore "other ways" that may be a better > answer > > to his needs. > > > > The node ecosystem is growing fast, with people that **do** node, and I > > don't want to disrupt this. But I feel that there is a great opportunity > for > > node to go more mainstream (like PHP and RoR). I don't think that node > will > > go mainstream by trying to convert mainstream developers to the > callbacks > > and streams paradigm, simply because it is too hard. I think that it can > do > > so by being open and letting people just **use** node, and this is where > > alternate tools may help. > > > > I don't have a good answer to what the line of conduct should be on the > > mailing list. But I don't think that excluding discordant voices is the > > right solution (in this specific case but also in general). > > > > Bruno. > > > > > > On Sunday, April 28, 2013 3:01:05 AM UTC+2, Nuno Job wrote: > >> > >> Node means a certain set of things, and part of those things are > callbacks > >> and streams. > >> > >> Callbacks and streams are hard to learn because its a new programming > >> paradigm you don't learn in school. It was hard for me too and I did it > when > >> this was still up for discussion. And I had good friends to teach me > that > >> really knew node. > >> > >> Developers will always try to fast track to their already understood > >> paradigms; but that is not node. This existing paradigm makes sense to > build > >> network proxies; which node is awesome for. To node programs are > proxies. > >> > >> A person should always start with callbacks and streams until he > >> understands them, closures, and the event loop. Then he can make > informed > >> decisions on what to use when. > >> > >> However node is not the solution to all problems and if you wanted to > >> build a general purpose replacement for Ruby on Rails in JS you > probably > >> wouldn't use callbacks and streams by something else as discussed. > >> Personally i think this would be great, an would follow closely such a > >> project. It could even interopt with node and npm but its not node! > >> > >> Given my opinions above it makes sense that i would advocate that a > node > >> beginner should start with the standard idioms: callbacks and streams. > It > >> might even make sense to make these documented as "the standard" on the > >> site. > >> > >> However its possible that this is not the best solution for the person > >> that asked the question, but then maybe that person shouldn't be using > node > >> and instead the brand new super cool thing someone will build. Or maybe > he > >> needs to learn how node works and then decide, by himself, that > something > >> else makes more sense. > >> > >> The ecosystem exists, it has an interoperability model, and works great > >> for what node is for (check node success). Improvements on this model > are > >> possible (like streams2) but even those aren't without backlash. > Breaking > >> changes are also awesome, but its not node > >> > >> Nuno > >> > >> Ps. Cause this doesn't seem obvious to everyone, these are just my > >> personal opinions. And I expressed them here mostly in respect to Bruno > who > >> did a blog post i thought was respectful and thoughtful, and i felt > >> compelled to respond in the same manner. We have a great community and > i > >> respect a lot the work and passion community members put into their > projects > >> > >> > > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
