The JavaScript ecosystem is delightfully weird

https://fly.io/blog/js-ecosystem-delightfully-wierd/

by todsacerdoti • 3 years ago

173 238 3 years ago

fly.io

ElfinTrousers2• 3 years ago

That would be a polite way to put it yes.

VyseofArcadia5• 3 years ago

I wonder how much of this can be blamed on JS being a relatively gentle and forgiving codegen target.

ElfinTrousers2• 3 years ago

I suspect that if some accidents of history hadn't left JS as the only language you can use to script a Web browser, it would have died off long ago.

VyseofArcadia5• 3 years ago

I've been wondering about that lately. What is the rationale for making it necessary to run WASM binaries through JavaScript? Seems like a missed opportunity to not be able to just point a script element at a WASM blob, but I'm sure I'm overlooking something.

cout• 3 years ago

I want to disagree, but I think you are right. Java and Flash were the only alternatives to javascript that ever gained a foothold, and both of them were second class citizens. Circa 2001 I tried to use Java to interact with the DOM and ran into a browser bug that iirc took about a decade to fix. If the technology had ever been usable things might have turned out differently (or it might have turned out the same, who knows).

NoMoreNicksLeft• 3 years ago

What else was there, besides VBscript, or whatever Microsoft was calling it then? Even if we're only talking hypotheticals, at what point would anyone have attempted to release an alternative?

Everything was mucked up well into the 2010s with everyone chasing IE compatibility. And not even 3 years later, Chrome had taken over the world. That's a really brief window for anything to happen.

hnal9433• 3 years ago

I don't think that's true. I find Crockford's argument compelling that js is misunderstood and that the core of the language is a diamond in the rough.

https://youtu.be/47Ceot8yqeI?list=PL7664379246A246CB&t=3792

ragnese• 3 years ago

How is it a better codegen target than any other language? That's not intended with an argumentative tone- I'm genuinely curious as to what you mean.

VyseofArcadia5• 3 years ago

It's only a half-informed thought. I work on a project that compiles a domain specific language to C and C++. When I think about JavaScript as a codegen target, all I can see is all the problems I wouldn't have.

anon291• 3 years ago

Javascript benefits from the major efforts put into its JITs. No other scripting language really has that.

marcosdumay2• 3 years ago

Hum... A lot of people is working on JS codegen, so there are all kinds of knowledge bases, libraries, and standards for it. Also, JS itself got some changes to support it better.

So, yeah, it's a better target than most general purpose languages. It's surprisingly simple to generate, much simpler than to write on. It is also a worse target than most languages specialized on being generated.

brundolf• 3 years ago

I think what makes it a popular codegen target has more to do with

- The places it can run

- The ecosystem it can interop with

Not that it's a bad codegen target otherwise- it's high-level but performant for being so high-level, it's garbage collected, first-class functions, low-level primitives are available for optimizations, etc. But these on their own don't make it super unique

breckenedge• 3 years ago

So JS is delightful because we are still not actually writing JS, but stuff that looks like JS? Huh.

krapp2• 3 years ago

It's weird how JS is the only ecosystem entirely designed around the premise of avoiding direct contact with the language you're developing in at all costs.

Like, even C programmers are willing to actually write C.

spicebox• 3 years ago

Rust has a far more powerful and widely used macro system then JS but I don’t think that means rust devs are trying to avoid writing rust at all costs

WorldMaker7• 3 years ago

The C macro language is technically a different language (though today they are specified together, they originated once as different compiler tools) than C and lot of DSLs get written in it because C programmers are trying to avoid actually writing C.

There's also a lot of C programmers that prefer to use C++ compilers in C++ mode for their C code to avoid direct contact with C specification bugs or some C standard libraries.

(Plus, early C itself was designed to avoid direct contact with Assembly languages which was designed to avoid direct contact with Machine languages some of which were designed to avoid direct contact with Microcode languages most of which were designed to avoid direct contact with TTL logic and TTL logic was designed to avoid direct contact with the useful properties of transistors for computation and so forth. Programming is turtles all the way down.)

