DEV Community

Discussion on: What's the worst part about the JS ecosystem?

Collapse
leob profile image
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)

Collapse
jcayzac profile image
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 :)

Collapse
leob profile image
leob • Edited on

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?

Thread Thread
jcayzac profile image
Julien Cayzac

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

Collapse
jfbrennan profile image
Jordan Brennan

Depends on if you're willing to support older browsers. If you're building something new, I'd suggest never crossing that line. We have to save the web by breaking it ;)

If what you want to use can be polyfilled, I highly recommend polyfill.io/v3/.

Collapse
pigozzifr profile image
Francesco Pigozzi Author

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?

Collapse
sharpninja profile image
The Sharp Ninja

you need those build tools to support older browsers and engines,

Bingo! And there's your problem. When a new version of JavaScript is formalized, the runtime should come with it. Then the browser should load the runtime as a module. Now, you don't have "legacy" versions of JavaScript holding you back. But every attempt to use a pluggable scripting engine has been stopped cold by Google.

Thread Thread
leob profile image
leob

I can sort of understand why they're blocking that - bad experience in the past with Flash and Java and other browser plugins (security issues) ... they don't ever want browser plugins anymore (and to be honest, not just them, is there anyone who's really enthusiastic about the idea of bringing back browser plugins)?

Thread Thread
sharpninja profile image
The Sharp Ninja

Silverlight was never a problem, but was swept up in this movement. Flash and Java were deservedly blackballed, but they threw the baby out with the bath water to force reliance on Google's desires as the dominant browser vendor. And Google could easily encapsulate V* in a way that it upgrades independent of Chromium and would be a dependency of Chromium and not part of it. Then, as long as backwards compatibility is maintained, V8 can upgrade independent of the browser.

Thread Thread
leob profile image
leob • Edited on

Right ...

On a tangential note, I always find it so comical that, way back when, Oracle paid billions to acquire Sun Microsystems, not because of their great high tech (SPARC chips and Solaris OS), but because "Java is installed on a billion computers" (that was the silly Java plugin which almost nobody used, and which everyone hated) ... they really believed Sun's marketing mumbo jumbo ;)

Years later Oracle killed SPARC, then Solaris, then Java EE, and then they wrote off the last remaining bits of their failed astronomical investment ... utter incompetence of the "suits" in higher management.

P.S. I'm not a Java hater, it's a great language for the backend and it's utilized heavily for big enterprise systems, it's sort of the new COBOL, but on the frontend it was always a bit of a joke, and the biggest joke of all were Java Applets, what an epic failure that was ;)

Thread Thread
sharpninja profile image
The Sharp Ninja

The problem with applets and flash was the lack of a proper sandbox. Silverlight had that, and WASM does as well. Microsoft and Linux also both have the ability to sandbox the browser itself (and any app for that matter), preventing anything from escaping into the OS. But these OS-level sandboxes remove Google's argument that everything must be native to the browser and thus diminishes the value of their V8 JavaScript runtime, which is the real root of Google's power on the web.

Thread Thread
leob profile image
leob • Edited on

Java for sure had a sandbox, the security model is documented extensively, based on (among others) the infamous "class loaders" (I was a Java dev in the past, so then you get to learn about all that obscure shit).

But for some reason their sandbox was leaky, apparently. Maybe they just had more competent programmers in the Silverlight team?

The V8 JavaScript runtime is the real root of Google's power on the web, I wasn't aware of that! I believe you, although I can't really deduce why that is so.

Thread Thread
sharpninja profile image
The Sharp Ninja

There's too much for a comment. Here's a full response.

dev.to/sharpninja/google-s-grip-on...

Thread Thread
leob profile image
leob

Cool!

Thread Thread
leob profile image
leob

P.S. I tried to post a comment on your article but strangely couldn't, persistent server error ... so let me post it here instead:

Interesting! but should we call Google "evil" for pursuing this strategy?

I don't think so ... every company tries to optimize their profits, it's natural and it ain't evil by itself - but the outcome of what Google is doing is to further the open Web standards (based on HTML, CSS, JS) at the detriment of the proprietary "plugins" like Flash, Java and Silverlight ...

