What's the worst part about the JS ecosystem?

Photo by m wrona on Unsplash

Seriously, give me your honest opinion and save any rant: what's the worst part about being a developer in the JS ecosystem? What makes you roll your eyes up to the sky? What makes you wondering if you've chosen the right developer career?

Also, most importantly:

What would you change, if you could?

Let me know in the comments 👇 or just leave a 🦄 and share this discussion 📣

Thanks for reading 🙏

Comments

[leob]

The fact that you need a complex build process (Webpack, Babel) to be able to utilize newer features/versions of the language ... Webpack and Babel are products of a genius, but what would be absolutely gold is if we wouldn't need them anymore.

(what other language requires you to learn the intricacies of a complex build tool like Webpack in order to use modern versions of the language? any other language you can mention - Python, Ruby, PHP, you just install the latest compiler/runtime and there you go)

[Francesco Pigozzi]

I wouldn't say that you need those build tools to support newer features: I would rather say that you need those build tools to support older browsers and engines, what do you think?

Anyway, I'm with you: the amount of extremely complex tools around the ecosystem doesn't make it easy for newcomers. Also, by hiding such configurations and tools behind something like react-scripts is not good as well: too many times I've seen junior developers thinking that JS is able to do something that instead it's being done under the hood by some Webpack plugin.

What are your advice? What would you change, practically speaking?

[leob]

Well the problem (at least the Babel part) would go away once 95% users run browsers that natively support ES6. That way at least we'd know that our end users would really run our shiny ES6 code, instead of grand dad's old fashioned ES5 (the transpiled) version - to me this process always feels a bit comical, like we're collectively fooling ourselves. So in a matter of a few years we might at least not need Babel anymore!

But, the funny thing is that Typescript is becoming ever more popular, so we'd still need transpilation. But, what if the TS compiler would be able to do the whole thing - transpilation and bundling (including source maps, minification, and so on), and we wouldn't need Webpack anymore on top of that - now that might be a real step forward in terms of reduction of complexity.

Oh, and what if Web Assembly would take off - that would also be a solution, we'd simply choose our favorite programming language and use that, who needs JS lol.

[Francesco Pigozzi]

I once complained that an experienced Java developer told me that Js is a disposable language: "any JS engine is a LLVM, I can write in it with whatever language I want". I couldn't understand him at the time, what a junior dev I was...

I'm with you though: I hope for TypeScript to improve its learning curve so that it can become the de facto standard for this field (but this is another story); I can't also wait for WebAssembly to become widespread enough in order to rewrite everything in Rust 😈

[leob]

Exactly ... Web Assembly and Rust FTW ! and then TS as an intermediary thing or a stepping stone.

JS is just weird in that you're writing shiny new and slick ES6 or ES7, and then what gets actually run is often mundane old ES5 lol.

[Phred Lane]

To be fair you're writing Rust, but what actually gets run is often mundane old assembly. It's all just layers of abstraction.

[leob]

Yes but the difference is that ASM is fast, that's why we're compiling Rust (or C++ or whatever) down to ASM rather than interpreting Rust ... but ES5 isn't faster than ES6 (neither the other way around) - we gain no performance from the transpilation, that's why it always feels a bit more to me like a trick or like we're fooling ourselves a bit, just so that we're can get that warm fuzzy feeling by being able to write "let" or "const" instead of "var" (okay, I'm being cynical here). In other words, if I'm brutally honest it's more about programmer convenience than about performance (unless ES6 can be executed natively by the browser's JS engine).

[peerreynders]

Well the problem (at least the Babel part) would go away once 95% users run browsers that natively support ES6.

Even these days public serving web sites should be practicing differential serving:

• Differential Serving
• A Universal Bundle Loader

That way most browsers will be served a ES2017 bundle while legacy browsers have to deal with the larger ES5 bundle with its polyfills.

The root of the problem is that the web isn't a universal, monolithic platform but an infinite continuum of platforms. That is likely not going to change.

Oh, and what if Web Assembly would take off - that would also be a solution, we'd simply choose our favorite programming language and use that, who needs JS lol.

I wouldn't hold my breath.

WebAssembly:

It is also designed to run alongside JavaScript, allowing both to work together.

And languages that require separate multi-megabyte run times aren't going to succeed outside of niche applications - JavaScript doesn't have to ship a separate runtime and Web APIs are all designed with JavaScript in mind. So really C/C++, Rust and perhaps AssemblyScript are the only real contenders for solutions with a broader market but I'd expect "productivity" to take a serious hit.

Given the Mobile Performance Inequality Gap, 2021 a JavaScript payload can be more effective in most cases - as long as it doesn't drag half of npm with it.

[Michael Currin]

@leob code in ES5 will be slower than ES6 because it is more code to execute. I came across this. So to support 1% or 5% or whatever of legacy browsers you make speed and file size worse for everyone

[leob]

Interesting!

[Michael Currin]

Sorry corrected my typo. ES5 slower than, not in.

[Francesco Pigozzi]

@peerreynders your comment is gold 🦄

[Julien Cayzac]

