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.
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.
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.
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.
Ryan Dahl has only spoken about implementation details and poor decisions made at the start that are too far along to correct now. He says Go is better than Node, not Javascript. If Javascript-as-a-server was a mistake then Ryan would not be working on Deno [0]. I just hope that the use of Py2 and having to stick with it doesn't bite them in the ass past 2020 [1].
With the caveat of my argument assuming "Typescript is a superset of Javascript."
I don't see (from that issue, this is the first I've heard of it) that they "have to stick with it". They're saying they won't try to move to python 3 until the V8 build does. Seems pretty reasonable to me.
>That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever.
E: To clarify on this a little since I'm not posting from a phone. Which means he's still using Javascript-as-a-server (Deno), so he obviously still has some faith in using Javascript-as-a-server.
Go > Node, in his opinion, but that says nothing about Go > Javascript.
Yep, that's true. However, JavaScript does it right out of the box and the JavaScript ecosystem is very well-aligned for async.
One of the most significant reasons to use a language like Node for server-side async programming is that for any random library you choose to use there's a very high probability the library also supports async and won't block on you. For better or for worse, async is pervasive in the JavaScript ecosystem. Even languages that have good async frameworks, like Python, most libraries will block as it's the normal I/O mode for the language.
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.
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.
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?
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.
Except what part is that? Having to download 4 or 5 projects to build, compile, and run 'basic' pages is too much bloat; not to mention the dependency hell.
It more and more seems to me like node was made 'because we can' instead of providing something. This can be seen with all of the cruft required; a lot made as an after-thought.
Package manager, npm; which itself has proven that... it wasn't designed too well. The reliance of it creates the cruft. Add in the fact that a web server shouldn't be event driven. I (personally) haven't seen any other language do an event-driven web; and I'd say, for good reason (callback hell.)
Javascript itself is okay because it's a requirement today for web pages to the average joe. However, if the Javascript foundation is merging; it'll their motto to use it (Node.)
I've used ruby, java, python, etc and all of them require a decent amount of dependencies to get a server up and running.
Likewise, dependency hell is an issue in lots of languages. The company I'm with has legacy dependency issues with their Java. They have pip dependency issues with Python. The front-end testers learned JS and left ruby simply because they couldn't get their tooling installed on another machine without a couple days work (turned out JS was easier to maintain and faster too). Yarn exists and solves the major issues NPM had (though they seem to be improving as well).
EventMachine or twisted are two event-based servers (ruby and python) with some level of popularity. The big issue with them is every library you reach for has blocking code everywhere, so actually making it work is painful. Promises eliminated callback hell years ago for most of us. Koa/generators eliminate most of the rest as well.
On the flip side, JS as a language is rapidly evolving and node is a serious consideration when adding new features. Node as an implementation is extremely fast and I doubt that there's another scripting language that comes anywhere close to its combination of performance, size, memory usage, startup time, etc.
Nonsense. JavaScript is a general programming language that's suitable for many different kinds of environments. It just so happens to have started in the browser, but it could just as easily be embedded like Lua, or ran on the server like Python, or be used for shell scripting like Perl, and even used in embedded devices like mruby.
Javascript's best feature is also its worst. The single-threaded event loop makes async programming incredibly simple (e.g. no race conditions), but it is also a limitation in performance. AFAIK node's worker/cluster solution is much slower than Go's solution for multiple threads...
That's not an inherent limitation of the language though. There's nothing stopping a server-side implementation from adding threads as a first-class feature and breaking away from the spec. Ideally it would do so in a way that's backwards compatible with libraries that assume they're on the same thread as themselves, but that isn't infeasible.
At that point, creating a new language is just as likely. I love Javascript, even though it gets tons of flak, but I do accept that Go is probably a better server solution for people who need performance as a top priority.
Honestly, I don't like JavaScript, but this isn't a terribly good argument against it. There are many things to criticize about the language itself and its ecosystem, but the fact that it started as a client-side language is not one of them.
I haven't done any big projects with it, but I did use it for making a Firefox extension to archive sites. My biggest issue with it was the unpredictable way it would handle syntax errors, and how things were handled wasn't documented anywhere that I could find, you just kind of had to figure it out and remember for later. For example, depending on the function, passing the wrong number of arguments could 1). Cause the script to silently terminate 2).Cause the script to terminate with an error message 3).Execute the invalid function without mentioning the error, then return garbled output 4). Emit an error, skip the invalid function, but continue trying to execute the rest of the script.
It was frustrating enough to turn me off using languages that don't have compile time type checking.
Passing the "wrong" number of arguments isn't a syntax error in JavaScript.
If you pass fewer arguments than declared parameters, the rest are implicitly undefined. The variations you were seeing probably just came down to how the invoked function handled that undefined value. I can still understand how inconsistency in behavior there might be confusing.
I don't use JavaScript very much, so keep that context in mind.
As far as JavaScript the language goes, my biggest complaints are to do with the sparse standard library (leftpad should be something easy to do with built-in string formatting functions[0], not a 3rd-party library), unexpected behaviour (the map/parseInt thing[1] being one example), etc.
The unexpected behaviour stuff is truly a case of needing to understand the language - after all, why should JavaScript behave like Python? However, as someone who doesn't use JS much, these bits of weirdness make it more difficult to use when I need to.
The fact that Array.prototype.map has different semantics from Python's map built-in, as most likely encountered by newcomers to JavaScript with the [...].map(parseInt) issue, is something that bit me once, maybe twice, before I adjusted to it - especially given that I'm more likely to use comprehensions than map in Python nowadays anyway. And the fact that the callback receives the index in JS is useful in far more situations than it causes problems, and it's certainly nicer than
>>> [ callback(v, i) for (i, v) in enumerate(arr) ]
JavaScript has been server-side since the start; both the Netscape Enterprise Server and IIS supported it mere months after it first shipped on the Netscape browser.
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.
49 comments
[ 3.5 ms ] story [ 106 ms ] threadOn top of all that, they've piled on bureaucracy and alienated many important long-time contributors: 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.
https://js.foundation/community/projects
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.
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.
With the caveat of my argument assuming "Typescript is a superset of Javascript."
[0] https://github.com/denoland/deno
[1] https://github.com/denoland/deno/issues/464#issuecomment-411...
>That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever.
E: To clarify on this a little since I'm not posting from a phone. Which means he's still using Javascript-as-a-server (Deno), so he obviously still has some faith in using Javascript-as-a-server.
Go > Node, in his opinion, but that says nothing about Go > Javascript.
http://tinyclouds.org/jsconf2018.pdf
> My problems with Node are almost entirely around
> how it manages user code.
> In contrast to the focus on evented I/O early on,
> the module system was essentially an afterthought
> With this in mind, I have long thought about how it
> could be done better....
I still don't see what it offers against .NET, Java, C++, OCaml, Haskell stacks, and their concurrency options.
The event loop and non-blocking I/O are inherent in JavaScript. The language lends itself very well to scalable server-side programming.
One of the most significant reasons to use a language like Node for server-side async programming is that for any random library you choose to use there's a very high probability the library also supports async and won't block on you. For better or for worse, async is pervasive in the JavaScript ecosystem. Even languages that have good async frameworks, like Python, most libraries will block as it's the normal I/O mode for the language.
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.
LWT is a thing.
As for being dynamic, my experience has shown that beyond prototyping, most dynamic languages don't scale with the teams.
You apparently never seen enterprise JavaScript, specially in projects with multiple consultancy companies being part of the mix.
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.
I recommend reading epoll(1) or kqueue(1).
http://docs.libuv.org/en/v1.x/design.html
Except what part is that? Having to download 4 or 5 projects to build, compile, and run 'basic' pages is too much bloat; not to mention the dependency hell.
It more and more seems to me like node was made 'because we can' instead of providing something. This can be seen with all of the cruft required; a lot made as an after-thought.
Package manager, npm; which itself has proven that... it wasn't designed too well. The reliance of it creates the cruft. Add in the fact that a web server shouldn't be event driven. I (personally) haven't seen any other language do an event-driven web; and I'd say, for good reason (callback hell.)
Javascript itself is okay because it's a requirement today for web pages to the average joe. However, if the Javascript foundation is merging; it'll their motto to use it (Node.)
Likewise, dependency hell is an issue in lots of languages. The company I'm with has legacy dependency issues with their Java. They have pip dependency issues with Python. The front-end testers learned JS and left ruby simply because they couldn't get their tooling installed on another machine without a couple days work (turned out JS was easier to maintain and faster too). Yarn exists and solves the major issues NPM had (though they seem to be improving as well).
EventMachine or twisted are two event-based servers (ruby and python) with some level of popularity. The big issue with them is every library you reach for has blocking code everywhere, so actually making it work is painful. Promises eliminated callback hell years ago for most of us. Koa/generators eliminate most of the rest as well.
On the flip side, JS as a language is rapidly evolving and node is a serious consideration when adding new features. Node as an implementation is extremely fast and I doubt that there's another scripting language that comes anywhere close to its combination of performance, size, memory usage, startup time, etc.
At that point, creating a new language is just as likely. I love Javascript, even though it gets tons of flak, but I do accept that Go is probably a better server solution for people who need performance as a top priority.
What are the main critiques of javascript? Genuinely curious, would like to hear from people that use or used it to build real projects.
It was frustrating enough to turn me off using languages that don't have compile time type checking.
If you pass fewer arguments than declared parameters, the rest are implicitly undefined. The variations you were seeing probably just came down to how the invoked function handled that undefined value. I can still understand how inconsistency in behavior there might be confusing.
As far as JavaScript the language goes, my biggest complaints are to do with the sparse standard library (leftpad should be something easy to do with built-in string formatting functions[0], not a 3rd-party library), unexpected behaviour (the map/parseInt thing[1] being one example), etc.
The unexpected behaviour stuff is truly a case of needing to understand the language - after all, why should JavaScript behave like Python? However, as someone who doesn't use JS much, these bits of weirdness make it more difficult to use when I need to.
[0] https://docs.python.org/2/library/stdtypes.html#str.rjust - this is a Python example, but why doesn't JS have this in its stdlib?
[1] https://wsvincent.com/javascript-parseint-map/