That's progress in my book, in the end the open Web as an application platform (even though not perfect, but then what is ...) means we all win in the end.

Thread Thread
sharpninja profile image
The Sharp Ninja

Evil is based on intention, and the acts of Google along the way to getting where we are were filled with greed and malice from those in command. And the open web standards are not virtuous just because they are open. They should also be good technologies, and the trio of HTML, CSS and JavaScript epitomize horrible technology. Throw in their cohorts such as REST, JSON and OAuth and there's another set of bad ideas run amok.

Thread Thread
leob profile image
leob • Edited on

"The trio of HTML, CSS and JavaScript epitomize horrible technology", that's rather stark, why do you think so? Sounds like you're not a fan of the web platform, what's the alternative then, we need to code all our apps with Silverlight or what?

Thread Thread
sharpninja profile image
The Sharp Ninja
Thread Thread
leob profile image
leob • Edited on

Right, I've read similar proposals before to keep the internet (TCP/IP), but to replace the application platform / content delivery platform (the Web) that's running on top of it - i.e. to replace the Web with a "better" platform ... what do you think realistically speaking, does this even remotely stand a chance? That ship has sailed a long time ago, the web is what we've got, for better or for worse (and I think it has a lot of good things to offer).

Thread Thread
sharpninja profile image
The Sharp Ninja

There are many companies and industries that Google doesn't dominate, yet. Amazone, Disney, Netflix all come to mind as companies that currently have tons of expense supporting a mixture of apps and web that would benefit greatly from my approach. A second tier to consist of Walmart, Target, Tesla, SpaceX where they're dependency on web technologies create risk for them, but their brick-and-mortar presence provides some buffer and opprtunity to play in the disruption space.

Thread Thread
leob profile image
leob

No idea really, but what do consumers use? web browsers, and mobile apps (Android and iOS) ... I don't see how that's going to change. Standards are good in my opinion, even when they're not perfect.

Thread Thread
sharpninja profile image
The Sharp Ninja

There's a difference between "not perfect" and outright bad, and HTML and JS are outright bad, CSS is workable. But there is nothing stopping the W3C from declaring anything a standard except Google, which obviously would fight such a change.

Thread Thread
leob profile image
leob

Well, you're pretty outspoken to put it mildly, and with an opinion that I think is at odds with what 95% of devs are thinking ... interesting discussion, to be continued!

Thread Thread
sharpninja profile image
The Sharp Ninja • Edited on

95% of WEB devs, not devs. Most non-web-devs hate web dev with a passion for the reasons I listed.

EDIT: To expand on this. Web Devs typically have no idea how anything in the web dev stack works or the amount of scaffolding in place to hold up their house of cards. Once they are brought in API development they discover the shortcomings of Node the hard way. At that point they can give up and go back to web dev, or learn about why Node sucks and why the alternatives are much better. Once you cross that threshold it's very hard to go back to web dev and on continually ask why they are putting up with this crap. But until you break out of web dev and learn about concurrency, garbage collection and strong typing, you simply don't know what you don't know.

Thread Thread
leob profile image
leob • Edited on

I agree that node.js isn't ideal, but hey, to equate node.js with "web dev" is a bit misleading isn't it? There are dozens of platforms for doing web development (backend).

Also: "95% of WEB devs, not devs" => okay, but the large majority of devs are now "web devs", maybe not 95% but well, probably like 75% - so still "the majority of devs"

And: "Most non-web-devs hate web dev with a passion" => that's a bold (and subjective) claim, can you back it up with facts? I rather think most non-web-devs are neutral, or even mildly positive, and are MAYBE even using it themselves occasionally ;)

And finally: "for the reasons I listed" => I haven't seen any clear reasons mentioned anywhere, have I missed them?

You can program in a backend language with strong typing and still be doing web dev, I've done Java for years and considered myself a web dev (or at least a "web dev" among wearing a number of other hats) most of that time, so I don't see the artificial divide you're trying to put up.

Thread Thread
sharpninja profile image
The Sharp Ninja

I haven't seen any clear reasons mentioned anywhere, have I missed them?