Webpack and Babel are products of a genius, but what would be absolutely gold is if we wouldn't need them anymore.

Good news, they aren't needed anymore! Use Rollup and ESBuild and reduce your carbon footprint :)

[leob]

Haha, heard about those, instant Webpack lite without the hassle ... but do we need to use ESBuild and Rollup? I understood that ESBuild is the speed king, can we dispense with Rollup?

[Julien Cayzac]

esbuild compiles typescript and bundles javascript. You need rollup if you want to bundle anything else.

[Jean-Michel 🕵🏻‍♂️ Fayard]

JavaScript.

The community has done an heroic job of building useful things on top of it, defying the "house built on sand" fate, but I still wish the language itself had not been rushed in ten days in the early days at Netscape.

[Francesco Pigozzi]

So, basically the main problem of the JS ecosystem is JavaScript itself? What are the biggest struggles you face when working with it?

[Jean-Michel 🕵🏻‍♂️ Fayard]

If you open "JavaScript the good parts" you will find two chapters that summarize that well

• Appendix A. Awful parts
• Appendix B. Bad parts

And the lack of types, and here thanks Microsoft for Typescript, I hope schools don't teach vanilla JavaScript anymore but skip to Typescript. I strongly dislike giving beginners bad habits of working without types.

[Francesco Pigozzi]

Thanks for your reply, very helpful!

Long live TypeScript! 🛡️

[Jon Randy 🎖️]

I hate Typescript

[Francesco Pigozzi]

I used to think the same but I realised I wasn’t hating TypeScript: I was hating its lack of good documentation, its unjustified complexity and its learning curve for newcomers.

The hatred decreased with the increase of my knowledge and now, it’s hard to admit it, I can’t use plain JS anymore even with the easiest pet project.

[Jon Randy 🎖️]

Nah, it's definitely TypeScript for me

[Francesco Pigozzi]

Lol, got it 😅

Future readers might find more details useful 👌

[peerreynders]

If you open "JavaScript the good parts" …

Douglas Crockford, JavaScript - The Good Parts, 2008; p.2:

JavaScript is most despised because it isn’t some other language. If you are good in some other language and you have to program in an environment that only supports JavaScript, then you are forced to use JavaScript, and that is annoying. Most people in that situation don’t even bother to learn JavaScript first, and then they are surprised when JavaScript turns out to have significant differences from the some other language they would rather be using, and that those differences matter.

The bulk of "JavaScript the Good Parts" (before those appendices) was about dealing with JavaScript successfully on its own terms - which relied heavily on leaving behind any preconceived notions carried over from other programming languages.

---

I strongly dislike giving beginners bad habits of working without types.

On the surface the argument to start with a statically typed language for the sake of "safety" makes sense but people who have dedicated their career to computer science education have come to a different conclusion; The Structure and Interpretation of the Computer Science Curriculum:

The lack of a type system means that we don’t have to spend energy on finding and explaining type errors with the same care with which we explain syntax errors. Better yet, when we use Scheme to teach design principles we can informally superimpose a type system and use the types for program design. In particular, it is easy to define and use sets and subsets of Scheme values. This comes close to students’ intuitions about classes and subclasses in object-oriented programs and thus provides a good transition for the second course.

I haven't noticed that TypeScript compels people to actually think in terms of types which is the important part of program design. Just like working with an OOP doesn't teach OO, working with types doesn't automatically foster thinking in types. Dynamic typing doesn't impede thinking in types.

---

Future readers might find more details useful 👌

I left my take in this comment earlier this year.

[Phred Lane]

Ignorance/lack of knowledge.

Lots of people know jQuery, React, Vue, etc., but they don't know JavaScript itself. If you take away their library, they would be lost. They don't understand how React works and why it's useful. They don't know how and when to use different strategies and methods, because they lack the understanding of how those things work under the covers.

[Francesco Pigozzi]

This is so sad yet so true

[An Nguyen]

I wholeheartedly agree. I'm myself was and still is the person mentioned above. When I got into frontend I never emphasize on learning Javascript but j just use it as I learn jquery, react, node.

[Rik Schennink]

The constant fighting over everything and anything. Just let everyone use what they love and focus on building cool stuff.

[Michael Currin]

Oh yes it gets heated. Everyone thinks there tool is best. In a Vue vs React post, the argument went that the one that was slower to get features was annoying while others said that this very slowness is a benefit because it gives security and stability

Let people choose Ubuntu vs Debian or nightly vs stable release. I wish people did not assume their needs and preferences are the same as others.

[Francesco Pigozzi]

This is the best comment so far 🦄

[Andri]

Dependencies, and more specifically: Invisible dependencies.

For any medium sized project, node_modules has everything you needed, everything those packages needed and so on.

In the end, we’re depending on code we didn’t even know we’re using. What’s worse, these 3rd party dependencies can conflict with your own and can be a real horror show to upgrade and keep up to date.

[Eckehard]

There are lot´s of complains about the use of "this", which give people some headaches. For me, the worst thing about "this" is the use in classes. As any class variable and any class function is bound to "this", code inside a class is peppered with hundreds of "this".

