You can joke about it, but there is absolutely a lot of value in the fact that you can just fire up a debugger against Electron or React or your devtools or Node itself. The "just" is doing a lot of heavy lifting here of course, but I've done all of the aforementioned at different points of my career, to reasonably good success. I don't think everything should be written in Javascript, but at times it's been very convenient that that's what's under the hood.
Yes! At one early startup I worked at, one of our initial customers (we didn't have many at that point) had reported an annoying bug stopping their workflow. So one of our engineers logged into production on their tenant; replicated the bug; set some breakpoints in the Chrome debugger; worked out the cause of the bug; and then fixed it and deployed the fix within a few hours. Customer was happy.
I don't think there are many languages where you can do something like that? There are some where it's maybe even better, like Smalltalk...
With PHP you don't even have to deploy, just edit the files on the live server, save, and it is done. :D I'm not endorsing this way of doing things though.
Ok, but sorry, what is so special about Javascript here ? Did this for good old Java services a few hundred times. With hot-fix on same or next day. Remote debugging is supported for a large number of languages. It is not unique to JS alone.
JVMs support live visual profiling too - many engineers identify production performance issues this way. I don't think node js has anything to compete out of the box with the same level of convenience. (Last I checked, the profiling was bare bones primitive)
Yeah, that's handy, but it's also annoying that React Native has become the norm for mobile development. That's why we have tip calculator apps weighing in at 20 MB for what used to be 200 KB.
The "It's just JavaScript, so the frontend guys can work on the backend" line has never made any sense to me.
I think it's aimed at HR/recruiting.
Companies tend to think in terms of specific skills when hiring. Something like: We use PostgreSQL, so we will write "3 years PostgreSQL experience" in the job description for a senior backend engineer position.
Unless engineering is explicitly involved in the hiring process, HR will drop your resume automatically if you say "5 years of MySQL and SQLite experience" with no mention of Postgres.
> Unless engineering is explicitly involved in the hiring process, HR will drop your resume automatically if you say "5 years of MySQL and SQLite experience" with no mention of Postgres.
I found this the hard way during these last 2 years.
They might give you the benefit of the doubt if you have led teams before, but if that's not the case, your application is going to the bottom of the list because you don't match exact keyword and have a big number next to it.
I'd say that even though available APIs change based on context the premise of the "It's just JavaScript" line is more often that the syntax is still that of JavaScript. Meaning that in many ways it is much easier for someone used to browser/front-end JavaScript to start poking at a Node.js script compared to a python script with similar functionality. In that sense it is "just" JavaScript.
It's still useful to point out the differences like the article does. Because it isn't as if the transition between the various JavaScript environments is seamless.
I can agree that familiarity of the basic syntax is a decent strategy to get people over their fear of trying something new (really by making them think it isn't new at all). But it's also the lowest common denominator, and if understanding of the basic syntax is the only thing you have on offer, oh boy, are you going to meet that wall... real quick.
There is more to it. Even on different platforms there are a lot of shared APIs and principles. But yes, you still need a further understanding of the context you are now using the language in. Not to mention that you likely still need to do some further learning.
But, overall I'd say it still makes it significantly easier for someone to make a switch. Even more so given the current eco system where a front-end dev likely already has node.js installed, is somewhat familiar with npm, etc.
Even if we just stick to the syntax, just not having to worry about one such aspect when switching context overall shouldn't be understated as a benefit imho.
Classic communication mistake is assuming what people mean when they say $LANGUAGE.
Some people mean the language itself, others mean language + standard library, others mean language + standard library + tooling, others mean language + standard library + tooling + ecosystem.
The same people could be meaning different things at different times depending on what's in their mind at the moment.
> you no longer know when code is executed - it's magic
Kind of. That is what makes react a framework and not a library in my opinion. That being said, it's still learnable and managable (in pure react).
> state can be managed in ~5 different ways, with a lot of ceremony and idiosyncrasies
Not a valid argument. Just use react state and be done with it. If you go for anything on top, well yeah. But to be honest, other frameworks have the same problem, even in the backend.
> It is, absolutely, an eDSL (`useState` & `useEffect` introduce new semantics using JS syntax), and a proper DSL would be a lot easier to learn.
That is absolutely true and a valid point. It's mostly a shortcoming of javascript/typescript where it would be too annoying to pass down dependencies/props in a long chain of elements. So in an insufficient programming language you have the choice between typesafety+verbosity (react without hooks) or conciseness+unsafety (hooks are not typesafe, they are not regular functions and hence can't be refactored like them etc.). Basically, they break composibility.
Honestly, the frontend world circles around that problem and every blue moon something things they found the enlightenment and then they give up the previous benefits for new benefits. And the circle repeats.
I wonder if maybe effect.website might be able to change that in the future. It has the potential.
People who think JavaScript is easy have made a big mistake.
There are multiple build chains to pick from. Multiple package managers each with nuances. Every need (e.g. ORM, logging) has multiple options to choose from each with some shortcoming you won't discover until you are deep into it. It has vulnerability types that do not exist on other platforms.
The language is easy and flexible, but the platform as a whole and ecosystem is a mess if you want to ship enterprise grade software. The moment you realize the need to define meta types on the BE (Zod, class-validator, etc) is the moment you should just start transitioning to a runtime typed language because you've realized "Actually, runtime types are kinda nice".
Many teams realize this too late and are stuck in JS hell which infects everything the team does and creates drag at scale. It creates drag in the CI because you need more checks and the tooling itself is slow. It creates drag in the DX because I have to restart the TS language server multiple times a day. It creates drag in the platform config because it's spaghetti to get things working and it's slow to build at scale.
For FE, it's hard to avoid. For BE...why do it to yourself if you know you're not building a toy?
Yes, I build JS backend, but it's fine for my side projects. Great even! For real, high value work? It is a mistake every time because it requires much more babysitting than almost anything else.
This code will in fact NOT run on Deno, unless one explicitly configures Deno to load JavaScript code as CommonJS. With Bun, however, this code runs without any configuration necessary.
I suppose the author is intentionally not mentioning these details, since it's greatly summarized at the end of the article. JavaScript code indeed requires a great amount of context on the ambient development environment.
There is a related article I recall reading last year, asserting that "JavaScript does not exist". Cannot find the article, unfortunately, so I will paraphase. The article explained how a modern development stack involves a composition of several code transformation tools. We are effectively writing in a fictitious language and pass it through a series of transformations until we finally get syntactically valid JavaScript. Off the top of my head: most people in frontend are likely using React and TypeScript. TSX files at least go through the TypeScript compiler and a plugin to transform JSX to JS. The outputted JS may have funny things like "CSS imports" or bundler-specific "magic comments" like the article's Preact example. That has to be specially handled by a bundler (like Vite) so that the JS file becomes syntactically valid JavaScript.
>"...modern development stack involves a composition of several code transformation tools."
Or not. We for example use plain browser site JavaScript for business frontends. Bar some domain specific libs and web components we are not using any frameworks like React. Saves great deal of time in the end.
author here: this is a great point, thx for pointing it out! also love this summation
> We are effectively writing in a fictitious language and pass it through a series of transformations until we finally get syntactically valid JavaScript
Seems like the code from the article will run as-is with either of the first two options. In any case, this is what I meant by Deno not being able run the code "unless one explicitly configures" it.
Readit News
I don't think there are many languages where you can do something like that? There are some where it's maybe even better, like Smalltalk...
Isn't this a basic feature that all languages have?
Never mind pretty much all other languages.
JVMs support live visual profiling too - many engineers identify production performance issues this way. I don't think node js has anything to compete out of the box with the same level of convenience. (Last I checked, the profiling was bare bones primitive)
What TSMC giveth React Native taketh away...
"Is it C?" – there is a big difference between C on Linux, C on Windows, C on an embedded chip doing real-time shenanigans...
"Is it Java?" – Desktop? Server? Android? Java ME? A CREDIT CARD?!?
The list goes on...
I think it's aimed at HR/recruiting.
Companies tend to think in terms of specific skills when hiring. Something like: We use PostgreSQL, so we will write "3 years PostgreSQL experience" in the job description for a senior backend engineer position.
Unless engineering is explicitly involved in the hiring process, HR will drop your resume automatically if you say "5 years of MySQL and SQLite experience" with no mention of Postgres.
I found this the hard way during these last 2 years.
They might give you the benefit of the doubt if you have led teams before, but if that's not the case, your application is going to the bottom of the list because you don't match exact keyword and have a big number next to it.
I had thought the industry has matured by now, but nope, still running the same old scripts!
It's still useful to point out the differences like the article does. Because it isn't as if the transition between the various JavaScript environments is seamless.
But, overall I'd say it still makes it significantly easier for someone to make a switch. Even more so given the current eco system where a front-end dev likely already has node.js installed, is somewhat familiar with npm, etc.
Even if we just stick to the syntax, just not having to worry about one such aspect when switching context overall shouldn't be understated as a benefit imho.
Some people mean the language itself, others mean language + standard library, others mean language + standard library + tooling, others mean language + standard library + tooling + ecosystem.
The same people could be meaning different things at different times depending on what's in their mind at the moment.
* you no longer know when code is executed - it's magic
* state can be managed in ~5 different ways, with a lot of ceremony and idiosyncrasies
It is, absolutely, an eDSL (`useState` & `useEffect` introduce new semantics using JS syntax), and a proper DSL would be a lot easier to learn.
Kind of. That is what makes react a framework and not a library in my opinion. That being said, it's still learnable and managable (in pure react).
> state can be managed in ~5 different ways, with a lot of ceremony and idiosyncrasies
Not a valid argument. Just use react state and be done with it. If you go for anything on top, well yeah. But to be honest, other frameworks have the same problem, even in the backend.
> It is, absolutely, an eDSL (`useState` & `useEffect` introduce new semantics using JS syntax), and a proper DSL would be a lot easier to learn.
That is absolutely true and a valid point. It's mostly a shortcoming of javascript/typescript where it would be too annoying to pass down dependencies/props in a long chain of elements. So in an insufficient programming language you have the choice between typesafety+verbosity (react without hooks) or conciseness+unsafety (hooks are not typesafe, they are not regular functions and hence can't be refactored like them etc.). Basically, they break composibility.
Honestly, the frontend world circles around that problem and every blue moon something things they found the enlightenment and then they give up the previous benefits for new benefits. And the circle repeats.
I wonder if maybe effect.website might be able to change that in the future. It has the potential.
Do you know a language that has solution to this on a language level?
The only similar thing I can think of are dynamic vars in Lisp. At a quick glance they remind me of React Context.
There are multiple build chains to pick from. Multiple package managers each with nuances. Every need (e.g. ORM, logging) has multiple options to choose from each with some shortcoming you won't discover until you are deep into it. It has vulnerability types that do not exist on other platforms.
The language is easy and flexible, but the platform as a whole and ecosystem is a mess if you want to ship enterprise grade software. The moment you realize the need to define meta types on the BE (Zod, class-validator, etc) is the moment you should just start transitioning to a runtime typed language because you've realized "Actually, runtime types are kinda nice".
Many teams realize this too late and are stuck in JS hell which infects everything the team does and creates drag at scale. It creates drag in the CI because you need more checks and the tooling itself is slow. It creates drag in the DX because I have to restart the TS language server multiple times a day. It creates drag in the platform config because it's spaghetti to get things working and it's slow to build at scale.
For FE, it's hard to avoid. For BE...why do it to yourself if you know you're not building a toy?
Yes, I build JS backend, but it's fine for my side projects. Great even! For real, high value work? It is a mistake every time because it requires much more babysitting than almost anything else.
I suppose the author is intentionally not mentioning these details, since it's greatly summarized at the end of the article. JavaScript code indeed requires a great amount of context on the ambient development environment.
There is a related article I recall reading last year, asserting that "JavaScript does not exist". Cannot find the article, unfortunately, so I will paraphase. The article explained how a modern development stack involves a composition of several code transformation tools. We are effectively writing in a fictitious language and pass it through a series of transformations until we finally get syntactically valid JavaScript. Off the top of my head: most people in frontend are likely using React and TypeScript. TSX files at least go through the TypeScript compiler and a plugin to transform JSX to JS. The outputted JS may have funny things like "CSS imports" or bundler-specific "magic comments" like the article's Preact example. That has to be specially handled by a bundler (like Vite) so that the JS file becomes syntactically valid JavaScript.
Or not. We for example use plain browser site JavaScript for business frontends. Bar some domain specific libs and web components we are not using any frameworks like React. Saves great deal of time in the end.
> We are effectively writing in a fictitious language and pass it through a series of transformations until we finally get syntactically valid JavaScript
that article sounds interesting...
(1) the file extension is "cjs",
(2) there is a package.json file with "type" set to "commonjs", or
(3) a require function is created with createRequire
https://docs.deno.com/runtime/fundamentals/node/#commonjs-su...
Seems like the code from the article will run as-is with either of the first two options. In any case, this is what I meant by Deno not being able run the code "unless one explicitly configures" it.