(Also there are quibbles to be made about "at all costs". JSX is still a superset of JS syntax with a little bit extra added in. Typescript is built to be a superset of JS syntax. You can't write either without a lot of direct contact with JS. Neither seems like "at all costs" avoidance to me.)

zaphar• 3 years ago

That is not what the author said. They said the JS Ecosystem was delightful. He then goes on to describe that Ecosystem. For some people that ecosystem is indeed delightful. They love the sheer complexity it takes to deploy a JS application these days. There is certainly a lot of choice and power out there for it.

I personally am the kind of person who tries to ship my stuff as a single statically linked binary that I can just drop in place so I look as WebAssembly as a way to participate in the browser ecosystem while avoiding the whole NPM/JS Tower of development tooling complexity. I don't begrudge others from wanting to play there though.

weeksie2• 3 years ago

Javascript is this generation's C++. It's a massive language and the only way to stay sane on a project is to agree to use a well demarcated subset of it.

Nothing wrong with being C++. The reason JS is so massive and weird is because it's the language that everybody uses, or has to use at some point. Upsides and downsides.

miohtama2• 3 years ago

JavaScript, The Good Parts by Douglas Crockford symbolises this well today

https://www.reddit.com/r/ProgrammerHumor/comments/621qrt/jav...

pcthrowaway4• 3 years ago

Javascript, The Good Parts, is not really relevant to today's Javascript, unless it's been refreshed. I remember working through it 10+ years ago:

* `var` is no longer a thing.

* Even `let` is less common now.

* Using closures and prototypes to enable functions to be used like classes and have private variables and static variables, have been replaced with proper classes

Nowadays if you want to use the good parts of Javascript, just install eslint with insane defaults and let it tell you if you're trying to use the non-good parts

amateurCoder5• 3 years ago

"JavaScript, The Good Parts" is not really relevant to modern JS. But Crockford's new book "How JavaScript Works" is basically the updated version. As an amateur coder I found it very useful, definitely worth reading.

tln• 3 years ago

Are you talking about JS the language, or the ecosystem?

JS as a language isn't nearly as big as C++ or, say, Swift... I'd say Python complexity is on par or even higher than JS, in terms of core language features.

There are some language features that are outdated but it's hardly like the C++ situation.

josephg• 3 years ago

There are far more ways to write javascript than any of us want.

For objects with methods you can make literals, use a constructor with new and have prototype methods, use a class, or use Object.extend, or Object.create or probably other tricks.

For async code we have callbacks or promises. And promises can just use the Promise class and .then(), or you can use async / await. And the promise class also has polyfills in npm if you want that instead. Or there’s tricks with generators.

Functions can be written with function foo(), or const foo = function(), or const foo = () => {…}. Or const container = { foo() {} }. Or use class methods (which have different syntax again).

Importing external code can use commonjs (require()). Or import statements. Or dynamic import. In the browser you can use multiple script tags and have scripts assign their library to a global object. In nodejs code can also change what require does.

I can keep going - don’t even get me started on bundlers. You’re probably right - the language probably still isn’t as big as C++. But it’s big enough that almost nobody knows every javascript feature. I was around in the early days of nodejs (0.4 was my first version). At the time the design of the language, and of nodejs, seemed simple, clear and cohesive. Don’t get me wrong - I love a lot of the newer features. But javascript as a language feels like a bit of a bloated mess.

teichmann• 3 years ago

ECMAScript Language Specification 13th Edition / June 2022 (846 pages): https://www.ecma-international.org/wp-content/uploads/ECMA-2...

Working Draft, Standard for Programming Language C++ from 2020-01-14 (1815 pages): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n48...

I'm not sure what's the "correct" spec for the current C++ standard is. Still a big difference between these languages, but 846 pages isn't exactly small either.

throw_m239339• 3 years ago

Javascript is this generation's C++. It's a massive language and the only way to stay sane on a project is to agree to use a well demarcated subset of it.

No, it's not massive compared to C++, it's actually quite simple. No explicit pointer management, no memory management, no user defined operator overloading and so on and so forth. The only difference between classes and function prototypes AFAIK is "super" late binding, otherwise one can replace classes with functions everywhere they want.

The problem isn't javascript itself, it's the different runtimes that have different API. But the javascript spec is tiny compared to C++.

As for the ecosystem, it's mostly node's that is a mess, as the result of core Node API being barebone. Browser API are actually quite extensive and do a lot of stuff, from shaders to XML parsing to sound generation, but this isn't javascript it's the DOM/Browser API.

ilyt2• 3 years ago

JS is far smaller language than C++. You don't need to agree on common part of language, it's the rest of the ecosystem around that's the problem as you "need" a lot just to fix JS deficiencies

weeksie2• 3 years ago

Yes.

danwee• 3 years ago

For me:

JavaScript === C

TypeScrit === C++

You can shoot yourself in the foot writing vanilla JavaScript. There should be a book "TypeScript: The Good Parts" though: the language brings a lot of stuff that is better not to use.

overgard5• 3 years ago

C++ is this generations C++, it hasn't gone anywhere (especially with WebAssembly). JS isn't even a tenth of the insane complexity of C++ (I say as a fan of C++ and JS)

junon5• 3 years ago

Coffeescript was well before "tree shaking" (the JS ecosystem's way of spelling "dead code removal") and code splitting, both being relatively new things in the bundler world ("tree shaking" being introduced with rollup if memory serves). Then came Acorn, which gave way to a whole slew of JS transformation bits.

It also didn't help that Node was fixed at 0.12 for years and years, and we had the IO.js fork until Node was released by Joyent for OSS community members to take over. That caused more issues to boot.

Also the whole bundling fiasco started with Babel, which wasn't a bundler at all and instead started as a means to provide polyfills for supporting "old browsers" (really, IE). From that whole thing came the concept of "evergreen browsers" which is a term that has largely fallen out of the common vocabulary with the rise of Edge.

Now we have "anything is a valid feature request" TC-39, and "it's really just Google at this point" browsers dictating how the web works.

It's a nightmare. As a maintainer of several large JS packages, and being so dreadfully burnt out on JS, there are other words I'd use to describe the whole thing than "delightful".

chrismorgan2• 3 years ago

"tree shaking" (the JS ecosystem's way of spelling "dead code removal")

I’m not altogether against giving it a different name. It’s very limited compared to what proper ahead-of-time compilers manage. I’d really like to see some actual effort put into partial evaluation and symbolic-execution-guided code simplification and dead code removal. Google tried something a little like it in Closure Compiler’s advanced optimisations mode, many years ago, but hasn’t really kept it up; and Facebook tried some five years ago with Prepack, but quickly gave up on it for unclear reasons.

rektide• 3 years ago

Qwik is interesting here, very just-in-time with running JS on the client side.

https://qwik.builder.io/docs/concepts/resumable/

EMM_386• 3 years ago

As a maintainer of several large JS packages, and being so dreadfully burnt out on JS, there are other words I'd use to describe the whole thing than "delightful".

My first project that used JS was in 1996, so I've been along the ride every step of the way. Up until today where I am working with all of this on an Angular 15 enterprise project.

I actually would describe it as delightful, compared to what it was like only a short 10 years ago. 1996-ES6 was painful.

I understand your pain as maintainer and am also burnt out on ... um ... 27 years of JavaScript. Yikes.

But now it can just be written in TypeScript and I'll let the transpilers and other tools handle the details.

It is so much better.

yamtaddle6• 3 years ago

The thing about JS is that it was always terrible 5-10 years ago, and is always "actually good now".

[EDIT] Though I actually agree that it's nearly-tolerable now that we have TypeScript and async/await to force what always should have been the default behavior.

spion• 3 years ago

If other tools handling the details just works for you, thats pretty amazing (and kinda surprising). Last time I was working on JS tooling there was a smorgesboard of various choices and it looked like most are opinionated just enough to not work with each other.

junon5• 3 years ago

I've been at it since DHTML as well. I miss ES5. It should have ended there.

WA• 3 years ago

So, what language/ecosystem do you prefer nowadays if you were free to choose?

Scarbutt2• 3 years ago

For web apps is just Javascript. And since you are forced to use it, why not run it on the server too and use less programing languages? Not a fan, but it is what it is.

junon5• 3 years ago

I firmly believe Rust is the future.

polishdude20• 3 years ago

I feel like this is a normal thing for any language that becomes this ubiquitous. Python, C++ , Haskell, Java don't run in the browser the way JavaScript does. They don't have the same requirements that the JavaScript ecosystem does.

nextaccountic• 3 years ago

What do you think about Deno?

junon5• 3 years ago

Not a fan, for one reason in particular: they allow URL imports[0]. It's a massive uptime and security flaw in my opinion that was added because someone asked for it. It's been asked for on the Node repository as well where it's received mixed feedback (namely, negative feedback from several core contributors) due to it being, well... a dumb idea.

I've never seen the need for Deno. Every library I've written that has more than a few hundred users has inevitably been spammed about "Deno support when?" which also turned me off from it.

[0] https://deno.com/manual@v1.0.0/linking_to_external_code

stevefan1999• 3 years ago

Joyent. Loved their free cloud server plans before until it was accquired by Samsung. It was also at that time I started looking at NodeJS, which is one of the side project from their software engineer for their SmartOS based on Solaris amirite?

But anyhow, boy oh boy, look at what we have today.

thayne• 3 years ago

Coffeescript was well before "tree shaking"

From my quick research, it looks like the initial release of google's closure compiler, which had some amount of tree shaking, predates Coffeescript by about a month.

aigoochamna• 3 years ago

I wouldn't say bundling started with babel... but was predated by browserify and other bundlers... oh the days of gulp/grunt and browserify...

simultsop• 3 years ago

I find this like saying you are actually writing binary code, what you code is not any language at all.

chrismorgan2• 3 years ago

deliberately misuses the JavaScript label syntax

Eh, deliberately repurposes. I don’t think “misuses” is the right word at all.

abuse of the bundler

This also feels too strong a wording—though the fact that these are at least .js files (unlike .svelte files in the other case) makes the term “abuse” less unreasonable.

ghusto2• 3 years ago

Nobody Writes JavaScript Any More

This is how "delightful" it is, and is the reason I'm waiting for it to die.

Every couple of years we decide on the 'no no, definitely this time we have it all figured out, trust us, just use X' "solution" to the problem of JavaScript. We have the definative 'this is how you do it', until the next one.

mathgladiator• 3 years ago

I'm waiting for it to die

I'm there with ya, but I wouldn't hold your breath. I'm trying to minimize my JavaScript exposure by using streaming, and it's going well enough with a minimal JavaScript "runtime". However, I still find myself with thorny edge cases like "I need a better date/time picker", "color picker", or a drag and drop calendar planner.

I find myself frustrated with the ecosystem, and I'm debating how large the set of exceptions are to my ideology.

superchroma• 3 years ago

This. It fucking sucks. I just waded back into it and I hate everything about it. VSCode barely copes, Visual Studio doesn't even try and Rider was the only thing that worked which hasn't helped my mood.

danielvaughn2• 3 years ago

I don't know enough about WASM to know why it can't be exposed directly to the DOM, since in theory the DOM should be a language-agnostic interface. If that were to happen, I think the floodgates would really open on WASM and we'd finally start to see JS die.

rafark• 3 years ago

Exactly what I thought a few months ago.

The DOM and the HTTP api (or pretty much all browser APIs for that matter) should be interfaces that can be implemented in WASM code. I have no idea why this hasn’t been proposed let alone implemented. I mean, why give us the ability to use other languages if we can’t implement the (browser) APIs?

dwaltrip• 3 years ago

I think this is pretty much all of programming.

Or life in general.

There’s plenty good and plenty bad. It’s no use fixating on things you can’t change. Focus on what you can do.

potta_coffee3• 3 years ago

Javascript is not going away anytime soon, probably. Personally, I'm waiting for React to die.

steve_adams_862• 3 years ago

As much as I love React and it has been a positive part of my career, I'm starting to think there really are better alternatives. Its staying power may just be the sheer number of people supporting its ecosystem and competent enough to build things with it.

I'm content to keep working with it, and I'm so familiar with it that for small tasks it's kind of my go-to. If I was building something I wanted to be long-live a future-friendly, I might be hesitant to run with React at this point. To be honest though, I'm not sure what's better than would be a clear contender for having similar staying power. I wouldn't complain if that turned out to be Solid.

leptons3• 3 years ago

The only real problem with Javascript is people's lack of understanding of it - and it's not even that difficult.

dgreensp• 3 years ago

I stopped reading after the typo “JavasScript” and then the juvenile tone of “Less that 10 years ago, JavaScript sucked bad.”

I have a positive impression of fly.io overall, I mean they admitted they are still figuring out how to build tech at the level of their ambition and have it be reliable enough, but I might like to be a customer one day.

recursive• 3 years ago

the typo “JavasScript”

You may be interested to know TC39 makes the same "typo" at https://tc39.es/ right in the biggest header on the page.

Specifying JavaScript.

Hm, maybe it's not a typo?

toastal2• 3 years ago

The JS ecosystem also relies on npm, which is owned by Microsoft. Having a corporation control package management is pretty weird.

wetpaws2• 3 years ago

Something something pnpm, yarn, jfrog

toastal2• 3 years ago

I believe they don't have registry or independent mirrors. Which CLI tool isn't that important.

earthboundkid• 3 years ago

Well, now that Microsoft has embraced and extended open source, I think it's time for us all to let our guards down, because it's not like they have some kind of "third step" to their business plans.

davely• 3 years ago

I am a product of a coding bootcamp from awhile back, so JavaScript is really the only thing I’ve ever known in my career (outside of writing some apps in Visual Basic around 2001).

Maybe it’s because it’s the only thing I’ve ever known, but… I like it?

I guess if I hack around on a side project and want to use vanilla JS, it’s the Wild West and there’s no rhyme or reason for anything (and everything looks gross).

But working inside various frameworks have been pretty enjoyable for me.

Side note: there’s also this hilarious video about the… delightful nature of JavaScript from 2012:

https://www.destroyallsoftware.com/talks/wat

qbasic_forever2• 3 years ago

JS itself is perfectly fine and quite a nice language when you stick to all its modern idioms that you learned and use today. I think what rankles a lot of people is going through the history of JS when it was terrible and confusing, then basically just jQuery, then the explosion and confusion of server side/node and drama with the company behind it, and finally confusion and drama with moving to modern ES modules.

For the longest time doing the most simple thing in any programming language, putting code in a separate file and loading it to execute, was nearly impossible in JS and required learning and picking sides in an opinionated loader battle. It was confusing and pretty bad for newcomers.

Nowadays all that drama is settled and the core of modern JS is quite nice. I like it more than python to be honest.

treis• 3 years ago

The problem with JS these days is not that what's there is bad. It's that there's not much there. Anything beyond the basics requires you to roll your own or go hunt for a library.

ElectricalUnion2• 3 years ago

and finally confusion and drama with moving to modern ES modules. (...) Nowadays all that drama is settled and the core of modern JS is quite nice. I like it more than python to be honest.

Using a mixture of old, deprecated versions of Webpack, Angular, Babel, and Typescript, and a very big pile of code with plain bad (if not plain wrong) type annotations I wish that statement applied to me.

Constantly attempting to keep all this nodejs stuff without vulnerabilities while migrating the least ammount of stuff at once is a daily challenge.

And that comparison is pretty low bar, everything involving say pytorch is a flaming pile of bad waiting to explode.

chrisco255• 3 years ago

I always think back to this talk when I come across a WebAssembly Text file, annotated by .wat. Highly relevant to the author's prediction about the future from 2014 as well: https://www.destroyallsoftware.com/talks/the-birth-and-death...

https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...

rglover• 3 years ago

The mind bending parts of this presentation are where he first utilizes use server to implement a client side form action, and then later launches a client side alert from the server using use client. And he closes by saying that this requires new generation routers and new generation bundlers.

No, it just requires a basic websockets implementation and a normal HTTP server. If anyone else like me loves JavaScript but thinks the above line of thinking is bananas, join me on the lifeboat [1].

[1] https://github.com/cheatcode/joystick

vmfunction• 3 years ago

Hmm, it's a shame that Little Javascripter is not mentioned: https://www.crockford.com/little.html That is really the only positive reason to use JS.

jsdeveloper• 3 years ago

So what was weird exactly? react is not JS. nextjs is not js..... same way spring boot is not java. JS is the way it is. Most of it complainants has issues as they usually come from synchronose language and when JS (its true power) uses its async nature, they can't comprehend it and think its weird, why would it do so. If your rational is that its slow, you should probably use assembly to write the most optimal code. If you want a high level language then JS brings most paradigm than competing languages. If you argue to want all features high level, low level and speed go for C++.

techaqua• 3 years ago

nextjs is not js..... same way spring boot is not java

does spring boot bring it's own dsl and compiler?

ElectricalUnion2• 3 years ago

Kinda, as usual within Javaland, there's a lot of reflection involved into making annotated interfaces (a kinda of standard Java reasonably limited dsl capabilities) pop up as singletrons connecting to your database/OLAP/LDAP/REST-endpoints/websocket-clients/whatever.

Same thing for serialization things, you define interfaces, the actual classes often just pop into existence by generated bytecode.

It's also not unknown to bring JSP/EL (literally requires a Java Compiler embedded in your server to compile servlet objects for you on the fly) or some other, on purpose less fully featured template things with their own DSLs like Thymeleaf to do the same job.

pier254• 3 years ago

I must be the only person left not writing TS at this point.

Once EcmaScript adopts optional static types or some kind of standardized type annotations [1] I will probably use those. At least in Node, where I have more control of the runtime version.

[1] https://github.com/tc39/proposal-type-annotations

Wazako• 3 years ago

typing saves so much time. Especially since the flexibility of its optionality does not restrict, and allows for really nice autocompletions.

Especially with esbuild which has made this simple and fast, one could even say it has saved javascript.

pier254• 3 years ago

I have ample experience with typed languages like C++, C#, Java, Kotlin, Go, AS3, Swift, etc.

Maybe I just have exceptional memory but I rarely encounter a problem that would have been solved by using TS.

hot_gril9• 3 years ago

Typing wastes time. Teammate and I tried switching a backend project to TS, and I kept a mental note of time spent defining types vs time saved not debugging type-related issues. The result was some high number vs 0. Also messed with the toolchain, making things like Node profiling not work.

capableweb4• 3 years ago

Believe it or not, autocomplete is still possible without typing, as any user of any dynamic language could tell you. Seems like a poor reason to add a another full language to the abstraction ladder of your application.

potta_coffee3• 3 years ago

You're not the only one. I'm sure Typescript is nice / better, but I don't feel like having yet another bullshit language foisted on me. Also I dislike Microsoft.

overgard5• 3 years ago

I'd barely call it a new language, it's just javascript where you actually document the allowed structure of your data.

solumunus2• 3 years ago

Typescript is just Javascript with more features. Why would you not embrace that? There's nothing taken away, only added.

fbn79• 3 years ago

I'm with you. I do not want my code transpiled. I wrote vanilla JS and use Typescript only as annotations (https://www.typescriptlang.org/docs/handbook/jsdoc-supported...)

atlantic• 3 years ago

I'm still using Javascript and jQuery. In combination they work just fine. I took the time to learn TS, but I never felt the need for it.

artyom6• 3 years ago

I moved away from JavaScript because of the same reason I moved away from PHP.

An originally decent idea gone terribly wrong.

reidjs• 3 years ago

How do you build web applications?

artyom6• 3 years ago

I don't. I build backend services now.

But to be fair, I still maintain a relatively popular Chrome extension in old-school JS and that's still a pleasure to work with.

sodapopcan2• 3 years ago

There are plenty of ways these days to build rich web applications without writing much JS. LiveView, Hotwire, Reactor, LiveWire, Blazor...

isanjay• 3 years ago

IMHO JavaScript is neither a good OOP language not a good Functional language.

artyom6• 3 years ago

Unfortunately I think the opposite. JS was a great prototype-based language, but very few understood those and tried to fit it into functional or OOP mindsets.

When they started talks about adding classes to the spec I knew I had to run away.

qazxcvbnm4• 3 years ago

Many other comments have touched upon other unusual aspects of the Javascript ecosystem, but there's another major aspect in the ecosystem at quite a precarious position, yet of which, I see very little discussion on, namely, the debugger.

Chrome DevTools is the de facto debugger of Javascript, which becomes apparent once I have to take advantage of Javascript's capability of moving beyond the browser, on alternate runtimes. To debug node.js for the server and Hermes for my apps, in both cases I need to use the Chrome DevTools debugger which uses the Chrome Debugger Protocol. In the case of Hermes, the Chrome DevTools that comes with React Native doesn't even come from your local copy of Devtools, but is dynamically loaded from https://chrome-devtools-frontend.appspot.com/.

As far as being a protocol goes, I have yet to see another viable implementation of a Javascript debugger. To profile my performance or check my memory usage, I need to use Chrome. Even worse, both node.js and Hermes have strange issues pop up with the debugger connected. In the case of Hermes, it is acknowledged that the Javascript runtime is not fully compatible with Chrome DevTools Protocol, whereas node.js occasionally exhibits segmentation faults with the debugger connected, or falls into non-terminating computation when connected to certain complicated programs (such as npm...)

It worries me greatly that to debug my code, not only must I have Chrome installed, but I must be connected to Internet and trust that some particular domain, controlled by presumably Google, maintains it. I struggle to understand why no alternative debugger for arguably the world's most popular language exists, or at least a local, independent copy of the debugger that is untethered to the whims and desires of an entity as trustworthy as Google.

I guess I'll be having to whip up at least the latter option (which seems feasible enough, if a little tedious; with ungoogled versions of Chromium available by some kind souls as a starting point) when have a bit more spare time, to keep my sanity checked.

ntonozzi2• 3 years ago

WebStorm and VSCode both have OK debuggers, but in my experience they are even more finicky than the Chrome one, which as you noted does have issues. Firefox and Safari are likewise fine, but not as good as Chrome.

More importantly though, if you are that distrustful of Chrome, you probably should not be using Node because it is based on v8, the Chrome Javascript runtime.

qazxcvbnm4• 3 years ago

There are basic things to be desired with the current state of affairs, beyond the trust of Google, such as:

1) ability to debug locally, without an Internet connection.

2) ability to debug reliably, without fear of debugger features becoming 'updated' when one needs it most.

The fact that no independent debugger, without the Leviathan that is Chrome, exists, only hides this aspect even more, hardly doing justice to the importance of debugging in the practice of software.

Regards to the Firefox and Safari debuggers, they do not seem to be viable in practice with the alternative Javascript runtimes mentioned, both very popular and widely used, which is the reason that I claim Chrome DevTools to be the de facto 'Javascript debugger'. Neither do the two tools offer a debugger independent of the browser, as far as I am aware.

WorldMaker7• 3 years ago

I think Firefox's debugger is still extremely viable for web development. The Firefox Developer Edition even puts the Dev Tools nicely at hand in the toolbar and other places.

It can't help enough with Node or Hermes, but those are too tied to v8 and thus Chromium internals to start with. (Which definitely leaves some questions about the current JS monoculture.)

fulafel2• 3 years ago

Good article. There's of course editorial decisions about what to mention but still the in the Nobody part the JS-as-compile-target coverage seems a bit selective. There's of course ClojureScript, Elm, Scala.js, ReScript and TypeScript (the latter is mentioned in passing).

harha_• 3 years ago

I can't help but cringe when looking at the dependency count when using some javascript framework to write client-side code. I think the frameworks and the ecosystem is overly complex and the same could be accomplished by embracing minimalism. I do like things such as babel and webpack though, but those are dev-dependencies which is unrelated to the contents of the final bundle and I can live with few dev dependencies.

For my last project I wrote just plain old javascript without any frameworks, but I did use dev dependencies such as the ones I mentioned above. It was a breeze to implement things, but I do understand that the benefits of frameworks like React become clear in larger more complex projects. So all in all I don't really know what should I think about the current state of the ecosystem, nor am I really on the edge of the wave of progress, but the kind of feelings I often get is in the lines of 'is this dependency x really needed here? what does it do? oh it does this small little thing, why is it here??'...

ipaddr• 3 years ago

Wish we had something simple like jQuery

Etheryte• 3 years ago

I mean you can still use jQuery, no one's stopping you. They're still releasing new versions with updates, the last one came out two months ago if I'm not mistaken.

ilrwbwrkhv• 3 years ago

Just use mithril

potta_coffee3• 3 years ago

Vanilla Javascript is comfortable. I think I've pretty much given up on the JS ecosystem. I've been going back to web frameworks like Django / Rails / Laravel. Obviously not the solution for all things but most projects really don't need to be SPAs.

ilyt2• 3 years ago

I wouldn't call it delightful, I'd call it diaherra

psnehanshu• 3 years ago

Sounds like you haven't worked on a production javascript project yet.

AlchemistCamp2• 3 years ago

Less that 10 years ago, JavaScript sucked bad. It had no imports, no classes, no async, no arrow functions

No classes in JS was much better than with. As someone who used and contributed to CoffeeScript, I was initially excited by them but in retrospect, they've been a huge negative IMO.

Douglas Crockford saw it immediately: https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=300s

moron4hire3• 3 years ago

I'm so sick of these paradigm religious wars. There's nothing wrong with object oriented programming. There's nothing wrong with functional, either. You use them for different purposes. These people like Crockford who talk about "Java programmers are stuck in this inferior way" are the ones who are stuck and not all that educated on programming.

AlchemistCamp2• 3 years ago

There's also a lot to be said for having fewer footguns. One reason I liked CoffeeScript is that it actually removed JS footguns such as "with", ==, etc.

I'd rather either Clojure or Java to using Scala and having all the possible complexity and interactions between paradigms it makes possible. Sometimes less is more.

suzzer992• 3 years ago

Wait until you have to maintain someone else's overly crufty, inheritance-based JS framework.

lobstrosity4204• 3 years ago

They weren’t criticizing OOP per se. Before the class keyword, JavaScript had much more powerful OOP semantics using metaobjects.

hot_gril9• 3 years ago

Yeah, I write all my new stuff in JS (React frontend, Node backend) and have never felt the need for defining my own classes. Wasn't actively avoiding them either. React was fully centered around classes and they ditched all that in the new hooks system.

I also don't understand the big deal with arrow functions. Yeah I use them, but they're basically regular functions except slightly shorter to write. `async` was a big improvement, though.

jfengel• 3 years ago

Arrow functions have less-incomprehensible semantics of what "this" means. Though that's less important if you're not using the classes.

Most users just use arrow functions as syntactic sugar. But it's really good syntactic sugar.

suzzer992• 3 years ago

That just described how I feel about Typescript - created by Java programmers so that they can feel comfortable and not have to learn how to program in Javascript. I was a Java dev for a decade. It's so much more tedious and less fun than programming in Javascript. I get Java recruiting emails and I shudder.

I accept that in gigantic apps worked on by multiple teams, and libraries shared with 3rd parties, Typescript makes sense. But 90% of the time I see it used it's with a smallish node app or SPA worked on by a few people, and all Typescript does is slow things down.

I feel like I can count on one hand the number of times I've gotten burnt by a run-time JS bug that a compiler would have caught. I just don't see that as a strong use case for the overhead and development drag of TS. I only see sharing lib-ish code across teams as a net benefit of TS.

99% of the time when the TS IDE complains over something that a JS linter wouldn't have caught, it's just because something wasn't defined properly in TS, not because it's an actual error in the code.

toastercat4• 3 years ago

That just described how I feel about Typescript - created by Java programmers

Close! C# programmers. :)

okeuro492• 3 years ago

created by Java programmers so that they can feel comfortable and not have to learn how to program in Javascript.

Well... C# .Net developers, as Microsoft found, correctly, that you can't build complex products easily with a lack of types.

I also don't think many program in vanilla Javascript; it seems everyone is using JSX.

overgard5• 3 years ago

Typescript's type system is vastly different from Javas, and if you're using it that way you're missing most of the good parts.

The great thing is it's powerful enough that you don't lose JS's dynamic features, but your code becomes much more self documenting and clearer, and your IDE has a much better idea how to support you. I would never go back to vanilla JS, typescript saves me way too much time and from too many headaches.

WorldMaker7• 3 years ago

No classes in JS was much better than with.

I think you experienced a different JS than I did. JS has always had classes, they were just "harder" to build/use and every "Framework" had a different mixed bag of "utilities" and patterns to work with it and they weren't always compatible. (Mixing jQuery style classes and Dojo style classes was "fun", for two random examples. I could go on all day about the long tail from MOO Tools to YUI to Backbone to…) ES2015 class syntax just standardized already common patterns and increased interoperability and cleaned up a lot of footguns regarding Prototype-style inheritance along a "garden path".

The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced.

pier254• 3 years ago

The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced.

I agree. Honestly I don't understand the obsession some people in the JS world have against classes.

React components with state made more sense with classes than hooks. And yeah some people argue hooks are composable yada yada but if you need a React expert to write a useInterval hook to use a fundamental language feature, then maybe the model is not a great idea to begin with.

https://overreacted.io/making-setinterval-declarative-with-r...

Of course I know I'm in the minority here.

squeaky-clean2• 3 years ago

I got quite used to the prototype inheritance style Javascript and really liked it. But I don't think it scales across teams as well as modern JS or Typescript. But for a small project with just myself or a few other skilled developers? I'd prefer old-school style JS semantics.

schnable• 3 years ago

Well, that's one way to put it.

toastercat4• 3 years ago

I started writing a small static site generator for myself using JavaScript and QuickJS by Fabrice Bellard[1]. QuickJS is not quite complete, and there are some cross-platform inconsistencies, but overall I found it pleasant to use and its libc wrappers to be powerful enough. I also found that JavaScript is actually pleasant to use when I'm not using classes, or dealing with metaprogramming/Babel, or implicit globals. Dependencies are just pure .js files I keep in a /lib directory and import.

I still think JS is a nice language although I tend to side with Crockford (before he started promoting the "next" language) in that JS has some good parts, and you can write clean and powerful software with it if you ignore most of its warts (even if you're using Node). My best advice is be very careful with what dependencies you choose; and also, don't feel pressured to be at the bleeding edge all the time. The Node/React world is a constant hype machine that flip-flops on best practices every 6 months. Be very skeptical of them, and don't let them spoil JS for you.

[1] https://bellard.org/quickjs/

synergy20• 3 years ago

what's the use case for quickjs? can it be used for a light-weight runtime for JS on resource restricted embedded devices?

by the way, comparing to angular and vue2-vue3, react is actually the one without python2-python3-alike breakages over the years to me, I would say it's the best out of the 3 options(angular,vue,react) so far, which could explain by market share that it remains to be dominant.

schemescape2• 3 years ago

Not OP, but I experimented with QuickJS for my SSG and, on my super slow laptop, it started up about 200ms faster than Deno, but ran about 5 times slower overall (and the binary was much, much smaller).

My original motivations were: Deno doesn’t support Raspberry Pi and I was running lots of short-lived processes to support incremental rebuilds using a Makefile. In the end, my requirements changed, so I’m not using QuickJS, but it was very easy to pick up and use.

So: portability, startup time, and small code size seem to be the advantages of QuickJS.

toastercat4• 3 years ago

Yeah, the QuickJS interpreter is less than a megabyte compare to Node/Deno's >60MB or more install. My use-case was that I wanted something lightweight that I can run on lower-end hardware or in a CI pipeline to generate my site. At first I looked at bash, but I find bash gets unwieldy for more complex operations. I like JS as a scripting language, and QuickJS seemed to fit my YAGNI approach.

Indeed, React the library is generally stable. But React the ecosystem is not; best practices change every 6 months. Libraries gain popularity and then are abandoned, or people just realize the cost of using them. SSR vs SPAs? Wait you're telling me CRA is basically deprecated now? etc etc.

naikrovek• 3 years ago

not sure I'd call it "delightful" in any way, but it certainly is weird.

FpUser• 3 years ago

"Nobody Writes JavaScript Any More"

I code single page apps that talk to business backends using JSON based RPC. All in plain JavaScript with some domain specific libs when needed. No problems so far.

mattgreenrocks• 3 years ago

I've avoided JS/TS almost entirely, and shown contempt toward it a bunch in the past. I'm now at a place where TS seems like a reasonable language for prototyping backend stuff: JS has a GC, big package ecosystem, sum types, static typing, good tooling support.

Only thing that ticks most of those boxes (IMO) is Kotlin. Anyone been down this road before (skeptic->using in prod)?

hot_gril9• 3 years ago

I used to avoid JS then tried it for backend stuff, finding it actually the easiest way to do web backends. Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await. Then React Native instantly converted me from the horrible native iPhone dev, then got me into React (web). So I'll do new app projects fully in JS.

I also gave TS a serious try and found it pointless. Complicated the toolchain, made default stuff like the Node profiler not work anymore, and wasted tons of time on defining types that didn't actually catch any mistakes. Went back to JS. Turns out part of its strength comes from not caring.

Before that had used Java, Scala, C, C++, Erlang, Python, Swift, ObjC, Rust, PHP, and a little Golang.

yamtaddle6• 3 years ago

Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await

Async/await's pretty new, is probably why you're seeing so many tutorials that don't use it.

steve_adams_862• 3 years ago

Dart appears to tick some of those boxes, but probably not the big package ecosystem and sum types boxes. I'm considering building something with it at the moment, but I'm hesitant to commit much brain power to something Google has a lot of influence over. Yet, Go has been awesome and I don't regret learning it. In some ways, Dart looks a bit like what I wish TypeScript could be, though not exactly.

Something I use a lot in Rust is exhaustive matching and sound types, which Dart now has. It's a somewhat specific thing, but I like designing finite, well-scoped systems which can be handled and tested almost completely. Doing this in TypeScript is kind of possible but can be incredibly verbose and difficult to navigate for less experienced programmers. While the design patterns aims to simplify and eliminate errors, the type system can easily complicate it and introduce mistakes.

That's such a drag in my experience. For example, stuff like this can happen in TypeScript: https://www.typescriptlang.org/play?ts=5.1.0-beta#code/GYVwd...

However, TypeScript has come a long way and it gets better in this regard all the time.

philsnow• 3 years ago

I appreciate the summary of the changes in the javascript ecosystem over the last decade+; all of that happened after I had kids and I didn't have the motivation to keep up with it, so it's a complete blur in my mind.

I've tried at various times to get caught up, but it seems that every time I find articles / blogs that talk about How Things Are Done at the time they're written, with only the briefest nod to how it's better than The Old Busted Way (probably because the authors, being steeped in and surrounded by javascript for years, think that their readers will also be similarly up to speed).

Meanwhile, I feel like a historian in the year 5000, reading recipes from 2023 and wondering whether people used dog milk or cat milk (because those were the two kinds of mammals that most households had available).

Does anybody know of other resources that go into more depth on the evolution (and specifically the Whys) of the javascript ecosystem?

yCombLinks3• 3 years ago

"Modern Javascript for the Impatient" does a good job for the language itself. It doesn't try building on non-existent prior knowledge. It assumes you program, but in other languages.

crooked-v• 3 years ago

Weird? Absolutely.

Delightful? Try managing a monorepo with internal dependencies and multiple target platforms and you will immediately and firmly say 'no'.

karaterobot• 3 years ago

I like javascript, but I always think about the time when I was working as a front end developer, and a guy across the room suddenly stood up, walked over to the white board, and wrote "F*CK JAVASCRIPT" in massive letters. I believe his concern was around the lack of type safety (this was before we used Typescript). And this was someone not prone to dramatic gestures.

At the time I laughed. Guy must be having a bad day. Javascript rules, look at this widget I made.

Cut to a few years later. I am fed up with React, and the entire javascript ecosystem in general. The trend-based, article-driven development, the new framework/pattern you have to learn/unlearn every six months, the SPAS that made a simple web app spool up the user's laptop fan with all the javascript it was processing just to do basic stuff we could do much more simply in the 90s.

I ultimately quit being a developer in 2019, switched to doing design full time. I still write javascript for personal projects, because it's the thing I'm most familiar with. But, only vanilla javascript.

Javascript rules, but also: f*ck javascript.

leptons3• 3 years ago

a guy across the room suddenly stood up, walked over to the white board, and wrote "F*CK JAVASCRIPT" in massive letters
Guy must be having a bad day.

He was having a bad day because he was doing stupid things with the code he wrote that led to problems. I've never had a problem with Javascript's type system, or having the wrong type show up where it shouldn't. I accepted the dynamic nature of JS long ago when it first came out in Netscape, and I adjusted my coding style accordingly. And Javascript types are not a mystery, type coercion is fairly simple and doesn't produce unexpected results if you actually understand the language. If you don't understand the language (or any programming language), then writing things like "F*CK JAVASCRIPT" in massive letters on a whiteboard is something that might happen.

tstrimple• 3 years ago

I've never had a problem with Javascript's type system, or having the wrong type show up where it shouldn't. I accepted the dynamic nature of JS long ago when it first came out in Netscape, and I adjusted my coding style accordingly

Different languages have their own strengths and weaknesses as well as generally accepted coding practices and sometimes different paradigms. I find the folks who struggle the most are trying to write JS as if they are still a C# or Java developer so they constantly run into square peg round hole issues and blame it on the tool. I love JavaScript. I also love C#. But you've got to approach how you solve problems with them differently. How you write long term maintainable code in both is different.

krapp2• 3 years ago

Yeah, Javascript isn't even the only dynamically typed language out there, but you don't see people compiling strictly typed supersets of Python or Lisp because they consider those languages unusable otherwise. With any other language people are willing to learn the idioms and accept and work with the quirks, but for some reason Javascript alone seems to be the exception.

fulafel2• 3 years ago

There are lots of well-liked dynamic languages. But JS deserves the bad rap, it has so many WTFs in it's dynamic behavior and as a rule doesn't raise errors when things go sideways. Just painting it as a dynamic vs static thing is misleading.

ggregoire• 3 years ago

I am fed up with React, and the entire javascript ecosystem in general. The trend-based, article-driven development, the new framework/pattern you have to learn/unlearn every six months, the SPAS that made a simple web app spool up the user's laptop fan with all the javascript it was processing just to do basic stuff we could do much more simply in the 90s.

I must be living in a parallel world cause I write React & TypeScript code on a daily basis (among many other things, including writing Python and SQL too), I've done it for a few years now and I quite enjoy it. Last time I had to learn a new "pattern" was Hooks I guess, and it was like 3 years ago? I was hesitant at first, I didn't have any issues with class components... but Hooks actually increased my productivity and simplified my code. Otherwise I feel like coding in React hasn't changed much over the years. I would definitely not want to go back to the technologies I was using in the 2010s.

SkyPuncher• 3 years ago

I always find myself coming back to react.

Its so delightfully simple at its core. Typically super easy to debug. Extremely composable and reusable.

Kailhus• 3 years ago

I’m the same here. React with TS just makes sense as it is. We have a mix of class and functional components which can easily be understood. State lives here, logic goes there, render, done! It does become tricky when you start adding things to its simplicity like Redux, useEffects, useContext, useReducer, locationState, params, props, classes, StorageProvider (and the list goes on) without a clear standardized code guide for each scenario/patterns.

klabb3• 3 years ago

Yeah that’s right. I think a lot of JS devs are jumping on fads but it’s absolutely not a requirement. Just pick a couple of well supported projects for the stuff you really need and stick with it.

I’d much rather have some dependency discipline and a vibrant fast-moving ecosystem than the opposite. Just pick the fruit of other people’s labor when it’s ready instead of dogfooding questionable and bloated deps.

Oh yeah and do not read medium articles about JS.

madeofpalk• 3 years ago

the entire javascript ecosystem in general. The trend-based, article-driven development, the new framework/pattern you have to learn/unlearn every six months

Maybe it’s worth logging off Twitter for a while and understand that you can just not pay attention to these ‘trends’ and learn a new pattern every six months and you’ll be absolutely fine. Yes, ecosystems and communities can encourage this, but individuals also have got to take some responsibility for opting themselves out (or into) this hamster wheel.

I’ve seen this React Server Components stuff on the periphery for a while now, but I don’t really understand it and I don’t intend to for a while. I’ll let the twitter us hype beasts sort out what they want to do with it and I’ll circle back and check out what it’s like in a few years.

bigger_cheese• 3 years ago

My experience with javascript as a non-software developer/non web person has often involved frustration.

A good example is an experience I had a few years ago (circa 2018)

My work acquired some new software which published some results using a REST endpoint. I wanted to pass some parameters to the endpoint get a response and display the response on a webpage.

I'm used to working with Python/R and SQL databases it is relatively easy to write code in these languages to execute a SQL query and publish the result.

To do the same thing with endpoint I had to learn about ajax, asynchronous code, callbacks and then later deferred promises. What I thought would be relatively simple ended up being horrendously complicated to code.

I think part of the problem is the javascript language changes and adds new features so rapidly it is very hard to search google for help in my case I found code examples using callbacks, I had massive issues trying to make it work only to later discover that was old way to do it and the new way was to use Promises instead. Most of google searches I made went to horrendously outdated stackoverflow posts and there was no obvious way to tell if answer was best practice or not.

Doing the same google search again today in 2023 it looks like they have reinvented how to do it with something called "Await" now.

jdlshore4• 3 years ago

Await is just syntactic sugar for promises.

solumunus2• 3 years ago

You would find it even more difficult in almost every other language available.. What you're describing is simply the pain of learning a programming language with virtually no prior experience.

Maybe it's more simple in Python but this really isn't that complicated, it's certainly not a valid criticism of JS.

icedchai• 3 years ago

Sounds like a perfect use for jquery. You don't always need to use the newest framework.

boucher• 3 years ago

I think there's a small but growing group of people in the JS ecosystem that are beginning to explore a more "platform native" approach to front-end development, which removes the need for bundlers and transpilers and embraces the fairly capable feature set of most modern browsers.

As the OP points out, a lot of what happens now is an artifact of the history of how these things have developed, and about which things were prioritized over the years. Many of these choices made sense at the time but may no longer be necessary, and some things were definitely lost in the process.

When we were developing Cappuccino, which includes its own transpiled to JS language (possibly the first such general purpose language), one of our important goals was making sure the compiler could run in the browser itself so no external build tools were needed; everything worked just dragging index.html in the browser and writing code in <script> tags if you wanted. Security changes in how browsers handle file: URLs made this harder to do, but anything that simplifies the process of actually running code is very welcome.

koito17• 3 years ago

When a bundler/transpiler encounters an import statement, they don't necessarily presume that the file being imported is JavaScript or even any of the variants mentioned above. If configured properly and you want to import a CSS or PNG file, it will happily do so for you.

This is what I like to nickname "WebpackJS". Code that is simply invalid JavaScript and requires a carefully configured composition of webpack plugins in order to be used. I occasionally run into npm packages wanting to "import" a CSS file when I use them from ClojureScript, and it's always a pain. The good news is that these ar rare encounters, but it's still behavior enabled by people assuming you're using the exact same framework as them with the exact same Webpack configuration made by said framework.

iLemming• 3 years ago

Oh I hate that shit. It feels so broken. Someone creates "a library" in CRA or webpack, and then you can't just import it in your project easily.

apatheticonion• 3 years ago

Controversial opinion rant below:

I think the weirdness is a cycle kicked off and perpetuated by how accessible web development it.

It's a good thing that it doesn't take a comp sci degree to build a completely functional, professional looking and/or profitable JavaScript powered application.

In addition to the exclusivity of JS in the browser - the ease of becoming productive has been a large driving force of its widespread adoption. The cost effective nature (cross platform, ease-of-development, abundance of skill) has played a large part in its ubiquity.

This large number of developers has resulted in a large market for tool makers.

Tools are difficult to profit from, so toolmakers adjust their business models and marketing to suit.

As a result, a lot of developers write self promotional blog posts sharing "best practices" and plenty of impressionable decision makers dive head first into well marketed trendy tools/technologies that _may_ offer a benefit but often not proportional to their cost (vendor buy-in, additional complexity/reduction in project maintainability).

For example, front end projects tend to prematurely optimise with huge foundational features like SSR - without considering their use case, the performance trade offs (caching, amongst others) and other more ergonomic/cheaper/more effective, optimisations.

Despite not requiring it, developers tend to highly _highly_ couple their presentation logic to their application logic to the point where throwing away and rewriting an application is not an unreasonable sounding endeavour. People don't write an application that uses React, Vue, Angular - they write a React/Vue/Angular application.

The current meta has moved away from boring obvious procedural circuits to dense, clever, fancy functional circuits which I (controversially) find difficult to grok, modify, and debug. I certainly use functional code (like functional components are nice for simple use cases and .filter/.find are nice shortcuts), my feeling is that deep functional chains are perhaps overemphasised now and difficult to mentally simulate when reading (which you must do inside-out, holding each step in your head).

Testing is also a huge pain point. Developers tend to make extensive use of features like module mocking (`jest.mock('./filename')`) and avoid any form of dependency injection (not talking about DI frameworks, just simple property injection). If there is a hell, module mocks were sent to us from there. So many times I have made changes to a file where module mocks prevented tests that would otherwise have failed from failing. They are hard to track down, fail at runtime and... cries

Today, when I consider joining a new company and hear a project uses React, NGRX, Redux, Next.js, SSR, and a few others - I can almost immediately assume it's going to be a contribution and maintenance nightmare.

I still love front end even though it is an endless source of headache-inducing eye rolls watching people shoot themselves in the feet while confidently claiming it's the best way to run faster.

deterministic• 3 years ago

I think it is a big plus that the JavaScript community embrace code generators.

I mostly write C++ for a living, and I use code generators all the time. Generating C++/Java/Typescript/SQL/… from high level declarations.

Code generators are great tools for automating away the necessary but no-thinking-required parts of a typical app. I am typically able to code generate more than 90% of the application code needed to implement a new client/server business system. So why not use it?

The JavaScript ecosystem is delightfully weird

Related Stories