Sometimes the jokes just write themselves :)
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.
const fs = require('fs');
const content = fs.readFileSync('./data.txt', 'utf8');
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.
(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.
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...
Not possible, as far as I know.
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...
Never mind pretty much all other languages.
Edit: Plus, if there was a crash, you can generally get a coredump, so you can inspect the exact state the program was in, again, with GDB.
Isn't this a basic feature that all languages have?
Its only thrown away if you ask the compiler to throw it away. You can always ship a debug build.
I also don't endorse this way of doing things, but there's no faster way to hotfix something.
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...
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.
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).
"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!
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.
/pedantry
* 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.
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).
So you write:
def foo5(nonReleventProps: Props) =
(props) => { const x1 = foo10(); const x2 = foo20(); return x1+x2; }
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.
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.
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.
devjam•1d ago
chrismorgan•1d ago
jimniels•1d ago