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.

Thread

Thread

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)

Thread

Thread

Thread

Thread

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.

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

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.

Comment button Reply

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

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.

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.

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

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.

Comment button Reply

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?

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?

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.

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.

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)

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.

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

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.

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

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.

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