JavaScript is Eating the World
dev.to
dev.to
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 like turtles.
It's hard to admire the work being put into javascript when you see the result every living minute of every day.
"Very smart people" are great at twisting and stretching and finding the most optimal possible solution within the restrictive box that you give them. But they're not always great at stepping back and asking bigger questions:
* Why was the box put there in the first place?
* Doesn't my solution defeat the point of the box?
* What are the alternatives to the box?
* Is it possible that I'm wasting tons of time and energy on a problem that would be trivial outside of the box?
Tl;dr -- pragmatism is why the web ecosystem is eating the world, not optimal design.
But even with that, wasm, service workers and other major changes don't come overnight. The rest of us still have a job to do.
Bonus points if it was a lisp or a 'hard' language because machismo alone would drive adoption overnight.
You don't, even when things can be installed. And that's where editors that eat half a gigabyte of memory to open a 6 MiB file come from.
I've never written anything on node.js, but that's the only argument that's ever given me pause.
Today, I do front-end React stuff as well as back-end servers with Node JS. I have been happy with it so far.
With some type-system like Flow or TypeScript, you can manage huge projects in Node JS.
I happen to like the community, CLI tools written in Node, and the plethora of open source libraries built on top of Node.
This also has a downside. Your libraries can get outdated quite fast, you would have to keep up with new language syntaxes etc., and remember which syntax is supported by which version of Node etc.
But so far, I think Node is headed in the right direction.
To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.
You can still make it work; but you can script a web page's interactions in C as well. That doesn't make it the right thing to do.
Should we collectively eschew what's possible due to individual language gripes?
I'm sorry, is this a dig at Ryan Dahl, or of JavaScript/Node developers in general? I'm having trouble understanding what point you're addressing with this comment.
As for evaluating languages for their "best purpose", I think that's a very complex discussion that doesn't necessarily yield a best (or cost effective/productive) result. And certainly, as we've seen routinely evidenced, using a different language on the server is no panacea.
To be clear: I said js is misplaced on the 'server' side and is a wart in general when applied in that context. Any educated comment on these sentiments?
Exactly what I asked.
> Any educated comment on these sentiments?
Without clarity on the sentiments themselves there's not a lot to elaborate on without simply fumbling in the dark. If the concern, though, is that, in Node, you live and die by an asynchronous event loop, I'd say that's not a small footgun. I don't think that's in dispute. I'd also say that the presence of footguns doesn't, by itself, disqualify a language from being used in any particular context.
As for JavaScript being a wart, I don't really agree with that sentiment. I think that's attributable to some pretty strong and level-headed language evolution making what was once a very blunt scripting instrument into something somewhat reasonably suited to larger-scale applications.
It is the poster child for the "If the only tool you have is a hammer..." maxim.
Its appeal derives almost completely from its presence in probably every major browser, where it was placed for DOM manipulation and was stressed way past its design envelope over time, leading to the increasingly dystopian web development landscape we progressively inhabit.
If it is ultimately victorious, it will be in spite of its design, not because of it. Those of us who are old enough to remember will cringe at the pain we endured over the years because of the widely used Intel 808x architecture as it evolved (small/medium/large/huge memory models, and segment registers, anyone?), not because it had the greatest merit, but because of its market penetration.
History repeats itself.
All things considered, a craftsman simply uses a tool to do a job. Often it doesn't involve much fanfare. I wouldn't say that modern JavaScript is quite as blunt an instrument as a hammer, but hey, if you're good with a hammer...
https://news.ycombinator.com/item?id=15090278
TL;DR: Writing JavaScript for the browser won't really help you write good JavaScript for the server.
As far as libraries are concerned, it was never my experience that the landscape changed drastically from one to the other. Most of the libraries I look at/use for the front-end today advertise themselves as both for Node and for the browser.
What do you mean? The fs module shipped with node is pretty much just a wrapper for libc. Hell, it even links to the open(2) manpage in the docs for usage information.
What's finally got me writing way more Javascript than I'd like to is React Native. It's by far the easiest way I know of to share code between iOS and Android, it papers over a lot of Android's irritating/broken UI bits (introducing others, but overall improving the situation), and you actually can share much of your code (practically everything but the UI layer) with a web client—and even... spits... Electron. RN's performance isn't even terrible, especially compared to cross-platform mobile frameworks that have come before it (and to Electron spits)
Hopefully Webassembly will save us in another couple years, and we'll be able to do the same thing in any of several much better languages.
[EDIT] though definitely keep your sanity and use Typescript. I'd have probably jumped off a bridge by now if I were having to do all this in actual JS, of any flavor.
Also, it 'helps' if both server and client are single-threaded, because then, you can use similar solutions on both server and client (even if they sometimes aren't the most pleasant approach for solving your domain)
I hope that Web Assembly will take of and get a decent interface to the DOM, allowing developers to pick other languages in the role that JavaScript now has.
As I mentioned PHP: In PHP each worker is single threaded, too, but you can scale by having more workers in isolation.
Some addition, subtraction is fine. But Array iteration, JSON encoding-decoding and similar CPU bound tasks could block the event loop.
You can perform them asynchronously, or forward the request to some remote service that's better at doing these computations for you and return results (maybe some service written in Python or a database)
Sure, JavaScript (and Ruby and Python) are usually fast enough with modern hardware - but we can't pretend there's no cost.
If my apps were that way, i could have replaced my team with 20 well-fed monkeys.
Does HN think putting 2-15KB JSON blobs in a Postgres DB running on Docker on a router is a good idea? Oh, and the table stores log data, so there's about 2 million rows after 5 days uptime. What do you think?
EDIT: This was not entirely related but it goes to the notion that it seems like a lot of myopic decision-making has somehow become even more acceptable and I would say this leads to dumb situations as above, and Node.
Making a full API on nginx via lua sounds crazy but it appears that people do it.
Things like getter/setters and object initializers. And don't even get me started on Web Workers, which basically seem to be dead on arrival. The Web Workers design is so shockingly bad and not fit for purpose that I don't understand how anyone signed off on it.
Some bits of the new js are in the right direction, and those are the things that people talk about and are getting used, but lots of things were definitely not.
Basically, if you write in Node JS, there's no concept of a thread. The thread API is not visible or accessible to the developer.
This forces you to think from the ground up about asynchronous operations that would take some time to complete - file opening, network requests etc., and have you group all tasks dependent on that time-consuming task, separately.
In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks.
Node JS has shown over the years that it scales well (maybe not as good as Go or Elixir, but enough for most use-cases).
Node also offers lot of great tools, that can be easily added to your project via NPM / Yarn. The Node ecosystem has a solution for virtually any task you might need to do repeatedly in a project.
Just to be clear, I am not saying Node or its ecosystem is perfect. There's always room for improvement.
What I am saying is that what appears as an obvious flaw, is not really a flaw. The language allows other approaches to solve the problem.
well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?
Backend and file systems, network and systems middleware do not need the abstraction model and overhead of a language designed to add dynamic content to fucking WEBPAGES because it can and it seems easy.
Well, file systems nobody writes in JS, so that's irrelevant.
As for "network and systems middleware" depending on what it does it can be a great fit for JS and especially Node, which is a lightweight logic layer on top of libuv.
'Lightweight logic layer on top of libuv': well if I can design, predicate and tout my language on 'event' orientation but then when it needs to do something else it becomes a thin logic layer over the hosts threading model: that's just a win!
That's not true on NUMA systems with multiple CPU sockets. You should have at least one thread per NUMA region for optimal results. Critical for example for running multiple 40 or 100 Gbit ethernet adapters.
Then again, you probably aren't going to run Node.js on those systems, at least not for handling heavy I/O.
the world doesn't revolve around making HTTP servers. Maybe you aren't writing apps that do parallelizable serial computations but please don't generalize.
This is exactly how backend Node.js development is done. The tradeoff is that processes are used instead of threads, which uses more memory but is magnitudes easier to work with than traditional threads where mutable bits of memory are shared.
Sure, Rust solves these problems but Node still has a place in the world: it is established, easy to pick up, and can share code with the browser. A decent solution to modern web development complexity.
However, I guess what made it appealing initially, was that it uses a syntax known to a lot of web developers. The callback pattern helped.
Although these days, we have been moving away to generators or async-await.
This is the key. And it reflects poorly on them for that. Syntax is the easiest part of a language to learn. The nuances of behavior is the hard part - and those nuances change as you move from the browser to the server; what makes good browser code will not make good server code.
In reality they shunned a ton of knowledge and community support to keep a particular (and particularly mediocre) syntax. Even today, years after Node has reached popularity and many lessons have been learned, developers with no experience outside the browser think they can write perfectly good server code, simply because they know the syntax. Never mind that all of the design patterns change. Never mind that the core libraries they use change. Never mind that they suddenly have to be cognizant of how much CPU time their code takes.
This is really true and it's sad, because it leads to more security problems on everyday software.
Node's success has everything to do with the environment itself in combination with the language. The node runtime, the associated stdlib, and most open source/3rd party modules have been written for a non-blocking runtime from day #1. The same stuff can be achieved in plenty of other languages/stacks (e.g. Python + Twisted), but you have much more work to do validating that every single library you use plays nice with async io, sometimes you have more event loop housekeeping responsibilities, etc...
Let's be honest: it is nothing to do with either of those and purely a matter of fashion. In a couple of years at most there will be a new new thing and everything will revert to version 0.1, keeping everyone busy but making no actual progress. Gotta soak up those CPU cycles the hardware people are giving us somehow right? Can't let the users get any of that speed for themselves!
Let's be honest: if you need "fashion" or "idiocy" etc to explain a trend in tech, you don't have an explanation.
Your explanation wouldn't even explain why it was Node+JS that got to be "in fashion" and not something else from the 20000 options.
That's the point. There is no explanation, other than the same reason that bellbottoms are in again this year. Or out, I don't actually know.
We pretend like we're "engineers" or "scientists" but there's nothing objective about what we do...
You mean you can't come up with one. Because for me, which followed the scene for 20+ years, there is a perfect explanation.
I had a homepage in 1994. I've seen them all come and go. This one's no different.
It’s as relevant as saying we don’t write apps in COBOL or Modula2 anymore.
I'm frustrated that better stuff doesn't win in the market as well, but I've been a web developer 20 years and Node's appeal was pretty obvious and exactly as the GP states. Without that it would not have gained traction to become fashionable.
The thing missing in developers that I have decried over and over in this devop/agile movement is that SAs had discipline and an ordered idea and that developers exist to perturb the norm to better effect. The two ideas are not readily reconcilable.
The real innovation that the Node environment and the Javascript language offered is one of marketing to developers who did not know better. Because there were no I/O paradigms in Javascript, one could be created to support this way of doing things, and there was no competing paradigm that people could point to in Javascript to say "Why would I do this when I could just use threads? It's not that hard."
With that out of the way, the floodgates opened, because once the first few people started adopting it because they did not understand threads, it was only a matter of time when "front end" people adopted it, because they did not know any languages other than Javascript. And thus, the current fad was born.
I sometimes think we could do with a bit more thanking-our-lucky-stars that the language that got entrenched on the web wasn't, say, VBScript (which IE did use to support).
For your major drawback, there's TypeScript.
dynamic typing, strong typing: python (for the most part), Scheme
dynamic typing, weak typing: Javascript, PHP
static typing, strong typing: Pascal, Ada, Java, C#
static typing, weak typing: C, Typescript, perhaps others
SPECIAL CASES:
strongly typed, dynamically typed, but with some compilers it can also be statically typed: Common Lisp
strongly typed, statically typed but can infer types: Haskell, ML family
strongly typed, can infer type with "auto" keyword: C++ (latest version)
non-typed: Machine language, assembler, perhaps Forth
If that's the primary language you are good at, from coding frontend apps, then it's pretty nice to be able to switch to writing backend code without having to do a language context switch. Muscle memory along with your memory about library methods all just continue to flow.
> It can't be that hard using a different language.
If I'm better at one language than another, it is at least somewhat harder. Why struggle when you can flow?
If you're better with screwdrivers, why struggle with a hammer?
JavaScript has a painfully slow runtime. Writing servers requires attention to performance and reliability, which javascript is very poor at. If you want to make a toy service and don't care about any of this, go ahead and use your favourite language. But when you want to make something incredibly fast and reliable (like nginx), you'll need to consider another technology.
Hammers and screwdrivers are not general purpose tools in the way that languages are.
For most things, most languages are just as fine.
It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is.
>JavaScript has a painfully slow runtime.
I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of tasks, and it totally obliterates Python, PHP, Ruby, and co in speed. And since some of the web's different properties are written in the latter 3, it's certainly not speed (which JS surpassed them far in) that's the issue.
>If you want to make a toy service and don't care about any of this, go ahead and use your favourite language. But when you want to make something incredibly fast and reliable (like nginx), you'll need to consider another technology.
Nobody writes "nginx" in JS.
They write the kind of APIs and apps and services that people also used to write in PHP, Python, Ruby, Go and whatever lang.
Uhh, what? You don't consider "programatically manipulate the DOM in the browser" to be a niche?
Whatever it was inveted to do is totally irrelevant, as the "browser API" is not Javascript the language/syntax but just an API (library/module).
In fact you could trivially implement it in all kinds of programming languages.
Anything it does related to that is just simple library code and methods on the "document", "element", etc objects -- and that's only when run in the browser where those are available (automatically "imported" let's say). Node doesn't even have the "document" object.
Any proof for this?
EDIT:
According to "The Computer Language Benchmarks Game"
JavaScript fares pretty well against Python [1] or Ruby [2] but not really that great against C [3] or Java [4] in the CPU intensive benchmarks.
1 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
2 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
3 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
4 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
Considering is a non-static, totally dynamic language, with all kinds of dynamicity in it, it does totally fine. 10x to 30x faster than Python, Ruby etc, and 3x to 5x slower than C/Java is totally fast.
JS JIT were already many times faster than PHP5. There's no comparison to the complexity, quality, resources and top-notch teams in play in JS JITs (just consider the vendors making them: Google, Apple, Microsoft and Mozilla) and PHP.
Not a great analogy. A more accurate analogy is switching from one very big toolbox to another very big toolbox. If you are used to one and know where all the tools are, and they have been used so much that the wood perfectly fits your hand, then it's just going to take some time to get used to the new toolbox. I'm not saying it's a hard rule and you should never consider another language. I just answered the question of why someone would want to use javascript on the backend. It's not the only factor, but it's a factor.
Imagine we have carpenters and brick layers. Two distinct jobs that maybe have some overlap of tools.
We decide that we have a lot more carpenters than brick layers, so we'll take a carpenters' toolbox and add a few brick layer inspired tools to it (but they're not necessarily the same, and some of the tools that can overlap maybe aren't quite as specialized, nuances, nuances, etc.).
Now, we can tell our managers that our problems are solved. All of our carpenters can now do masonry work.
The root problem of all of this mess is that both of these domains are different. Problems and solutions in the front-end tend to be different than in the back-end.
Management is sold on this "everyone is an interchangeable cog now" fantasy they have been chasing for decades and crappy decisions are made. We end up with most developers not really learning at least one of the areas of the full stack very well (and not learning both if they are really striving to under-achieve...).
Note: This same thing happened in Java before NodeJS, but in reverse. Back-end developers refused to really learn web development and so we ended up with misguided solutions like GWT and virtually every other high level Java web framework/library.
Perhaps I haven't run into the right people, but mostly my experience with other JavaScript devs is they don't even know the fundamentals really (they don't understand scope rules in JS, they don't really understand weak typing, they don't understand JS is single threaded, they don't understand closures very well, etc.). I don't know if this lack of understanding is due to a lack of experience programming at all, or just not really learning JavaScript (many non-JS devs are forced to learn enough JS to get the front-end working -- or at least seemingly working).
The thought of lowering the bar on development even further is frightening (Johnny did some web development last year, I'm sure he can transition to writing our back-end API since he knows JS). I'm all for anyone learning and improving as a developer -- and sharing in my passion. What I hate is this false confidence more and more people seem to have with everything and the problems it causes (they don't bother to learn the tools they have or the tools that came before them, they are too lazy to learn a new language/framework/library, and they have extreme NIH syndrome).
So, like Nginx's model? Or 99% of Python servers?
You can still run multiple processes...
https://nodejs.org/api/cluster.html
There are a lot of knowledgable people commenting, but it's starting to seem like they haven't familiarized themselves with the tools available within the NodeJs base.
To another point, I could put the time into writing a server and back end application in Go or Rust or C++ or whatever, but it would take (at least me) 10x as long to build out the application I need as it does to pull express into a project and build out a server, back end computations, file manipulation, authentication, and roll a MongoDB store with a fully-fleshed out front end (even if it's not so stylish).
Mind you I work in an enterprise environment where these kinds of things are required to serve maybe twenty people and run on a single multi-cored machine at any given time and not tens of thousands users.
It's a fantastic tool that works from small to mid-large projects, and would serve as an excellent prototyping and MVP-dev environment for even the naysayers who are probably more skilled than I am in other areas.
The problem with Node is it's unsuitable for a whole class of server applications - you're going to run into trouble whenever you need to maintain serial access to a single resource. Whereas in Java you'd have some sort of token that gets "taken" by different threads, there's no clean way to do this in a multiprocess Node environment.
The worst aspect of nodejs is code construction (craftsmanship).
Whereas Bill Joy said of Java "Allows you to think both In The Big and In the Small, at the same time." With nodejs, not only is there no Right Way, there's not even a Good Way. You have to mind all the details, plus quite of a few new ones.
Frankly, I'd rather just write 'C' again. If I have to care about the fiddly bits, I'd rather the language not fight back.
My team spends a lot of time mitigating memory leaks and back pressure (bufferbloat due to thread/task starvation). I haven't done this kind of troubleshooting since my 'C' slinging days.
And this is apparently acceptable.
I find the current state of affairs (emperor has no clothes) appalling and baffling.
Learn Elixir or Erlang and show that there's an alternative to Node.js that's both fun and powerful - and battle tested.
Like I said upthread, I used to dunk on JavaScript a lot, but it doesn't make sense nearly as much as it used to, to me.
>Single-threaded isn't a benefit
We aren't going to agree here, but you sounded like you thought your position was axiomatic or something, and that's what I disagree with. Meanwhile I am content that we may have different preferences, that's not a problem.
Can you describe a race condition that cannot be replicated on a single thread with either preemptive or cooperative multitasking/coroutines? I'm racking my brain and can't come up with one. If your coroutines are deterministically given time, then I guess you can avoid race conditions, but "are my coroutines deterministic" seems like a really difficult thing to conclusively prove in all cases (like, just add network I/O latency), and the conceptual barrier remains the same whether they're deterministic or not.
(Edit: a friend just noted the possibility of writing to memory/disk and reading halfway through, and if you don't have atomic writes that's true, but you can have preemptive, single-process multitasking that interrupts mid-write; that's why we have file system lockfiles, isn't it?)
I use node-async-locks when writing JavaScript sometimes if I have to deal with shared state, because, hey, I might have to await something and come back to this later. (Obviously I try not to, because duh, but sometimes you're stuck with it and can't immutable-all-the-things. So you define a critical section and do your thing.)
Use JavaScript.
We can say 'til we're blue in the face that that doesn't matter (and I do, as a Ruby/Grape guy for APIs), that matters. Lowered impedance mismatch is a thing. I use Ruby because I'm still more productive there--but that's a library problem (RDBMSes), not a language problem.
Node really is good-enough. I'd go for either a JVM or a BEAM-based solution if I was building things where there were significant and meaningful losses on the table if I fucked up, but for most things? Nah. Just...not important enough.
Instead, you'd rather the language be written with conscious land mines in it?
Like, I have a history of dunking on JavaScript. (Though, to be fair: ES6+ is better! It's a lot better. I kinda like it.) But C is unsafe as hell. The list of people who should be writing C is super short.
If you're running into memory links in Node, that points to bad native code or handles that are never getting removed. That's not something easier in C, unless you also like buying yourself double frees that you have to worry about. And backpressure is an architectural problem--it doesn't go away in another language, the ephemera of it just makes the problem surface in a different way.
Maybe what you're writing isn't appropriate for Node. Much of what I write isn't--if I start seeing buffers, I start reaching for another ecosystem, usually the JVM. But that's a far cry from a meaningful criticism of Node for what it's good at. Use what's good where it makes sense. Use other things where they make sense. Revisionism to have C make sense, in 2017, when we have modern, clean C++ and Rust both and Go if you really don't actually care about type systems, makes me really skeptical.
We have a handful of stupid simple http servers. We use express, redis, aws-sdk, pino, misc. Responses are mostly JSON.
The http-request module has given us the most fits. I question that any one has ever used it for more than toy problems.
The redis module is also an engineering marvel. I gave up trying to add a rate throttling shim. The goal is to limit the number of concurrent requests. Because when our app is under load, we're not processing redis responses fast enough, so redis server's outbound client buffers grow and will eventually OOM ABEND the server. So I wrote our own stupid simple redis thing using async.queue as a poor mans thread (task) pool. Trivial. Eg my REPL parser is 1/3rd the size of node-redis-parser. Works great. I keep thinking I must be missing something.
From my reading, hapi (successor to express) does an inbound backpressure thing. I'll be trying that out asap.
Much as I hate Spring, AOP, jedis, annotations, jaxrs, log4j... I've never had these kinds of nuts & bolts problems. Now I kinda miss the elephant gun approach.
PS- I can only assume the on drain event strategy was someone's idea of a practical joke. Maybe its a uvlib thing.
JS is the only language on the browser after Java and Flash were killed off.
Brendan Eich created JS.
Brendan Eich runs Mozilla.
No new browser language occurs unless the big players (including Mozilla support it)
Mozilla have killed all attempts to add new languages to the browser.
Q.E.D. - language monoculture due to one creator forcing his creation on everyone and denying anyone the chance of doing things differently.
At least Web Assembly offers some hope for a sane future where we can actually choose the right tool for the job rather than the only tool for the job.
Ran. Very briefly.
The language is non-blocking, so any asynchronous tasks (DB read/writes, disc I/O, cache, http, etc) will immediately jump to processing the next request the moment it is not doing blocking computation.
Non-blocking:
[aa][bb][cc][/aa][/cc][/bb][dd][ee][ff][gg][/dd][/ff][/gg][/ee]
[aa]------------------------[/aa][ff]----------------------[/ff]
[bb]------------------------[/bb][gg]----------------------[/gg]
[cc]------------------------[/cc][ee]----------------------[/ee]
[dd]------------------------[/dd]
And then on top of that, clustering module is used to do the same thing on every core.
You can have "non-blocking" and multiple threads at the same time.
The V8/JS thread and the C++ thread?
Doesn't the C++ part create threads in some cases when needed?
I would propose "person who can only be at most half-competent," except that is too wordy and probably too charitable.
This is ridiculous from the point of view any professional developer. I know that this is your point, and I'm just amplifying it. I (and many other professionals I work with) know - and use on a daily basis - so many more than 1 language that it's sincerely baffling to grok a world that promotes "One language fits all". That's without even considering the parlous state of npm and its libraries.
To me it seems that NodeJS solves a very specific problem; handling many simultaneous persistent network connections (i.e. websockets). I can't help thinking of NodeJS as fundamentally being a programmable socket server. I.e. its purpose is to solve a network problem, not a business logic problem.
The problem for me, when I work on large(r) apps that run in NodeJS, is that there is a certain "mental overhead" associated with it. NodeJS has this non-blocking IO, event driven architecture for a very specific reason which makes total sense when you solve IO problems (such as handling many simultaneous network connections) but this behaviour somehow seems to trickle down into business logic. With NodeJS I find myself writing non-blocking, event driven business logic because the environment in which my code runs dictates this. Somehow that doesn't make sense to me. To me business logic is inherently synchronous.
Now there are some really clever ways to compensate for this such as the Promise and with never versions of JavaScript there are even new language features to help battle what was originally known as the "callback soup". However, no matter how clever and admirable each of these features are, to me they seem to compensate for a fundamental problem in the run-time environment (NodeJS) that actually makes it not really suitable for anything CRUD and beyond.
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.
[1]: https://unpkg.com
When you write code in a team, you optimize for readability, maintainability etc. You spread your code over 5 directories, 50 subdirectories, 3000 files.
When you want to run this in a browser environment, it needs to be optimized for delivery - faster download, less time-to-be-interactive. You need to split your JS codebase as per routes in your app, and load chunks as per user demand.
Not just JS, you'd have to compile and inline your CSS, base-64 encode your images to data-urls, generate image stripes.
Before all these, you'd have to lint your code, and run unit tests on your code.
I fail to see how you can do all these with just a script tag. You need some sort of a compiler / transpiler; and a task runner that gives you a handy interface to these.
The package manager has no dependency, other than the Node runtime itself.
As for arbitrary toolchain, the metadata is codified with semantic versions in your package.json. You're one install step away from downloading all the necessary packages.
One thing I think lot of Node project misses, is to not add which Node version is to be used. It's not because it's impossible to do that - there are two well documented ways to do that (via .nvmrc and "engines" entry in package.json)
The fundamental issue is that the overwhelming majority of interactive websites today don't actually need to be interactive, and may even be better off as old-fashioned HTML pages served by the server.
But people love over-complicating stuff, and when the end result is complex the toolchain has to be complex too, not just for one person but the whole team. Then you end up with developers who spend more time wrestling with webpack et al than working on actual features.
Some of the incentives fueling this trend could be viewed as undesirable (e.g. monstrous ads on news sites as a desperate bid for profitability), but that doesn't negate the fact that the incentives exist, and aren't simply "people love over-complicating stuff".
To illustrate, hacker news and reddit work fine with javascript disabled, and the javascript they use is simple and just makes some interaction like voting work nicer. Even amazon, which is a pretty bulky and interaction-heavy site, works quite well with javascript disabled.
As for incentives vs over-complication, there's an interaction there. The incentives are to put some fancy whirly whingding on your website because it looks flashy and your target audience has (according to you) fast internet connections and web browsers. The incentives are to do this with the minimum of effort even if that means serving multiple-meg, javascript-heavy pages that don't even have any interaction.
Your solution to the JS ecosystem is to make news websites less interactive. I see why you long for simpler times but I don't see how that fixes things.
For those of us who are building applications we need the complexity. It solves problems that come from the fact that the web has evolved from a hypertext system to an application platform.
One of the trends I'm seeing is that a lot of developers once they have built one web site as a SPA they seem to start thinking everything should be built this way. More consideration should be given to deciding which is appropriate.
I'm not saying don't build applications. I'm saying web applications can be server-only and should not spill over into the client.
Again there are exceptions - things like control panels or consoles do benefit from being SPAs. But in a lot of cases there is also nothing wrong or insufficient or unsatisfactory (from a UX perspective) about clicking a link and having the server send you pre-rendered HTML. JavaScript can still be used as icing on the cake to enhance those interactions, such as by displaying a spinner on the submit button and disabling it once the user clicks it.
We need lots of tooling to keep our code readable across a zillion files.
And it is worse than you mention. You rarely get 60 files per directory, and, in addition to the files you want, your package manager and build system add a few zillion of their own that all can break your build in 'interesting' ways.
I used to prefer a 0-dependency, no-build format for sites. Nowadays if something doesn't have an npm module it's enough for me to not want to use it for a variety of reasons.
I used to install "dependencies" by copy and paste and was happy, but because I didn't know how it could be better. Despite all of npm's woes (which are many) the concept is sound, and not just for JavaScript.
To compile a Qt app you need: - the meta object compiler (moc) to add dynamic features to C++ for Qt use - the Resource Compiler (rcc) to embed icons or sounds as arrays in header files - the Qt Quick Compiler if you are using QML files for your interface - the C++ compiler, linker, etc.
This is either driven by CMake, qmake or your IDE!! I see you can use Qbs to generate the CMake or qmake files! I remember learning CMake, make, ant, etc being non-trivial!
Oh, and you were on your own when it comes to dependencies!
Of course, your point still stands. But's a tradeoff. C++/Qt has a ton of compile-time bloat, while Node/Electron has runtime bloat (see the Slack client using hundreds of megs of ram). And you can use bindings, like PyQt, where you have Python/Qt and then you get Python's dependency management.
Comparing C++ to Node or Python doesn't help me. If I could write Python that run in the browser I wouldn't be commenting here.
Just look at all the Node.js drama. Today I read they want to fork again, while they just consolidated their last fork...
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.
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.
"I had a problem. I started using regex and now I have two problems."
Becomes...
"I had a problem. I ran npm install and now I have 21,735 problems."
Think about that for a moment: one library, 40 versions downloaded and compiled to fill NPM dependencies. What if there was a vulnerability in a version of that library - how do I audit that? Can I even fix it myself without hosting my own NPM registry? Bandwidth? Computation costs (a thing again, with cloud computing)? Disk space costs?
It makes me glad we just use Docker; so I don't have to try and make sense of the NPM madness from day-to-day. Just Docker's own brand of madness.
NPM on Windows also had other problems such as Python path is wrong or C++ compiler is missing.
Then we switched to Yarn. Uncached install took about 2-3 minutes, and cached install would finish in seconds.
Recently, NPM 5 has been released, and it's been competing well against Yarn.
Also, Yarn's run command can be used to run locally installed NPM binaries, not just NPM scripts. i.e., you can do `yarn run -- webpack` and it will run the local copy of Webpack. This is handy imo, and as far as I know NPM doesn't do it.
I like Yarn run, because if I'm running a lint or tests, it errors out with error messages related to the specific process.
If you run via npm run, it would throw lot of extra error messages, making excuses that it wasn't NPM's fault the command exited with a non-zero status etc.; and hiding the relevant error messages.
And as always, you can just run a script as yarn script, instead of yarn run script; like yarn lint:src, instead of yarn run lint:src.
NPM does it only for a few common ones.
Also, Yarn run picks up right node version from .nvmrc - you don't have to run an nvm use and switch to it.
ES7 is okay, Node.js is good, V8 is GREAT, but NPM is an atrocity.
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).
I'm pushing everything to Python these days and some light front-end in JS where needed. Couldn't be happier!
While the benefits of moving any distance away from JS's weak-typing are certainly obvious, why stop at Python rather than a language which is both strongly and statically typed?
JavaScript tooling is notoriously complicated on the front-end, not the back-end. And I doubt they're saying that they switched to Python on the front-end.
The distinction was that cdnsteve was motivated to switch to Python due to issues with the toolchain and build system, not that JavaScript was weakly-typed.
> JavaScript tooling is notoriously complicated on the front-end, not the back-end. And I doubt they're saying that they switched to Python on the front-end.
You have a good point, though you still have to pull in dependencies and deal with NPM when running JS on the server-side (especially if the server is doing non-trivial stuff). Idk, maybe an approach with server-side rendering using Python did away with much of the JS usage which made things nicer.
And as for build tools, people like to complain way too much, maybe they prefer just using bash scripts instead..
... was the keyword, or at least that was how I read it.
Not sure I buy the argument.
That alone will effectively stop the world from migrating away from JS. More and more people will give NodeJS a whirl, confident at very least that JS isn't going anywhere for quite a long time.
It just creates a cycle where you're going to see very little slippage in JS usage and most of the time ever increasing usage. It won't be this way "forever" but we're probably a decade away from peak JS.
> Java still powers the backend of Netflix, but all the stuff that the user sees comes from Node. In addition to Node, Netflix is also using ReactJS in their stack.
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.
Or perhaps the language has nothing to do with your problem.
The implementations are what matter. They're the only thing that matters. It's the business axiom "Ideas are worthless, it's the implementation that counts" at work.
Ask yourself this: If V8's performance was still at 2010 levels, would Node exist?
And if some other language were the one which had been picked for browsers - JavaScript relegated to only running on servers - I wager JavaScript would hardly be used at all.
Language != compiler
Language != library
Language != SDK
That being said, JS sucks for large projects.
I had a similar experience on macOS with Chrome Canary watching a YouTube movie full screen. My laptop simply froze, nothing, except a restart, worked.
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.
I've got between 5 and 10 on my computer at least.
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.
It's not driving anything, we keep hacking it to make it bearable. I mean, come on, the most popular projects in JS are all projects to avoid writing JS in the first place.
I think it's a totally cool language because of it, but it definitely does not have that ease of use for any sufficiently complex application.
You want to have fun programming, use Lisp. (Which, BTW, invented "arrow" fns ... aka Lambda functions!)
0. You have to use it because it's the only thing in browsers, just like VBA is the "popular" choice for scripting a Microsoft Office application.
It may sound appealing to management, but the front-end and back-end are different paradigms requiring different skills and language features.
It is the opposite result that would be surprising.
Javascript isn't eating the world, it's just escaping from its multi-decade browser-only shackles and spreading its wings, which means JS is moving into some niches it previously had no access to. From 0, there's nowhere to go but up! If you're a primary-JS developer it may feel like suddenly the world is at your command, compared to where you could take your skills before. But it's not eating the world and it's not going to, because there aren't any niches anymore for it to conquer that aren't already colonized by other quite good competition. JS itself is nothing particularly fancy next to Python or Ruby. And there are a lot of very important niches that are simply unavailable to it.
If Javascript were something other than a fairly standard dynamic scripting language, it might find itself with some new opportunities. But it's not, and while it was locked in the browser, the other dynamic scripting languages pretty much took over everything that a dynamic scripting language can. I'm sure JS will develop parallels to some of that stuff, it already has, but it isn't going to be growing into uncontested space.
I just wanted to share this because I find it amusing til the moment that client went with another company that had "patent pending tech" and AI, it was sad because I knew the other company was just a couple of guys loading data.
I guess the lesson is that sometimes it's hard for people with a technical background to sell because we usually don't "hype" our tech.
Until your client is unable to find competent programmers to hire to do maintenance after you're gone because you chose to use something esoteric.
A big reason why there are so many JavaJobs™ is that there are so many programmers with Java listed on their résumé/CV.
Your client needs to look ahead and plan for the possibility of his/her entire dev team being poached on the same day.
Am I the only one?
Now that many shops have separate back-end and front-end focused teams, a lot of API development is moving to node so that the front-end focused JS developers can maintain the APIs they consume themselves.
Also, while languages like Java are very good at helping large teams manage equally large codebases, deploying microserves and organizing code into smaller-more self-contained pieces make it easier to use things like javascript for individual services.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
(Worth watching no matter what your background is, it's funny and informative)
The holy grail is a language that enforces guidelines itself, for example: a type system.
This is in contrast to something like Rails which is super opinionated and doesn't give you much of a choice if you as a developer or even as a company as a whole were to disagree with these opinions.
The current movement towards functional programming exemplifies this philosophy.
All I'm saying is JS is more than capable of scaling in both complexity and maintainability.
Can someone who knows what they're using node for go into a little more detail?
When people say they use Node for frontend, it generally means for things like Webpack or Gulp, not something running on the end user's computer.
1. https://github.com/Netflix/falcor 2. https://www.youtube.com/watch?v=WL54eYbTJUw
Something like this: https://medium.com/the-node-js-collection/netflixandchill-ho...
No thanks.
I'm looking at Go, Rust, Erlang, and Crystal. Go seems like the best choice so far.
This is not a productive comment.
To the extent that that's true, I'd say it's equally true of "here is this list of companies that use my preferred tools" articles like this one.
Pretty sure pronouncements like that are the real indicator of unmet emotional needs.
The way this community needles dissenting opinions needs to change. If you don't like the HN flavor of things, the resulting swarm of nitpicking, self-righteous commenters blots out the sun.
"Ugh, why would anyone use it on the server? Idiots!"
"Lol web developers only know one language. Sad!"
As if anybody that chooses a different set of trade-offs is incompetent, not just comfortable with a different set of trade-offs.
So for a lot of people web apps are good enough. They do not need native apps. The same applies to developers. Sure you can avoid transpiling to JS but JS also became good enough for people to just stick to it. And while they were at it they found out it is also good enough on the backend (nodejs) and on the mobile (react native) and also on the desktop (electron).
Only time will tell if it is or was the right choice.
Recently, JavaScript has adopted lot of language feature from C#, Ruby etc., that make it really useful for most common tasks. And the community moves really really fast, hence adoption of new language syntax is quite fast.
JavaScript has some killer platforms / apps, that are being used in production by high-traffic companies.
You can do cross-platform Desktop app in Electron (Slack, VSCode, Atom etc. are written with this).
Front-end build tools are written in Node JS, and they do lot of heavy lifting as well. Babel is a transpiler, Webpack is a bundler.
These days, native mobile apps (not hybrid apps) in JS are also gaining traction, via React Native.
From open source communities to big behemoths are behind this.
I would like to hear what about JS turned you off so much?
I wasn't aware that a platform's ability to move fast was now a feature. Sounds more like a moving target, honestly.
I want stable tools that let me do things quickly. In the current JavaScript ecosystem, you have the "do things quickly" part without the stable part. It's really easy to get bogged down in the mud. My guess here is that with the increasing industry tendency to move on every <2 years, everyone is building their shaky house and then getting out before it crumbles with them inside.
I don't think that Electron is an argument for JavaScript.
And basically the reason we have JS is because we can't agree on anything else. So JS is what we've got.
But you should take JS seriously, because it's what we've got. It's not going anywhere. And it powers the Internet. And for right now the Internet is the end all, be all, technology.