On the other hand, function definitions inside a class do not need the "function" identifier. Writing longer class definitions you often get los to know, what precise class you are working on. I just started to add the class-name as a comment:

class test{
    myVar
    /*test*/myMethod(){ this.myVar = "Hello world" }
}

It would be far more handy to have any class method clearly be part of the class like

class test{
   let myVar
   test.myMethod(){ myVar = "Hello world" }
}

This yould also allow to shift some code into a class without the need to rewrite anything.

[leob]

In my view this, prototypal inheritance, constructors, and most of "classical" OO in Javascript is simply better avoided when designing new JS code. I much prefer a more FP (functional programming) style approach. Use objects, but just put data in those objects, then write functions that take in those objects as arguments and do something with them.

I know that almost every introduction about Javascript starts talking about this and about prototypal inheritance, but IMO it's a load of historical baggage that's confusing and almost always unnecessary. Just look at contemporary React (with function based components and with hooks, but without classes) and you can see that we don't really need classical OO, "this" and prototypal inheritance.

(use functional components and hooks in React and you'll almost never have to write "this")

Plain objects and functions get you there 90% of the time, prototypal inheritance is historical baggage. Javascript (especially ES6 with arrow functions, destructuring and so on) is a cool language, simply don't use its legacy features, that's all just cruft.

[Michael Currin]

Yeah this works differently in function and arrow function (not allowed in latter I think).

I found a video which explained this and there are some many cases where it behaves weird.

And then you assign var _this = this to get some context frozen...

[peerreynders]

there are some many cases where it behaves weird.

Don't expect JavaScript's 'this' to be a 'this' that you are already familiar with.

It's its own thing.

xkcd

[Ben Calder]

People who complain about the JS ecosystem...
Sure there are some flaws; but I'd love to hear what 'ecosystem' doesn't have any.

[Pacharapol Withayasakpunt]

I complain more about Python though.

To me JavaScript is not so bad, although there are some major flaws. I will type later.

[Pacharapol Withayasakpunt]

• No warning on bad arithmetic, nonsense type coercion, e.g. [1, 2] + [3, 4]. I sometimes did this, coming from Python. And, left-side type coercion?
• No real Array data type. No IndexError on bad insertion.
• No integer. To use with Array, for example.
• Prototype-based inheritance is confusing; and I am not sure if it is even recommended.
• Over-engineering - why make a class that is based on Prototype? Object.create()?
• Threading is very recent, and is just actually fork or equivalent to iframe.
• Non-specific try-except. Actually, you should always specify the Error type.
• Diversification of standards. Browser-side and server-side are very different.

There is TypeScript, but it also has a fair share of love-hate as well.

[Ivan Jeremic]

JavaScript needs an official compiler, projects like webpack, typescript, rollup, babel should come together and create under ECMA an official compiler, goal should be compile to targets like old browsers/node versions and directly to wasm. The ultimate goal should be no difference between browser and Node + rebranding of JS call it "Node" maybe?

[Renan "Firehawk" Lazarotto]

Everything from start to end. The tooling is a nightmare for those of us that wasn't into front-end development when Angular, React, etc, came to light. Nowadays, every single goddamn tutorial takes for granted that you already know how NPM works, it just goes to 'hey, install this, put this code there, bam, your todo app is done!' without actually properly explaining whats going on. It took me 6 months to understand how importing JS packages works, and why I don't need any kind of autoloader of whatever, like pretty much every PHP framework does.

Promise, async and await are also another nightmare that is so bad explained that only today I finallly got a small grasp on how they work (thanks to this article dev.to/zackdotcomputer/i-promise-y...), but I'm still confused about their usage and everywhere I look, things got more complex instead of breaking down each concept first before you start doing any actual code.

There are still lots of stuff that works by black magic hidden under a stone set aside a tree in the middle of the nordic forest on Kepler-10c. It just works, but how?

And please don't get me started on node_modules. That is ridiculous, an atrocity, and I wish that whoever came up with this got fired and was never allowed to touch, get close, stand nearby or even talk about any computer, ever again.

[Nikola Stojaković]

And please don't get me started on node_modules. That is ridiculous, an atrocity, and I wish that whoever came up with this got fired and was never allowed to touch, get close, stand nearby or even talk about any computer, ever again.

This is actually one of the things Ryan Dahl, creator of Node.js, strongly regrets about Node.js.

youtube.com/watch?v=M3BM9TB-8yA

It's also one of the reasons why he built Deno.

[Renan "Firehawk" Lazarotto]

Really? Interesting, even the Node creator dislikes node_modules! I'm watching his talk now, thanks for that!

[Massimo Artizzu]

Hi there, pigoz!

... I think it's the usual stuff that affects big, large, and in this case immense communities: latent toxicity from some members, who don't lose time to spew vitriolic remarks and uncostructive comments towards this or that library/framework/specification/tool. We really, really don't need that 😫

As the language per se, it's mainly fine. I wish we had, you know, types but it seems that TC39 is fine with the current situation of transpiling everything. Which is strange, since they gave us so many things to let us use module directly. In practice, we still create big bundles...