DEV Community

Cover image for What's the worst part about the JS ecosystem?
Francesco Pigozzi
Francesco Pigozzi

Posted on

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 πŸ™

Discussion (94)

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
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
leob profile image
leob • Edited

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

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

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 • Edited

@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

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

Thread Thread
pigozzifr profile image
Francesco Pigozzi Author

@peerreynders your comment is gold πŸ¦„

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

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

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

"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

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

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

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

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

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
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited

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.

Collapse
pigozzifr profile image
Francesco Pigozzi Author

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

Collapse
jmfayard profile image
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.

Thread Thread
pigozzifr profile image
Francesco Pigozzi Author

Thanks for your reply, very helpful!

Long live TypeScript! πŸ›‘οΈ

Thread Thread
jonrandy profile image
Jon Randy

I hate Typescript

Thread Thread
pigozzifr profile image
Francesco Pigozzi Author

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.

Thread Thread
jonrandy profile image
Jon Randy

Nah, it's definitely TypeScript for me

Thread Thread
pigozzifr profile image
Francesco Pigozzi Author

Lol, got it πŸ˜…

Future readers might find more details useful πŸ‘Œ

Thread Thread
peerreynders profile image
peerreynders • Edited

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.

Thread Thread
sharpninja profile image
The Sharp Ninja

Scheme

The language I hate even more than JavaScript. And that bull-crap about informally super-imposing a type system can be dried out and used for fertilizer. That is the same thinking that leads to databases where everything is a string and then the consumer has to figure out the correct pay to parse it.

Thread Thread
peerreynders profile image
peerreynders • Edited

Scheme

That paper was from 2004. In the meantime they acknowledge that "all those parentheses" can be challenging for some students. That is why Pyret was developed.

Support for static typing. Pyret will have a conventional type system with tagged unions and a type checker, resulting in straightforward type errors without the complications associated with type inference algorithms. We have carefully designed Pyret to always be typeable, but our earlier type systems were not good enough.

However:

Pyret has an optional static type checker.

So in terms of education static type checking is still being delayed.

See also Programming and Programming Languages


That is the same thinking that leads to databases where everything is a string.

They still deal with types (other than string) - they just don't use static typing from day one.


The language I hate even more than JavaScript.

Well that explains it then.

Most of the "coping techniques" outlined in "JavaScript the Good Parts" are about leveraging JavaScript's Scheme-y bits to maximum effect.

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

Collapse
nguyenan1201 profile image
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.

Collapse
pigozzifr profile image
Francesco Pigozzi Author • Edited

This is so sad yet so true

Collapse
rikschennink profile image
Rik Schennink

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

Collapse
michaelcurrin profile image
Michael

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.

Collapse
pigozzifr profile image
Francesco Pigozzi Author

This is the best comment so far πŸ¦„

Collapse
efpage profile image
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" }
}
Enter fullscreen mode Exit fullscreen mode

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" }
}
Enter fullscreen mode Exit fullscreen mode

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

Collapse
leob profile image
leob • Edited

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.

Collapse
michaelcurrin profile image
Michael

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

Collapse
peerreynders profile image
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

Collapse
andrioid profile image
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.

Collapse
blindfish3 profile image
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.

Collapse
patarapolw profile image
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.

Collapse
patarapolw profile image
Pacharapol Withayasakpunt • Edited
  • 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.

Collapse
ivanjeremic profile image
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?

Collapse
renanlazarotto profile image
Renan 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.

Collapse
stojakovic99 profile image
Nikola StojakoviΔ‡ • Edited

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.

Collapse
renanlazarotto profile image
Renan Lazarotto

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

Collapse
maxart2501 profile image
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...

Collapse
jonrandy profile image
Jon Randy • Edited

Over-complexity, over-engineering, too much tooling, too much emphasis on supposed 'convenience' for the developer rather than the efficiency or appropriateness of the solution(s)

Collapse
jonsilver profile image
Jon Silver