From this thread: "From the horrible language (which requires an overload of the equals operator to pick what kind of comparison you should make, and then choosing the odd-ball operator as the correct choice)"

And over the years I've posted many articles on many mediums about ways that JS sucks, but even without going into specifics, its type system is so fundamentally broken that it cannot be fixed without starting over. The module systems (plural!!!) are so convoluted and incompatible that you cannot use valid modules of the same version with itself. Then there's the fact that it's so sctrictly single threaded that when it pretends not to be you can easily deadlock yourself by using recursion.

Thread Thread
leob profile image
leob

I was about to start arguing again lol but I do have to admit you have a point here. Look at the mobile ecosystems (Android and iOS), where there's a clear market for native client apps which aren't web based, but which use web tech (HTTP, JSON and so on) to communicate with the backend.

So yeah I'd say use HTTP and all of the web standards on the backend (and in MOST cases do NOT Javascript or node.js there, use a proper language) but for the client I'd argue we should have more choice than just HTML/JS/CSS. Something like the iOS or Android app model but then for the desktop.

P.S. on a tangential note, you're clearly a Microsoft fan but I'll never forgive them their monopolistic practices of the 90s, which included threatening PC manufacturers if they'd dare offer Linux on their hardware, or anything non-MS. I have to say they've changed a lot and they sing a different tune now, but the days of Steve Ballmer were horrible (and so was Windows back then).

Thread Thread
sharpninja profile image
The Sharp Ninja

Here's the thing, Microsoft got better. JavaScript hasn't. And the reason you see so much REST in mobile is they dumb down the service layer to avoid having to support different ones for mobile and web. The reality is that gRPC and SOAP aren't JS based, so WebDevs actively work to prevent their usage.

Thread Thread
leob profile image
leob • Edited on

LOL "WebDevs actively work to prevent their usage" ... conspiracy thinking much?

I've worked plenty with SOAP but never liked it, TBH hated it, like pretty much almost everyone else I knew. You know, those corporate and proprietary "standards" tend to be over complicated, over engineered, feel like "designed by committee" and are terrible to work with.

The open web standards though are simple, easy to work with, and are sufficient in 95% of the common scenarios, that's why people like them. In case you need more sophisticated, you step up to GraphQL.

Microsoft got better yes, mainly due to their leadership, Satya Nadella is lightyears ahead of what Steve Ballmer ever was, it's like the evolution from the chimpanzee to Homo sapiens. And they (Microsoft) finally embrace open standards and aren't actively trying to sabotage them (remember IE6/7/8, ActiveX, JScript?)

MS also abandoned Silverlight, and embraced HTML5, JS, CSS ... so ironically your "heroes" have started to bet on and embrace the platform that you dislike.

Seriously though, I fully admit that the web was conceived as a platform for content delivery - it was never designed or meant to be an application development platform - a lot of it feels bolted on, even though arguably a lot of effort has been put in to improve it as an app dev platform (of course it's not true that JS hasn't made any progress).

That's why I made the comparison with mobile ecosystems (Android and iOS) with their native client apps, and wondered why a similar development hasn't taken off on the desktop - web for content delivery, native apps (connecting to backends via web technologies) for apps.

Oh and by the way - if you despise Javascript as a language (and even Typescript, conceived by MS) then there are plenty alternatives (all of which "compile" to JS, so that you don't have to write that): Elm, Dart, ReasonML (the last one is really interesting and I'd expected it to take off, but it hasn't) and others ... so I'd say that you can hardly use the weaknesses of JS as an argument against "the web".

Collapse
leob profile image
leob • Edited on

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.

Thread Thread
pigozzifr profile image
Francesco Pigozzi Author • Edited on

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 😈

Thread Thread
leob profile image
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.

Thread Thread
fearphage profile image
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.

Thread Thread
leob profile image
leob • Edited on

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).

Thread Thread
peerreynders profile image
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:

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.

Thread Thread
michaelcurrin profile image
Michael Currin • Edited on

@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

Thread Thread
leob profile image
leob

Interesting!

Thread Thread
michaelcurrin profile image
Michael Currin

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

Thread Thread
pigozzifr profile image
Francesco Pigozzi Author

@peerreynders your comment is gold 🦄