DEV Community

loading...

Discussion on: The Shocking Immaturity of JavaScript

Collapse
peppesilletti_4 profile image
Giuseppe Silletti

Hi Jared, after reading your article it's still not clear to me what you don't like about Javascript. I personally run multiple projects with JS (on frontend and backend) in the last five years and it's been a great experience.

It would be great if you could be a bit more specific about the problems with JS. Maybe you're doing something wrong?

Collapse
rickmills profile image
Rick Mills

Not the OP but my immediate thought would be, if you pick up your oldest couple of projects and try to update them, or to compile them using the latest tools out there, you can pretty much guarantee it will fail.

Thats the fragmentation, the instability, and the "hype-train" issue Javascript has. Theres just so many people wanting to re invent the wheel constantly that the whole ecosystem surrounding Javascript is just woefully poor when compared to other languages.

I'm totally bias here as a PHP dev who's watched PHP go through the same issues. Back in the v4 days, we had crummy sites offering up poorly written code snippets, and then there were a few that tried to make their sites seem like the go-to place for the best code (they weren't). Everyone just constantly reinvented the wheel every time they built something.

Finally we got stability with Composer and Packagist and a sensible set of people sat down and built the PSR standards, which were adopted by all the major widely used frameworks, down to the smallest of packages. And now because Composer actually requires packages to meet these standards (or at least a basic set of them) it means compatibility between codebases and versions is insanely good.

If a PHP package doesn't have a feature these days, you built it and contribute it back into that package, instead of the Javascript community which seems to think its a fantastic idea to just build a totally new thing every time.

This is what Javascript is missing - stability and leadership. As long as theres this constant screwing around with "Ooo a new shiny package, I must use that" or "I don't like how they did this thing so I'm going to write a better one" then JS will continue to be a second rate language with an extremely unstable ecosystem.

It's not really even a debate a this point - Javascript, without a doubt has the worst developer experience of any modern web programming language - by far! People who don't see this often just haven't had the experience using something better, so have no idea its even an issue.

Collapse
leob profile image
leob

Spot on, I said more or less exactly the same thing in one of my comments on this post ... it's the "not invented here" syndrome, and the constant reinventing of the wheel, which are doing a lot of harm IMO.

Collapse
ohryan profile image
Ryan

I love that the top answer to a post about the extreme poor DX of JS ecosystem... a post which specifically mentions "...rude, curt dismissals of genuine problems people are having in the real world. RTFM is never the correct response to DX issues."

...I love that this comment ends with "Maybe you're doing something wrong?" AKA "RTFM."

Case in point. Brilliant!

Collapse
peppesilletti_4 profile image
Giuseppe Silletti

That's your interpretation. Mine was a genuine question to see if I could help in any way, not being rude or anything.

As I said, I've used JS successfully for years and I didn't feel the pain. And great devs like Eric Elliott or Matteo Collina are doing the same.

So again, maybe you people are doing something wrong?

Thread Thread
leob profile image
leob • Edited

I don't think it's a matter of people doing it wrong ... as many commenters have argued, the JS ecosystem tends to be confusing and fragmented, and therefore doesn't make it any easier for a newbie to become a "pro". Other languages/ecosystems just seem to provide a little bit more guidance for a beginner. If you happened to experience smooth sailing and little problems, great, but I think that's not the point of the post.

Thread Thread
peppesilletti_4 profile image
Giuseppe Silletti • Edited

I agree with you, but the OP didn't write anything useful to understand his context and experience with JS. So the article it's making statements without any proof that what he's saying is right

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.

Collapse
jaredcwhite profile image
Jared White Author

"Maybe you're doing something wrong?"

OK, I'll go ask all the people who contact me on a regular basis to complain about how messed up their build is what they're doing wrong. 😆 Also all the people on epic GitHub threads having the same problems I am. Also team members already looking to rewrite half the application stack. Also…

Collapse
peppesilletti_4 profile image
Giuseppe Silletti

Cool, let us know!

Collapse
melissamcewen profile image
Melissa McEwen

Have you worked with other languages? For me that was the breaking point. I already was frustrated with things like build tools that take ages to compile. And the thousands of libraries to sort through and dependency hell. And issues with Js vs. Node.js (have you tried to deal with CJS/MJS yet?). When I started learning Swift I was like... wait this has all the stuff I want, why do I torture myself with a build configuration when I can write in a language that already has all these features. I stopped trying to learn Typescript and now I'm gonna focus on WASM because if I'm gonna have to have a heavy build pipeline, might as well write in another language.

Collapse
peppesilletti_4 profile image
Giuseppe Silletti

I don't do Typescript, pure JS is generally enough 😇

Forem Open with the Forem app