DEV Community

loading...

Discussion on: The Shocking Immaturity of JavaScript

Collapse
leob profile image
leob • Edited

The main problem (in my opinion), or one of the main problems, is that in JS land there are way too many options for doing anything ... the amount of "not invented here syndrome" and reinventing the wheel is staggering. And, I daresay, unproductive.

If you look at other languages (Ruby, PHP, Python) you see a lot more standardization around one or two major web frameworks (Rails, Laravel, Django) and their major add-ons or popular libraries. Yes it all does feel a lot more mature and less hype-driven.

I do love JS as long as you keep it simple. Best scenario? Use it only for the frontend (use something else for the backend), use Vanilla JS, no Babel, no bundlers etc (because huge amounts of time are spent just on configuring Webpack).

That's another pet peeve of mine regarding JS when compared with other languages like Ruby and so on - JS comes in a number of "generations", ES5, ES6, and so on, and you almost always need "transpiling" to do anything remotely advanced ... so they're selling you an "advanced" language, but you're being fooled because behind your back you're in fact running your granddad's dead ugly stone age JS ;-)

Long story short, I love JS as long as I can keep it simple and lightweight, meaning I don't need to pull in a gazillion node modules, and no transpiling and packing and whatnot just to achieve something basic.

Collapse
peppesilletti_4 profile image
Giuseppe Silletti • Edited

The software engineer should be the master of the tools, not the opposite.

I agree that the JS ecosystem could be overwhelming for beginners, and I may be wrong saying that's just because they haven't develop yet a strong engineering mindset that can help them make good decisions.

There are a good few libraries out there and who's been using npm for a while knows that.

Thread Thread
leob profile image
leob • Edited

Of course you're right - there are good JS libs and frameworks out there, but the problem is often there are too many ... "JS fatigue" and "JS churn" are famous for a reason.

With other languages and ecosystems I see more of an attitude like - okay we have a tool or framework here, it does have some issues, so how can we collaborate and work together to improve it? In the JS world it's often more like, "your framework or tool sucks, I know better - so I'm building my own!" - often more for glory and github stars, than for the benefit of the community.

And the result is often a huge amount of fragmentation and confusion.

Maybe I'm exaggerating, and my goal is not to bash JS (which in itself is a fine language, and which I like to use when appropriate), but I think you might say that in other communities/ecosystems there's often a more "mature" approach or attitude. Or at least it seems so.

Thread Thread
peppesilletti_4 profile image
Giuseppe Silletti • Edited

What you're saying is true, but it's not necessary a bad thing. It means that you have tons of resources and libraries you can choose from for your project. I'd say it's more flexible than using a framework that makes decisions for you.

It's a bit like using React vs Angular

Thread Thread
dbshanks profile image
Derek Shanks

It’s always evident when you have pro JavaScript devs who glorify JS and all the the things you can do with it. The typical ‘Maybe you’re wrong and I’m smarter than you attitude’ is why many tend to not discuss the problems of JavaScript.

JavaScript is overworked and overused within the web application and software realm. It’s terrible to sit through technical interviews and constantly be at disadvantage trying to remember all of the syntactical flavourings that JavaScript has to offer.

We rely on tools. JavaScript is over engineered and writes differently from library to library. ReactJS is a great example. Class based React components are barely recognizable compared to Hooks version.

I haven’t worked on a class based React project in a long time. During a recent technical interview I couldn’t recognize the older class patterns on the spot. Blew a hole right through my interview as I was out of practice on an older version of React.

I haven’t even discussed TypeScript. Which is just JavaScript with another syntactical costume on. Again, it does not write the same as anything else in the ecosystem.

I recently finished a project, ThreeJS, GSAP, React and Express. I was exhausted by the constant syntactical changes within each library. Import and exports alone were frustrating enough that I had to rewrite my webpack configuration so that my import / exports behaved in a somewhat predictable manner.

It’s a problem that needs to be acknowledged. Not ignored.

Thread Thread
yoonwaiyan profile image
Yoon Wai Yan • Edited

This is my favorite comment here. Developers are not to be blamed if something is not working out of the box. As a seasoned developer myself, I still stumbled upon breaking builds and had to spend many many hours to make things work in my local environment which could be used for much more meaningful work.

Collapse
vikkio88 profile image
Vincenzo

I think "having too many options" it is a problem, but it is a NICE problem to have.
Look at the ecosystem of C++ or GO, where the options are less, and the standards are less shared/agreed upon.

Thread Thread
leob profile image
leob

Well, theoretically "more" is "better", but sometimes "less is more" ... if there are many alternatives, but most of them are virtually the same (quality and functionality), then I'd argue working together on one product and improving it is the smarter choice - less waste, less confusion, better end result.

Thread Thread
vikkio88 profile image
Vincenzo

I don't agree with that, ultimately more choice means more flexibility, it is a bit counter-intuitive, I guess, but I think most standards are born when many people try to solve the problems differently then the best solution naturally becomes the standard de facto.

Forem Open with the Forem app