JavaScript is Eating the World(dev.to)
dev.to
JavaScript is Eating the World
https://dev.to/anthonydelgado/javascript-is-eating-the-world
311 comments
We really need to stop putting Javascript on the back end when there are so many other great options that won't be any different to the front end in most (all?) cases. I think working on full fledged Javascript solutions for the front end that address load time and page size is great. It still amazes me why anyone would use Javascript on the back end willingly.
And here I am desperately looking for an alternative to Node.
Virtually contentless.
For anyone who's searching for more quantitative data, there's always the 2017 Stack Overflow Developer Survey [1] which seems to reflect that js (& node) are still growing.
[1] https://insights.stackoverflow.com/survey/2017
[1] https://insights.stackoverflow.com/survey/2017
The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.
Not sure I understand the usage attributed to Netflix? Sounds like the writer is saying that front end is node, but that can't be right?
Can someone who knows what they're using node for go into a little more detail?
Can someone who knows what they're using node for go into a little more detail?
What a depressing idea. I don't take JavaScript seriously at all.
Summary: "Javascript is eating the world because 5 huge companies use NodeJS"
Not sure I buy the argument.
Not sure I buy the argument.
The other day I managed to freeze my computer -- such that I did not even have access to the SysReq key, by stupidly running
I was an idiot, but at the same time, an unprivileged process should not be able to consume resources like that without a dæmon coming in and pausing/killing it. And the Javascript should not have been allowed to execute once I had closed the window.
Truly, Javascript is eating the world.
while (true) { var d = new Date; e.textContent = d.toLocaleString(); }
I was an idiot, but at the same time, an unprivileged process should not be able to consume resources like that without a dæmon coming in and pausing/killing it. And the Javascript should not have been allowed to execute once I had closed the window.
Truly, Javascript is eating the world.
Most of these examples aren't "moving off Java to Node" as the post tries to conclude, it's simply breaking out the view layer to "a right" tool for views. If anything, it's simply adding a supplement to existing systems.
In many large orgs devs still use a homogenous tool for the existing systems (e.g. my guess is at Netflix all new business logic services are still Java based to plug into the Spring+NetflixOSS stack).
In many large orgs devs still use a homogenous tool for the existing systems (e.g. my guess is at Netflix all new business logic services are still Java based to plug into the Spring+NetflixOSS stack).
JS has the appeal that it's something a lot of people already have good amounts of experience with. And ES2015+ features add to the learning curve, but also give some much needed aid to existing problems; it's easy to pick up on async/await when you already know how promises work.
Meanwhile, trying to find Go developers can be a challenge. And the learning curve is low, but there's plenty of low-level gotchas like dealing with concurrency and memory usage. (Yes, even in a garbage collected language, this manages to be a problem.)
In Node, you run into less issues because if you have a problem to solve you just npm install something.
That being said, my enthusiasm ends there. Every experience I have with trying to tie a database into Node has been horrible. Also, I think event loop based programming is missing the mark even if it beats out previous methods; I think Go and other CSP based languages like Erlang have the real right answer. I think if we really start seeing huge core counts, it will become apparent that a single thread event loop eventually starts to become a bottleneck. Also, NPM has an insane number of packages, but the quality is extremely variable - much more than PyPI, though I'm not saying everything on PyPI is magically production ready.
I guess what I'm saying is, maybe I should start learning Rust.
Meanwhile, trying to find Go developers can be a challenge. And the learning curve is low, but there's plenty of low-level gotchas like dealing with concurrency and memory usage. (Yes, even in a garbage collected language, this manages to be a problem.)
In Node, you run into less issues because if you have a problem to solve you just npm install something.
That being said, my enthusiasm ends there. Every experience I have with trying to tie a database into Node has been horrible. Also, I think event loop based programming is missing the mark even if it beats out previous methods; I think Go and other CSP based languages like Erlang have the real right answer. I think if we really start seeing huge core counts, it will become apparent that a single thread event loop eventually starts to become a bottleneck. Also, NPM has an insane number of packages, but the quality is extremely variable - much more than PyPI, though I'm not saying everything on PyPI is magically production ready.
I guess what I'm saying is, maybe I should start learning Rust.
ARG! The floating point handling in JS bites (bytes?) me almost daily. I code in JS every day but I hate this number "bug" the most. Having to frob back and forth with "int" to make it not totally broken.
Am I the only one?
Am I the only one?
What you build is infinitely more important than what you built it with. If someone writes a better Google the users won't care if it's using Javascript, Rust, or QBasic. They'd still be all over it.
JavaScript has eaten my time. It's a really frustrating ecosystem to work in, all the deps, toolchains, build process is extremely fragile.
I'm pushing everything to Python these days and some light front-end in JS where needed. Couldn't be happier!
I'm pushing everything to Python these days and some light front-end in JS where needed. Couldn't be happier!
What they don't say in this panegyric to node is that..
1. The language (js) is absolutely horrific.
2. node is single threaded and non-blocking/async in I/O for some operations but when blocking requires libuv and gymnastics.
3. It moves too fast for stability. I've encountered huge memory leaks with node at various versions that are terrible to debug.
4. It is designed to the lowest possible specification for development: web developers.
5. js package mgmt and build tools are a running joke.
We live in dark times.
npm and the huge number of dependencies scares me, I remember in WordPress plugins would get hijacked and you would get an update that backdoors or inserts some vulnerability, other than this, I spend 3-4 hours 2 days ago, trying to merge 2 json datasets by doing some averages, and simply could not do it, the numbers were in string format, and it would work for some and get NaN for other, or would just concatenate them as string, I was working in typescript and using "number" was concatenating, weirdest thing ever, I just gave up.
Node scales well in terms of performance. However does it scale well in terms of code complexity and readability?
I feel like it's less Javascript that's eating the world and more Node and NPM.
It seems as if it's impossible to publish a Javascript project without taking for granted that the developer has, or even wants, a package manager with dependencies, arbitrary toolchain and transpiler along with it.
Maybe I'm just a dinosaur for not wanting my "build process" for javascript to be more complicated than including a script tag. That's probably what it is.
It seems as if it's impossible to publish a Javascript project without taking for granted that the developer has, or even wants, a package manager with dependencies, arbitrary toolchain and transpiler along with it.
Maybe I'm just a dinosaur for not wanting my "build process" for javascript to be more complicated than including a script tag. That's probably what it is.
We should all speak JavaScript.
JavaScript you say? What a fresh opinion. I'm just like wow, the thought leadership of this post is defo palpable.
Maybe. Callback / promise hell in a language that needs a book like "Javascript the good parts" is probably not eating the world.
Yeah it is cool, npm package system is (was?) one of the easier ones to use. It is a good starter thing for someone who has only learn or done frontend development before. But I have not had a good experience with it on the backend.
Yeah it is cool, npm package system is (was?) one of the easier ones to use. It is a good starter thing for someone who has only learn or done frontend development before. But I have not had a good experience with it on the backend.
Reminds me of a 'future' talk about how JavaScript took over the world as a language even though no one actually programmed in. This was because as long as you could transpile to ASM, you could get native performance via JS.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
(Worth watching no matter what your background is, it's funny and informative)
https://www.destroyallsoftware.com/talks/the-birth-and-death...
(Worth watching no matter what your background is, it's funny and informative)
Certainly eating all my inodes, anyway.
The fact that JavaScript and the web platform kind of sucks while at the same time being "unavoidable" is why it's so good.
It forced a lot of very smart people and a lot of eyes onto the platform to try and find solutions within the extremely restrictive "box" to these problems.
How do you solve the API issues when you don't control the platform?
How do you solve for perf when things can't be installed?
How do you solve the API when you can't force people to upgrade?
How do you solve the language when you only have one language as a compilation target?
Out of these we got React and other vdom style view layers. FP paradigms got into the mainstream.
It exposed the mass to newer type system features
We got a toolchain that while complex, can do almost anything.
We got some test tooling that are ahead of other mainstream languages.
And every last bit of these went through tons of iterations (sure, javascript fatigue, whatever), and have had an immense amount of eyes on. You totally can look at any of the things I pointed out and say "Language X did it first!", but no one forced Language X on so many people, while JS was, so these things got a lot more exposure.
In short, I love the JS ecosystem precisely because it sucks so much.
It forced a lot of very smart people and a lot of eyes onto the platform to try and find solutions within the extremely restrictive "box" to these problems.
How do you solve the API issues when you don't control the platform?
How do you solve for perf when things can't be installed?
How do you solve the API when you can't force people to upgrade?
How do you solve the language when you only have one language as a compilation target?
Out of these we got React and other vdom style view layers. FP paradigms got into the mainstream.
It exposed the mass to newer type system features
We got a toolchain that while complex, can do almost anything.
We got some test tooling that are ahead of other mainstream languages.
And every last bit of these went through tons of iterations (sure, javascript fatigue, whatever), and have had an immense amount of eyes on. You totally can look at any of the things I pointed out and say "Language X did it first!", but no one forced Language X on so many people, while JS was, so these things got a lot more exposure.
In short, I love the JS ecosystem precisely because it sucks so much.
I think ES6 javascript is actually a decent language. But the way it's used is terrible. Slow transpilers that give all the disadvantages of a compiled language - but with the type safety of a dynamic language. Asynchronous code that is slightly better with promises and async/await, but horrifying to debug with stacktraces that are often completely useless. NPM with its plethora of low-quality packages - yet it's not uncommon for packages to have hundreds of dependencies. And when you try digging into those packages to understand what they do, because there's no documentation, you find a mess of javascript magic. Globals, nested closures, "coroutines" using yield and function references and a dozen magical libraries that are nearly impossible to untangle. I found the development experience to be slow and extraordinarily painful. I actually find PHP easier to work with (but more soul crushing to write.)
I would much rather use Go or C# or C++ or Java (well Kotlin, because I don't like to write Java) the development experience is just so, so much smoother.
I would much rather use Go or C# or C++ or Java (well Kotlin, because I don't like to write Java) the development experience is just so, so much smoother.
Using the same language on both the front-end and back-end is never a good idea. Java Applets, anyone?
It may sound appealing to management, but the front-end and back-end are different paradigms requiring different skills and language features.
It may sound appealing to management, but the front-end and back-end are different paradigms requiring different skills and language features.
1. It is relatively easy to comprehend and pick up and play around with.
2. With the advent of node.js, and later electron, it is incredibly relevant whether you're developing web apps, servers, or now, even desktop apps.
3. Some of the newer features, such as arrow functions actually make writing javascript a lot of fun!
JS has come a long way. I do think there are negatives to its popularity but I think it has also probably done wonders in terms of lowering the barrier of entry to get into programming. It's honestly a great language to start out with these days imo. It's easy enough to learn the basics (excusing the quirks of the language that do remain), easy to practice it developing whatever project you want to work on, and, even though it has problems of its own, node is a solid and, again, easy to use (I think it might be becoming clear what aspect here I think is key to JS popularity) tooling system for the language.
It still has its detractors, but all in all I'd say JS is pretty great.
Now, does that mean so many companies should jump to using it right away? No, of course not. But you can see why they are tempted. Because JS code is typically easy to use, comprehend, and manage, and because of its ubiquity it makes sense to use it so that as the composition of a team shifts and changes it's fairly easy to pass work along or pick up where someone else left off.