
The Future of Programming in Node.js - Yakulu
https://groups.google.com/forum/#!topic/nodejs/9afurRCTlOc
======
gkoberger
Only tangentially related, but the "rant" by Ryan Dahl (node creator) when he
left Node day-to-day is worth a read:

[https://gist.github.com/cookrn/4015437](https://gist.github.com/cookrn/4015437)

~~~
grannyg00se
"The only thing that matters in software is the experience of the user."

Hell no. Software comes from software development. And software development is
a process. My editor, programming style, directory structures and other
personal organizational behaviours do matter. This is work we do, and while
the end user's experience may be identical regardless of very different
personal development style options, the one which gives me the most comfort
and work satisfaction is superior. So yes, I will configure my editor so that
I don't have to keep repeating the same keystrokes dozens of times throughout
the day. I will align things the way I see fit, and I will endeavour to study
and improve my skill with the language. Not only so that I'm more efficient,
but because it will bring increased contentment to the process of development.

~~~
coldtea
> _Hell no. Software comes from software development. And software development
> is a process. My editor, programming style, directory structures and other
> personal organizational behaviours do matter. This is work we do, and while
> the end user 's experience may be identical regardless of very different
> personal development style options, the one which gives me the most comfort
> and work satisfaction is superior._

Only nobody cares about you.

As in a restaurant, people care about the food, not the cook.

And even if you (and I) mattered, developers of a piece of software are N,
where users are 1000 _N or 100000000_ N. They matter massively more.

Oh, and there will always be programmers as long as there are money to be
made, so the "without me [in particular] there would be no software" argument
doesn't hold much either.

~~~
doktrin
> _As in a restaurant, people care about the food, not the cook._

The health inspectors care about both the food _and_ the cook, and the
latter's workflow is certainly scrutinized.

If we're going to beat this analogy to a bloody pulp, the health inspector in
software land would be technical debt and colleagues.

Not taking care of the process will bury the project, and the users with it.
Ryan Dahl's brilliant, but I don't think his entire statement should be
adhered to verbatim. It's solid guiding principle, nothing more.

~~~
itcmcgrath
No, the health inspector would be non-existing in most software shops.

What a different industry it would be if all software required independent
audits and the public could get access to the results.

~~~
doktrin
Colleagues are non existent in most software shops? I obviously didn't imply
there was some independent software inspection service.

I care about how code is written, because I'll have to work on it. My
employers care about how code is written, because our reputation is on the
line.

It's about solving problems, certainly, but workflows directly contribute to
solving problems better, faster and more reliably.

------
leetrout
> We are done making breaking changes at the Node.js layer. If your

> program runs today, we're doing everything we can to make sure that it

> will run next year, albeit faster and more reliably.

I've yet to devote any significant amount of time to developing on Node but
this is a big +1 for more serious consideration.

My memory is fuzzy (this was well over a year ago) but I remember building an
app in express and it being completely broken by updates a very short time
later (along with a good number of other modules that hadn't been updated
either).

Anyone venture out a guess/opinion on how many things in userland will
stabilize because of this? (Or perhaps things already have- I don't hear as
many complaints about express' api changing lately).

~~~
driverdan
Userland has become a lot more stable over the past year or two as projects
have matured. A lot of popular projects (like express) went through rewrites
with breaking changes.

~~~
SimHacker
Didn't UserLand make Frontier? (It's a Dave Winer joke -- ha ha!)

------
jchrisa
Node's module system is hands down the best module system I've worked with. I
wish other new languages would stop trying to innovate and instead just copy
what they've done.

~~~
nahname
Really? I think it is terrible when compared to other languages (C#, Java,
Ruby, Python, etc...). I have only done a few applications on node, but my
experience with including modules was painful to say the least.

~~~
carrja99
I'd have to say the biggest thing that npm has over module systems found in
java, ruby, python etc. is the complete isolation of transitive dependencies.
It is nice to use two dependencies and not waste a day or two because:

* module A depends on module C v1.0.2

* module B depends on module C v1.4.3

In all the languages you mentioned it becomes a pain because you can only use
one version of module C, meaning either module A or B simply will not work
until you find a way around it.

~~~
otterley
This is a cultural problem, not a module management problem _per se_. Blame
the author of module C, not the package management system.

Semantic versioning's raison d^etre is to prevent these sorts of issues.
Reusing a major version number is supposed to constitute a promise not to
remove or change the call signatures of any functions published by your
library. This is necessary so that a dependent library can declare a
dependency on version 1.x.x of your library when version 1.1.0 is released,
without having to worry that version 1.2.0 of your library will break things.

The problem is that too many library and module authors (who are otherwise
talented, or are simply the first provider of a useful library that ends up
gaining traction) refuse to follow the rules, and there's no effective
sanction in the OSS marketplace for this sort of antisocial behavior.

As soon as backward-incompatible change is introduced without bumping the
major version number, the dependent module author becomes paranoid (and being
closer to the user, he's going to wrongly get a disproportionate amount of
blame), and (rightly) feels he has no other option but to declare a strict
version dependency. And when there is more than one dependent module involved,
the misbehavior of the independent module author can cause a dependency graph
that is impossible to satisfy.

As far as I can tell, this whole situation started with Ruby, and is the main
reason (along with second-class documentation) why I am generally averse to
its ecosystem. rvm and its ilk shouldn't even have to exist.

~~~
dragonwriter
> Semantic versioning's raison d'être is to prevent these sorts of issues.

Semver may surface them by making it very clear (assuming all involved
libraries use semver) where they can occur, but, if you have a package
management/loading system that only allows one version of a particular package
to be loaded, obviously can't do anything to prevent the situation where
different dependencies rely on incompatible versions of the same underlying
library.

Sure, with semver it won't happen if A depends on C v.1.0.1 and B depends on C
v.1.4.3 (as A and B can both use C v.1.4.3), but it will still happen if A
depends on C v.1.0.1 and B depends on C v.2.0.0.)

