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.
At least from my personal perspective, the core difference here is that I use the same tool for all of those different things. Any mature language these days has a solid debugger available, but not jumping between different tools means you get more proficient at the one tool you do use.
any language where the necessary information is not thrown away when producing a binary. so that means by default languages where the source is distributed have an advantage. but that's still a lot of languages.
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.
I personally use that style in Scala with ZIO. Because the same problem exists in basically every language. I think more and more languages capture something like that and more under the term "capabilities". In a sense, the Rust borrowchecker is a very specialized case.
https://effect.website/ offers something very similar that in their effect-type; the "environment" parameter.
Basically, imagine you have many foos like `fun foo1(props: Foo1Props): string {...}` and so on, and they all call each other. Now you have one foo999 at the very bottom that is called by a foo1 at the very top. But not directly. foo1 calls foo5 which calls foo27 and so on, which then calls foo999.
Now if foo999 needs a new dependency (let's say it needs access to user-profile info that it didn't need before) you have to change the type signature and update Foo999Props. To provide it, you need to update the caller, foo567, and also add it there. And so on, until you find the first fooX that already has it. That is annoying, noisy (think of PR reviews) and so on.
Using the effect-type of effect.website you basically can the move the dependency into the returntype. So instead of returning `string`, `fun foo1` will now return `Effect<string, Error, Dependencies>` where Dependencies would be Foo1Props - which means it will not have the props parameter anymore. (or, they way I do it, I only use the Dependencies for long-lived services, not for one-off parameters)
Inside of fun1 (or funX) you can now access the "Dependencies". It's basically a kind of "inversion of dependecies" if you want so.
Seems like just moving the required dependencies from the parameter into some weird complex result type. But, there is a big difference! You have to annotate the parameter, but you can have the compiler infer the return type.
So now if you have a huge call chain / call graph, the compiler will infer automatically all dependencies of all functions for you (thank god typescript has good union types that make that work - many other languages fail at being able to do so).
Where foo10 is of type `Props => ServiceA` and foo20 is `Props => ServiceB` and the compiler will infer that foo5 returns an effect that needs both ServiceA and ServiceB - and so on. (note that you have to combine the results in a different style, I used just `const x = ...` to keep it simple)
So if you make a change very far down the call graph, it will automatically propagate up (as long as you don't explicitly annotate types). But, you still have full typesafety and can see for each function (from the inferred type) which dependencies it needs and so you know during a test hat you have to pass and what not.
Lisp is a completely different world because it is dynamically typed. In a sense it doesn't have the problem from the beginning, but it sacrifices type-safety for that.
> At a quick glance they remind me of React Context.
Yes, the intend is basically the same, but React Context is... well, an inferior version, because if you use a context where it has not been provided, it just blows up at runtime and no one protects you from that.
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.
I think the "javascript everywhere" phenomenon this article talks about comes from us misjudging the difficulty of learning a new language.
Python's a good example of this (or at least its one I use every day). In order to be able to keep using Python at larger scales, it's become a very big, complex language.
Sometimes I wonder if a lot of use cases for typed Python would be better matched by starting out in a typed language like Go in the first place.
In some ways, learning a new language can be easier than learning lots and lots of features of an increasingly complex language.
Maybe. But the cognitive load of learning a new language (and programming correctly in that language) is real.
And even more real is the emotional stress and mental turmoil a person faces when they're required to learn something new rather than pick up something familiar. When someone has deadlines, a home life, strong demands from their boss, familiarity with build pipelines, a team full of people that they can call on, etc, it's often easier to keep the stress and confusion count lower by sticking to the familiar.
Especially when, in cases like Python with types or Java with Lombok and "just one more thing" will "fix" the rough edges or difficult scenarios that the those specific developers have. Sure it's "one more step", but it's probably a small one and one they can reason about without having to upend their entire mental model (even if in practice they might not need to).
That's the issue with any abstraction I'd say. I know English, but I can't properly give legal advice based on regulations written in English. There is one more layer of human conventions besides the "English language" convention that I'd need to learn.
I'd say the point to be made is that debugging a library is way simpler than debugging a framework like React (even though they insist on calling it a library) because your code is no longer the entrypoint but some intermediate step in the logic.
author here, thx for pointing these out! I was simultaneously working on some CSS for my blog on localhost and when I looked up some references to older articles to put in my post, I looked them up in the version of my site that was running locally and forgot to change the links lol. Whoops. Fixed now — thanks again!
My favourite one was debugging a crash in an Electron app deployed to iOS. It turned out throwing an exception from a point event callback (deep in our app's code) was bubbling up into the device's kernel code.