Then you've got the wrong developers. I pay my devs a lot. I want them to have every convenience precisely so they can concentrate on writing the best solution. Their time should be spent rapidly writing code that does a thing. We can create amazing application software very quickly using Javascript and React, with crafted user interfaces and high runtime performance. In this way we serve our customers well and give them excellent value for money.

Collapse
pigozzifr profile image
Francesco Pigozzi Author

What do you mean exactly? Could you provide some examples? Even some links and repos are welcome πŸ’ͺ

Collapse
devfranpr profile image
DevFranPR

I'm just starting from working with PHP and the worst part was de npm enviroment. There are SO MANY copies of the same packages and the npm UX is very improvable. Maybe is unexperience talking but it seems like the project building part is a mess with a long way to improve. What are the experienced devs take on this?

Collapse
pigozzifr profile image
Francesco Pigozzi Author

I've been working with JS for quite a long time but I feel the same problem: the package management system has room for improvement.

The main issue, though, is not the package manager itself but the easiness for anybody to publish their own fork of the same package that is slightly different and solves a very specific problem that the author is facing. Don't you feel the same? I'm wondering if the developers in the JS community have ever heard of pull requests on Open Source Software.

Collapse
jcayzac profile image
Julien Cayzac

package.json and require().

PNPM now has support for package.yaml but half of the npm modules insist on parsing a package.json, preferably with a JSON parser from the early 2000s that doesn't support JSON-with-comments or trailing commas. Just give us an import.meta.moduleInfo(packageName) to get the package information already.

require() is completely broken but at least it's almost dead now.

Collapse
jcayzac profile image
Julien Cayzac

What makes you roll your eyes up to the sky?

And yes, having to deal with JSON in 2021 keeps me up at night.

Collapse
fnh profile image
Fabian Holzer

The worst part is that the language is just too successful, so that folks who would much rather could happily dwell on PHP, Java, Cobol or whatever their particular pick of poison actually is, end up in its ecosystem and whine about it.

At least JS didn't need eight god-damned major versions to get first-class functions right. Brendan Eich could actually pull that off in ten days.

Collapse
jonsilver profile image
Jon Silver

The worst thing about the Javascript ecosystem is Typescript.
It was painful watching an experienced dev waste hours tinkering with code, not to craft software features, but to get rid of complaints from Typescript about mismatched types. Then watching as they sit looking aghast at their runtime type errors, in disbelief because transpile-time type safety should have saved them. And the sheer volume of code written... I'd rather they spent the time thinking about what happens at runtime, and thinking about writing well-composed, maintainable code that's self-documenting... Not jumping through syntactical or semantic hoops trying to satisfy some tyrannical software tool with its uphelpful, nonsensical error messages written by people who really shouldn't have been put in a position where they have to write error messages to help other devs.
As I've said elsewhere, my devs are high worth individuals. I pay them a lot. I want high productivity, so the customer's money is spent on crafting the features of their software solutions, not tinkering with the tooling. We develop things once and reuse massively. Typescript would just get in the way of all this. The way we do what we do is to employ properly educated devs who know how to use Javascript expertly to create exquisite business application software, and keep everyone up to date with current best practises and communicating well. Appropriate tools like IDE, linters and formatters look out for us and watch our backs. Code reviews are opportunities to learn and teach. In this way Javascript is made friend, not enemy.
Of course I'll get flamed for this by the True Believers, but I don't care. I do what I do backed up by decades of experience with commercial success. You should carrying on doing what you do and go in peace.

Collapse
sharpninja profile image
The Sharp Ninja

The language is horrible. It starts there, and all the crap is a direct result.

Let's be honest, when JavaScript was annointed the official language of the web, it had nothing to do with technical merit, and everything to do with not being Microsoft's first choice. VB Script isn't a great language either, but in 2000 it was wayyyyy better than JavaScript, and the language was mature enough to build enterprise applications on, not something that could be said of JavaScript until.... is it yet?

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) design to even worse implementations by the browser makers, it's amazing that anyone ever took it seriously. It's a testament to truly how much people hated Microsoft in the 2000's.