To actually avoid the problem, you need to isolate dependencies so that they
aren't included globally but only into the package, namespace, source file, or
other scope where they are required.

------
asaarinen
I applaud the Node developers for their effort. While recent "competitors"
like Go are fascinating and in some ways even arguably better, the fact that
every device on earth runs JavaScript makes me bet that Node will prevail.

Computing will need to move fluently between the cloud and the terminal, and
JavaScript is the only language which allows you to use a single codebase for
both (in the foreseeable future). As developer time will stay the biggest
expense when developing software, I am bullish on Node and JavaScript.

~~~
tikhonj
These days virtually every language can be compiled to JavaScript in a very
usable manner. For example, I've had a lot of success with js_of_ocaml[1], not
really running into any of the problems people like to harp about regarding
compiled-to-JS languages.

[1]: ocsigen.org/js_of_ocaml/

The argument for developer time--as well as decreased maintenance cost--is
exactly why I went with OCaml over pure JavaScript. And so far it's certainly
paid off!

~~~
asaarinen
Sure, but the language that _every_ developer will need to know is JavaScript,
not OCaml or some other of the dozen alternatives that can be compiled to JS.

Besides, the ability to compile to JS is not enough; you will need to read it
in JS, debug it in JS and let other developers work on it in JS (because they
don't know OCaml).

~~~
ndesaulniers
Does _every_ C or C++ developer know the ISA they're targeting? Also, source
maps.

------
avolcano
> There will be no changes to the module system. None. It's finished. It's
> been finished for over a year. Any proposed changes must come with a clear
> reproducible bug that cannot be worked around or addressed with
> documentation.

This seems short-sighted, with ES6 modules now being used in production
(through transpilers) and slowly making its way into SpiderMonkey and, more
importantly, V8.

~~~
jlongster
It is a shame, but I just don't know how node would migrate to ES6 modules.
I'm sure someone smarter than me could think up of a plan, but it seems like a
huge amount of work. One of the strongest points about node is the amount of
small reusable libraries available. They aren't about to ditch that.

~~~
avolcano
Some thought has definitely been put into this problem:

[https://gist.github.com/domenic/4748675](https://gist.github.com/domenic/4748675)

[https://gist.github.com/wycats/51c96e3adcdb3a68cbc3#importin...](https://gist.github.com/wycats/51c96e3adcdb3a68cbc3#importing-
a-node-module-by-processing-requires)

(both of those are slightly out of date, syntax-wise, but are still
conceptually current, IIRC)

~~~
arxpoetica
Glad to hear it.

------
zekenie
This is the kind of open-source leadership that made me move from PHP to Node.
Node knows what it is.

~~~
SimHacker
At least we can trust the node developers not to check in untested code that
breaks crypt.

------
lelf
I hope that the future of Programming is not in Node.js

~~~
AndyKelley
You could make this comment useful and worth reading by explaining why.

~~~
CmonDev
I think that's obvious: forces you to stick with one specific legacy dynamic
weak-typed language.

------
jenius
> Synchronous child process execution is being added, at long last.

Thank the jesus. This will be nice to have, especially for some command line
and filesystem operations.

~~~
swang
Yes, best part since the node module we are currently using does not work in
v0.10 and the author is very adamant about not supporting it anymore.

------
kailuowang
> Callbacks will remain the de facto way to implement

> asynchrony. Generators and Promises are interesting and

> will remain a userland option. "

I am seeking for a comparable alternative to node (or something on top of
node) in which Promises are the de facto way to implement async. Any
suggestions?

~~~
halayli
Checkout C++11. It has lambda callbacks, promises/futures and async with
threading.

~~~
usea
I don't think C++11 is a comparable alternative to node, personally. Although
I understand that's a subjective judgment on my part.

~~~
CyruzDraxs
Have a look at node.native. It's just libuv and c++11, which behaves pretty
much the same as node. But much lighter, and with no Javascript engine tacked
on. Obviously not nearly as stable and supported, but it's an example of how
c++11 can work very similarly.

~~~
rmgraham
Or luvit (libuv + Lua)

------
_random_
"TypeScript and CoffeeScript will not be added to core." "As new language
features are added to V8, they'll make their way into Node."

Sigh... Let's leave this "future of programming" to the future then. I hope
someone needs it.

------
dpweb
Sound good on all those. Completely dropped PHP for Node, no regrets.. Good
because those breaking changes in Express v2-3 were annoying..

~~~
CyruzDraxs
That's what semantic versioning is for. Node modules should continue to move
forward, and reinvent themselves to improve how we write our apps. Otherwise
it'll just turn into another PHP.

------
mark242
I still, still, still don't understand why Node hasn't done in-line server-
side Javascript.

Give it a snazzy name. Maybe.. "Livewire".

[http://www.datacraft.com/livewire.html](http://www.datacraft.com/livewire.html)

~~~
jeffasinger
I think the reason for this is that the industry in general has moved more to
a MVC approach than this. No one wants to mix their server side code with HTML
anymore. In fact, more and more, people want to delay the rendering of HTML
until it hits the browser.

I don't think it would be very hard to to rewrite livewire as node module
though, if you were really interested in it.

------
callmeed
Can someone please explain Node.js's relationship with Joyent? I like what
I've seen/done with Node but I've had less-than-stellar experiences with
Joyent in the past. I'm hesitant to devote additional time to it if they are
very tightly coupled.

Is it similar to Go or Angular @ Google?

One thing I love about Rails is that it exists quite separately from 37signals
or any other company. I don't get that feeling with Node/Joyent, but maybe I'm
wrong.

~~~
IsaacSchlueter
Joyent owns the trademark and copyright on the IP related to Node.js. (Logo,
"Node.js" mark, etc.) They also are involved with marketing, legal, etc.

The active core committers over the last month, and their employers, in order
of whether or not they're me:

\- Isaac Z. Schlueter (npm author/admin, lead gatekeeper, stream maintainer,
javascripter), Joyent

\- Ben Noordhuis (issues list champion, most opinionated C++ developer, libuv
unix guy), StrongLoop

\- TJ Fontaine (build owner, C shim author, tracing afficianado, Master of
Robots), Joyent

\- Trevor Norris (performance perfectionist, master of dirty hacks), Mozilla

\- Fedor Indutny (russian ninja rockstar, TLS tamer), Voxer

Also very important to the project are Bert Belder (Windows guy, libuv co-
author) at StrongLoop, and Scott Blomquist (Windows bug-chaser, Microsoft
liason) at Microsoft.

Honorable Mention to Ryan Dahl (Node.js creator, BDFL) who is currently off
being a professional hipster somewhere in NYC, and not involved with the
project. When he did work on Node, he was paid by Joyent, and he got some
money for selling the copyright to the company as well.

The Node.js community experience would be much less pleasant if not for
Nodejitsu's continued support of the public npm registry. (Nodejitsu acquired
IrisCouch a few months ago.)

Node would continue on even if Joyent bit the dust. (Depending on who assumed
ownership of the mark, it may or may not have to change name/logo.)

If you've had a bad experience in the past with Joyent, it probably has
nothing to do with the experience you might have with Node.js. I am given free
reign here to manage the project free of any overt Joyent influence. Joyent is
a big Node user, and a lot of really smart people, so I do take it seriously
if they have something to say. Especially considering that most of the time
when Joyent engineers have a problem with Node, it's related to other users
hosted on their platform (Walmart, Voxer, etc.)

~~~
callmeed
Cool, thanks for the thorough reply.

------
pcunite
I'm new to web programming but I got the impression that C++ for web work was
silly ... use PHP, use Rails, use this, blah, blah, everyone said. Now it
seems that Node.js is just C++ style programming in JavaScript, expect that
you get "packages" that manage the HTTP headers (and other things of course)
for you.

It would be cool if someone makde a Node.C++. I would have less of a learning
curve.

~~~
oscargrouch
i hit "casablanca" the other day from microsoft.. what impress me is that is
open source and it also runs in linux. (not even in my wild dreams o would
predict this to happen one day)

anyway.. looking at the source its pretty decent, and go right to the point..
of course its focused in HTTP/REST..

theres a bultin IO scheduler and a concurrent task system.. from microsoft..
who would say so :)

~~~
pcunite
Wow ... thanks for the info!

------
DonGateley
My, god. Could they have possibly created any more or any more inscrutable
jargon? Must have had whole teams dedicated to doing just that. Keeps out the
riff raff I suppose.

------
camus
> This is not a democracy.

I agree 100%. But still, a lot of people are complaining about some of the
Node.js API choices.

They are complaining because it makes programming more difficult , and the
truth is , async programming is hard when it relies on callbacks.

~~~
hvs
Wasn't that the original selling point of Node? That it used callbacks for
async and that it was _easier_ that way?

~~~
jchrisa
I thought the original point was that it is JavaScript that can do stuff.

~~~
_greim_
As AndyKelley mentions, the point was it being async and event-driven by
default. JavaScript was chosen because it was the only language that was
simultaneously popular and free of sync baggage.

------
bfrog
So callbacks are annoying enough that they have to mention its a non-fixable
in the mailing list.

Awesome.

