
Node.js Foundation and JavaScript Foundation Announce Intent to Merge - dankohn1
https://www.linuxfoundation.org/news/2018/10/node-js-foundation-and-js-foundation-announce-intent-to-create-joint-organization-to-support-the-broad-node-js-and-javascript-communities/
======
EB66
I'm not really happy to hear about this. To me, it demonstrates that the JS
Foundation continues to focus on the wrong priorities. They've thoroughly
neglected their stewardship responsibilities for a number of different open
source projects. They've seen a reduction in sponsorship/funding for
maintaining projects and they've pulled back from GSoC and other events that
were essential in drawing in new open source contributors.

On top of all that, they've piled on bureaucracy and alienated many important
long-time contributors:
[https://github.com/globalizejs/globalize/pull/703](https://github.com/globalizejs/globalize/pull/703)

Despite their slogan "The Center of Gravity in the Javascript Ecosystem",
these days, the JS Foundation is largely an irrelevant organization. I see
this merge as a last ditch effort to retain some sort of relevancy. They've
abandoned their roots as a center of innovation. I see no effort to pivot
their existing dying projects to compete in today's JS ecosystem dominated by
component-based SPA frameworks.

~~~
k__
Maybe the merge leads to Node people doing the stuff the non-Node people
didn't?

~~~
EB66
I hope so, but I think it's unlikely. The Node.js Foundation isn't in the
business of supporting open source contributions to existing projects.

------
monsieurbanana
It's the first time I heard of the Javascript Foundation. What's exactly it's
purpose? Founding the projects it hosts?

[https://js.foundation/community/projects](https://js.foundation/community/projects)

~~~
irrational
This was my thought. I've never heard of a JavaScript Foundation. What purpose
do they serve?

~~~
sitepodmatt
They will merge with padString and addNumber foundations. /Sarcasm aside I've
never heard of either and I've done an intolerable amount of node.js

------
danShumway
I am not sure how I feel about this.

I don't have strong opinions about either organization, but this feels like a
situation where diversity might be a strength. The JS ecosystem is really,
really big and I kind of like having stakeholders in it that are pursuing
different goals and that can go in different directions.

Fragmentation can be a weakness, but so can consolidation. And I can not
stress this enough -- the JS ecosystem is _massive_. There are so many
different parties that have interests that should be represented. Having
multiple foundations might be a more effective way to do that?

Or maybe I'm just worried over nothing, I dunno. It just feels a little weird.

------
TimTheTinker
The JS Foundation is already hosting a lot of popular projects that run in
back-end and build/CI environments -- webpack, ESLint, Esprima, Grunt, Intern,
JerryScript, Mocha, QUnit, NodeRed, webhint, WebDriverIO, etc. Adding Node.JS
itself to the mix would seem to make a lot of sense.

------
johnkpaul
For those who haven't heard of it, the JavaScript Foundation used to be called
the jQuery Foundation.

~~~
EB66
I'm no expert on the history, but I believe JS Foundation was the re-
launch/re-brand of the merging of the jQuery and Dojo Foundation.

~~~
johnkpaul
Hmm, I had thought that the jQuery/Dojo merge happened first but tbh I don't
remember the timing.

------
z3t4
Node.JS is a fast and simple server framework. Perfect for userspace level
applications, everything from simple chat apps to distributed services. It has
a lot of potentials. Not just as glue for front end frameworks.

------
talltimtom
Vote for Python in the browser 2020!

------
cremp
So basically, I just just stay far and away from anything javascript now; not
just node.js. Got it.

This can't end well anyway; javascript itself is a _client_ side language, and
node, using the same language, made it _server_ side.

That's been my whole gripe with Node in the first place, because you're taking
a tool (square,) and force-fitting it into a round hole.

~~~
nebulous1
node.js came into existence because it turned out that it was particularly apt
for server side programming, not because it was force fitted into it.

~~~
pjmlp
Actually it was more because it allowed JavaScript developers to do server
side programming.

I still don't see what it offers against .NET, Java, C++, OCaml, Haskell
stacks, and their concurrency options.

~~~
hajile
Ocaml has no concurrency options worth mentioning (need to look to PolyML/SML
or F# for that). Finding and teaching Haskell devs simply isn't feasible. C++
is way too low-level for most of the work that someone choosing node would be
doing.

It turns out that most of the reasons a server needs threads is IO. With node,
any IO is moved to a new thread, so you get most of the threading benefits,
but are completely safe (provided libuv is safe).

Another consideration is JS being dynamic. It's very easy to create extremely
flexible APIs and you can move very fast adding features without breaking
things. While That SML or F# app will provide much better type guarantees (and
somewhat better performance), those benefits simply don't pay off for a lot of
projects.

There's also something to be said for functional vs OOP styles. You will never
see a JS dev writing enterprise fizzbuzz. Even in very large projects, those
layers of boilerplate abstraction simply won't exist. Part of that is being
dynamic and part is being functional.

~~~
frutiger
> With node, any IO is moved to a new thread

Not quite (or somewhat): the IO is done asynchronously. You tell the kernel to
notify you when any of a set of FDs are ready for reading/writing, and it
resumes you when that is so.

~~~
hajile
My understanding is that libuv creates a threadpool that it uses for IO
operations and these inform the main thread when an IO event is ready. Is
there something wrong with my understanding?

~~~
spiralx
You're both right, although you more than the other guy being a dick. libuv
uses a thread pool for asynchronous I/O for everything _but_ network requests,
which are handled on the main thread - presumably because they're already
asynchronous by nature.

[http://docs.libuv.org/en/v1.x/design.html](http://docs.libuv.org/en/v1.x/design.html)