But the best part is that enough people have discovered how much of acrap-show JavaScript is that the most popular language to avoid directly writing JavaScript is from Microsoft. And to everyone who complains about complexity with TypeScript..... You could have had VB Script instead and life would be a lot easier.

Collapse
matjones profile image
Mat Jones

The language itself, more specifically, a super weak standard lib. Everyone installs an NPM package for everything. It’s a security nightmare.

Compare to, for example, the excellent standard lib of C#.

Collapse
michaelcurrin profile image
Michael

If I'm allowed to pick a minor thing as a second answer...

I don't like the naming with an extension.

Like Node.js

It is not the name of a file.

react.js, vue.js, next.js... is not the name of a file. Well maybe sometimes but usually it is vue-1.2.3-esm.js or whatever as a long name

So why add extension?

We don't call it pandas.py, requests.py or grails.jar or rails.rb in other languages. Yes Python packages have Py names sometimes like Pygame or Numpy but that is fun and artistic and doesn't go to extension level.


And Node and Node.js and NodeJS are all (sort of) correct spellings.

And some say Node dot JS aloud. It sounded so verbose on NextConf for the presenters to say Next dot JS all the time when it is clear from the context and "Next" would be fine.


Typing "next.js" is the common way for packages while "DocsifyJS" is the preferred way of some packages like in Docsify docs.

Collapse
michaelcurrin profile image
Michael • Edited

What bothers me is JavaScript (aka EMScript aka ECMAScript) has no truth in a single version.

In Python, Java, etc. you and I can say that we have version 3.4.5 installed on our machine and we know it will give identical results. (Maybe some architecture differences or OS implementation differences but that is for any language)

While JS is standards or specifications, right? So when a new feature comes out in say ES6, then every browser and mobile browser has to go and implement that feature. And some diverge and never add a feature that the others do or blaze a path of a feature that no one else adds to their browser.

I mean it's an issue with CSS too I guess.

Plus there is the difference of what ES6 / ES2015 for example does in my browser vs in Node 12 or whatever and Deno 0.x

Collapse
drsensor profile image
DrsEnsor

The fact that most of the time classes and plain objects are not tree-shaked nor minified really irk me. Hopefully tscc/tsickle can solve this problem but still it's slow solution and require JVM.

And what Deno said in their docs is true. There is a need a new kind of Typescript compiler that fully use the type annotation to reduce the bundle size.

Collapse
ats1999 profile image
Rahul kumar

var

Collapse
pigozzifr profile image
Francesco Pigozzi Author

Could you argue more your opinion? Otherwise it might feel pointless to other readers πŸ“–

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited
Collapse
tamusjroyce profile image
tamusjroyce • Edited

None. npm is the ecosystem. And Deno fixes it.

As deno gains support, parsel, Babel, and snowpack will get rewritten into rust and tied into deno native speed improvements. Deno sis written in rust and can connect to rust. Deno can access gpu for speed up. It can run web assembly. And so can the browser.

Collapse
youurt profile image
Ugur Tigu

Var.

Collapse
unm4sk1g profile image
Marijo Šunjić

npm ecosystem.

Collapse
jankapunkt profile image
Jan KΓΌster

Hype Driven Development

Collapse
ghostmech profile image
Gary Howard

The ridiculous number of packages npm installs. I have NO IDEA what could be in there, besides my desired package. Vulnerabilities? Ok, glad to know but that side wastes time resolving.

Collapse
sankarmano89 profile image
Sankar Manoharan

Daily one new JS frameworks born. Job opportunity is also based on the current trending JS frameworks. That's not good for the community.

Collapse
proco profile image
Eduardo Ortega

Having a new framework every 5 mins.

Collapse
peter_brown_cc2f497ac1175 profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Peter Brown

The worst part about programming in javascript is dealing with javascript programmers. More than any other developers, javascript developers tend to be very uneducated on even the most simple computer science concepts. Many of the problems in the javascript community have been solved a 1000 times over by other languages but due to the ignorance of the community at large, the problems remain.