DEV Community

loading...
Cover image for The Shocking Immaturity of JavaScript

The Shocking Immaturity of JavaScript

Jared White on March 16, 2021

This is going to come across as a rant, so I'll do my best to refrain from blaming any one project or source and just make a generalized statement....
Collapse
faraazahmad profile image
Syed Faraaz Ahmad

This. Every word of it is what I've been saying and wanting to say about the whole Node/JS ecosystem for a while now. I was lucky enough to have stumbled upon and learned Ruby (and RoR) right out of high school and ever since I've hated the DX around everything Javascript.

I remember trying out tutorials for the MERN stack (even official ones from Microsoft) and was shocked by how much I needed to understand and install just to get started. It was so much easier in the Rails world to just do rails new project_name. There are some recent changes Rails has made that I'm a little iffy on, like requiring Yarn instead of just using NPM and using Webpack (which is great but I keep running into compatibility issues) which kills the DX for me a little bit.

Right now I'm a happy user of Elixir and the Phoenix framework.

Collapse
zaydek profile image
Zaydek MG

I think Node / JS became popular out of necessity. JavaScript kind of cornered the market by making it the only viable target for deploying to the web and Node bootstrapped V8 to make that happen on the backend. But JavaScript kind of has this legacy, with JavaScript being originally implemented in something like two weeks and not being able to revise itself due to backwards compatibility concerns. So it makes sense -- in hindsight -- why Node / JS can be so out of whack, but only if you understand the context in which JS was created and then ported to the backend.

I will say that NPM / Node / JS is fairly accessible today but that’s only if you are down with learning a bunch of tooling that may or may not fall out of fashion in the near future. Frontend is a tumultuous world.

All that being said, this is certainly not the best we can do. I really like that some frontend devs like yourself have branched out and are leveraging backend technologies, because the added experience can help re-contextualize frontend tooling for the rest of us.

I’ve never tried Ruby but I hear generally good things, depending on who you ask. 😀

Collapse
leob profile image
leob • Edited

I think JS might (gradually) be getting there in terms of DX - e.g. if both browser engines and node.js implement most of ES6/ES7/ESWhatever natively (so that we don't need Babel and so on), that will make a big difference.

It's not the whole story, but just the tooling is so much simpler for the other stacks (Ruby, PHP and so on).

Hopefully we'll gradually get less fragmentation and more 'standards' in the JS world.

Thread Thread
zaydek profile image
Zaydek MG

JavaScript is definitely more ‘aligned‘ then it’s ever been before. Though there is quite a bit of fragmentation now coming from tooling like TypeScript, for better or for worse. I use TypeScript but I feel like my TypeScript is not going to be constructed the same as everyone else’s because there’s a thousand decisions every TS developer needs to make or will be made for them and that causes me some concern.

I’m also all for not betting on Babel going forwards. I get that it was necessary at one point to really be productive, but it strikes me as a burden now to have fragmentation, like you said, in the core language itself, let alone TypeScript and type-oriented extensions. It surprises me that I haven’t heard more complaints about Babel?

It’s not that I dislike Babel, I just think it doesn’t make sense to force projects into using Babel because of legacy codebase decisions.

Thread Thread
leob profile image
leob • Edited

Spot on ... Babel is of course a technical marvel, but I never liked the fact that I'm not programming in the "real" language, but in a pimped version of it, which then needs to be cross-compiled to "the real thing" - in a separate build step (so, as a code generator, in fact).

It also makes debugging that much more of a hassle, always the struggle with source maps etc.

Obviously I respect the people who developed Babel, but I say good riddance when we don't need it anymore, once browsers and node.js support newer JS versions natively.

Ah yeah but then there is TS :-)

What I'd really like is if these "cross compilers" or "pre compilers" were just integrated into the JS engine, so that it would be something like a seamless "just in time" on demand compilation step, rather than requiring a clunky external build step ... JS is the only mainstream language which has all of this baggage.

Thread Thread
zaydek profile image
Zaydek MG

You may want to check out esbuild if you haven’t already. ;)

Thread Thread
leob profile image
leob

100 times faster than Webpack or Parcel ... how the heck is that possible?

Thread Thread
zaydek profile image
Zaydek MG

Webpack / Parcel are implemented in JS which ultimately is going to be as fast / slow as V8. esbuild is implemented in Go (closer to the metal) and uses a lot of concurrent algorithms as an optimization. In 1-2 years I think esbuild will emerge as the dominant tooling provider.

Thread Thread
leob profile image
leob

Right ... but why does that have to take 1-2 years? If it's that much better then I'd use it right away and dump the rest!

Thread Thread
zaydek profile image
Zaydek MG

It’s pre 1.0 and missing a few core features. It’s not far off but it’s also not 100% adoptable yet.

Thread Thread
leob profile image
leob

Ah okay :-)

Collapse
rxza profile image
youngdagobert

Ruby coder and can confirm its SO much easier than doing stuff in JS. Community is really helpful too :)

Thread Thread
thebarefootdev profile image
thebarefootdev

Subjective ease of use doesn’t always indicate quality, there are many reasons why some find things easier and harder. Usually that a lack more complete understanding of a language is why another is considered easy.

Simply because a language is syntactically clearer to an individual does not eschew any functional comparison, it’s more about the underlying language engineering and whether it’s a good approach for the domain solution and not entirely clarity for the developer

Thread Thread
jaredcwhite profile image
Jared White Author

It's a mistake to optimize for computers at the expense of humans.

Thread Thread
zaydek profile image
Zaydek MG

Comment of the year. 👍

Collapse
thebarefootdev profile image
thebarefootdev

This is a rather odd article. It’s not clear that you have a full understanding of the node and JavaScript ecosystem at all. You appear to lump it all in under one monolithic thing and then compare it to largely unrelated approaches.

Node is not a product directly as a platform for all JavaScript developers. It’s true it’s hard to do much these days in JavaScript without it but node itself is the V8 engine , and libuv written in C and as a tool is very powerful. Sure it’s powering JavaScript abstractions but if it’s dismissed as just part of a npm / JavaScript collective then it’s not a fair assessment.

Regarless, your article is absent of any real critical analysis on your dislike of JavaScript , you compare it to Ruby on Rails and elixir and Phoenix yet these are complimentary language / frameworks not constructs in competition with node and JavaScript. By all means a comparison between React or Angular and Rails for example would be more appropriate but denigrating JavaScript without examples is a rather naïve approach.

JavaScript has its problems that is true like most languages, but to know them is to understand JavaScript and to know it and to know Node.

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

Collapse
pllffrd profile image
pllffrd

Interesting topic, thanks. The most convincing bit of this article are all the JS Devs with Stockholm syndrome in the comments:
“There’s nothing wrong with my tooling... Examples or it didn’t happen...Everything is fine.”

Collapse
leob profile image
leob

Haha this made my day, Stockholm syndrome ...

But, TBH the point about JS is that in the frontend you don't really have much of a choice - frontend means JS, practically speaking ... right?

(there's WebAssembly but I don't know how practical that is, at this moment)

This puts JS in a "special" position, fundamentally different from Ruby, PHP, Python and so on - in many cases you don't really have a choice but using JS.

Collapse
dbshanks profile image
Derek Shanks

Web Assembly is both awesome and scary at the same time. I write C# in Unity and was impressed with how fast I could get up and running with Blazor & Web Assembly.

I would detest using something like Rust for web applications. Haha!

The projects that really excite me are Laravel’s Livewire and Elixirs Phoenix LiveView. Server side components natively written in either PHP or Elixir. Ruby on Rails has something similar although I am drawing a blank on the name. It’ll be interesting to see if Express or NestJS adopt something similar. This eliminating the constant pull for React, Vue or Angular.

Thread Thread
leob profile image
leob

Livewire, yes - tallstack.dev/

Another one I came across is Unpoly (unpoly.com) - sort of Turbolinks on steroids?

Rust is interesting though ... why the dislike?

Thread Thread
dbshanks profile image
Derek Shanks

No dislike on Rust. It’s amazing. It’s just not what I would want to write web apps with. I am looking into it’s capabilities for writing games. Currently C# is my game code experience via Unity. I worked with Lua or Haxe for awhile, Rust seems like a really good platform to write an entire game on.

I will admit C# and Unity are very hard to walk away from in terms of dev experience.

Thread Thread
leob profile image
leob

Well yeah, Rust is powerful and has a steep learning curve - maybe just overkill for 90% of web dev projects ...

Collapse
ninofiliu profile image
Nino Filiu

Thanks for the hi-quality rant!

But tbh most of this JS fatigue can be avoided by simply ignoring what's not relevant.

You wanna build your first website? Sure, just use FTP+Vanilla. That's all you really need.

Then (and only then) should a developer care about going further. Your website is getting complex? Sure, just learn Vue. You want faster load times? Sure, just give a try to the jamstack. But we must stress how completely optional these improvements are.

So yeah, I totally agree, fuck these "10 new features in ShinyNewFramework that were released yesterday that you absolutely need to know else you suck" titles are not the good way to go.

But I think that the amazing rate of innovation in web development today is worth the discipline one has to acquire to filter this noise of clickbait articles and stupid hot takes!

Collapse
jaredcwhite profile image
Jared White Author

"simply ignoring what's not relevant"

Well that's cool for me, and for you. But that's not where any of the jobs are and that's not where any of the code schools are. The industry pushes people into adopting certain tools for specific purposes. I'm here to question if those tools are good enough. (Narrator: they are not.)

So my point is, instead of just ignoring the problem, call it out! For the sake of the children… 😂

Collapse
svemaraju profile image
Srikanth

what is FTP? I'm a JS noob.

Collapse
jaredcwhite profile image
Jared White Author

File Transfer Protocol:

The old-school way we'd transfer files from a computer to a server or back again, before the days of SSH and Git. 😃

Thread Thread
svemaraju profile image
Srikanth • Edited

You wanna build your first website? Sure, just use FTP+Vanilla. That's all you really need.

Haha, I thought it was something else because of the context of the above comment.

Collapse
stojakovic99 profile image
Nikola Stojaković • Edited

He's telling the truth. Anyone who worked at least a year (or even less) in the JS ecosystem will understand this.

Collapse
zaydek profile image
Zaydek MG

I really appreciate you writing this article, and yes I can understand your hesitation to write it in the first place.

What I will say is that I’ve becoming increasingly enthusiastic about esbuild (esbuild.github.io) because it seems to be a real way out of the chaos while providing backwards compatibility. I was somewhat optimistic about Deno, but at the same time Deno is a breaking change oriented kind of technology, and I’m not 100% on board with that.

Anyway, yes. Frontend I think is plagued with too much hype, but I think that is also one of its best qualities. A lot of developers get their first footing into the world of programming because of how accessible JS is, but that also makes JavaScript, for better or for worse, more susceptible to lower-quality code / maintenance. Like you, I’m not pointing anyone or any project out, but I think it’s a symptom of the bigger picture that a lot of devs get into programming because of frontend. Me included.

I wish I had more to contribute other than simply writing a reply. But I am grateful you’re acknowledging one of the dirty truths about frontend-land.

Collapse
jaredcwhite profile image
Jared White Author

To be fair, I'm not letting JS backend off the hook either 😬 …but at least with backend tech there are numerous ecosystems to choose from. On the frontend, JS is basically it. Anyway, thanks for the reply, and I agree there are lots of interesting projects springing up utilizing esbuild that seem to promote speed and simplicity as core tenants. Encouraging stuff.

Collapse
zaydek profile image
Zaydek MG

I can’t handle JS backend. I mean, for small things, yeah -- why not. But for large things, why punish yourself? To each their own but JS backend is definitely not for me. I’m barely happy enough to stick with JS frontend, and that’s only thanks to the ecosystems that have been propped up to make it manageable.

I think frontend has suffered from a lack of technical competition. Framework competition isn’t meaningful in the same way language competition is. And unfortunately I don’t see WASM changing the game (because of DOM overhead). I would love to be wrong here, but I think frameworks will still be the way forward for a bit.

Dart / Flutter seemed to offer a way out -- by thinking about more reconcilers than just the DOM -- i.e. canvas, but for the time being appears to be underpowered and not ready for primetime.

Thread Thread
jaredcwhite profile image
Jared White Author • Edited

What makes me feel all warm and fuzzy is just how good browsers are getting at the core level, so our frontend code can become simpler and sit closer to the "metal" — esbuild being a showcase for that trend. After all the crazy framework wars of the 2010s, it feels like for many kinds of sites you can pull in a few simple libraries, write some web components, use a great backend with reactive HTML-over-the-wire techniques, and get a fantastic UX out of it all. That's my personal "escape hatch" anyway…I expect it'll take a while for the industry as a whole to embrace some of these trends.

Thread Thread
zaydek profile image
Zaydek MG

I’m somewhat open-minded to the whole server components approach but I also don’t like the idea that we suddenly need to be implementing and deploying servers rather than stateless assets to the web (assuming I understood this right). And I think web components had a chance to help resolve a lot of these woes but ultimately the SEO concerns I think outweighed whatever ergonomic benefits web components offer.

I really like how Svelte can be used as a compiler to generate web components and I think that was an incredibly smart idea for how to macro fix a lot of these systemic problems.

I really think that static site generators that are not JS-heavy is really the right approach for most sites. But once you want to develop and interactive frontend app, the water gets murky quickly because of just how much more tooling / overhead is needed. I will say that writing React in 2020+ is much more accessible than it felt to me before 16.8 (hooks) but I still think the experience overall could be improved.

Thread Thread
faraazahmad profile image
Syed Faraaz Ahmad • Edited

I really hope WebAssembly enables competition in the frontend for JS to get its stuff together, and ultimately gives everyone better tools across the board. I feel like something like Svelte and using your own preferred language in it that compiles down to webassembly could really improve the frontend DX

Collapse
hemiltherebel profile image
Hemil Ruparel

Exactly! Throw in a bunch of noobs and be ready to pay hefty prices to senior engineer/consultants to fix the mess they created (assuming you last that long of course :P)

jaredcwhite profile image
Jared White Author

"rockstar tech writer"

Wow, thanks! I spent 20 years toiling away in obscurity, working on numerous web projects without ever blogging about the strengths or weaknesses of anything I did or used. I only started blogging about dev tech in earnest a year ago. Now I'm a suddenly a rockstar?! What a ride! 😅

Collapse
jmitchell38488 profile image
Justin Mitchell

No point slinging mud at the language. Code is only as good as the person authoring it. JavaScript, compared to Python and Ruby is quite immature, and there are real and measurable reasons for such. The incompatibility and lack of standards compliance until the last 5 years was a major contributing factor. NodeJS didn't reach maturity until a few years back. Python and Ruby have been around for a very long time.

Lodash wouldn't have existed if MS didn't force users onto their own POS JScript engine and VB runtime crapola. JS would no doubt have reached maturity a decade ago if all the major IT institutions came together and standardised the browsers.

Also, shitting on a language because it was "created in 2 weeks" is really reaching for that tiny violin. PHP was created by a software engineer to help render HTML, and within a decade usurped .net, Java and Perl as the choice technology to build backend web applications. Ruby had 4 releases in 3 days when it was first created; pick your battles carefully.

Unless you're improving tools that developers use, it's just another frustrated developer complaining about the sky being blue or the earth being spherical.

Don't mistake ubiquity with immaturity.

Collapse
freakynit profile image
Nitin Bansal

I lost it when I started to see blog posts telling me to devote 5+ hours setting up my editor, theme, font, this-rc file, that-rc file, this-config, that-config, and 10's of other files and configs just so that I can build one fuck*** single page react app. And this shit is only getting worse. Just look at those repos on github. All they do is add 2 numbers and need 100 files to build. F*** this bloated ecosystem.

Oh, the main point, yes, the ecosystem is filled with broken, incomplete packages. I once tried building a video streaming app in react-native. Took me over 100 chrome tabs of tech browsing, and numerous failed, frustrating attempts, just to get one simple video get played correctly. Tried over 5 different libraries. Followed their tutorials down to the last words. That shit just don't work correctly. Then switched to native on Android using java. Worked in less than 20 min. fml! Not to mention, javascript's performance sucks, and also, it's single threaded.

stojakovic99 profile image
Nikola Stojaković

Understand the fact that JS ecosystem is not stable enough. There is no need for specifying things because if you worked long enough in it you would have come across chaos for sure. First things first, there are too many frameworks which are just reinventing the wheel.

Also, he did mention an example.

(Heck, demand standards at all! The ecosystem churn around ES modules right now is driving even the top authors of frontend bundlers absolutely nuts!)

This is just one thing. Others are quirks like the one you pointed out, small number of well written, well tested libraries (let's be honest, npm is full of trash libraries) and so on.

Just because you don't like something don't assume that someone is automatically wrong.

Collapse
nickmaris profile image
nickmaris

The article is about Developer Experience so it is normal if some comments are not constructive. Ruby is an example, it is not better and it is not the goal.

I wouldn't focus on the language or on a single library/tool but on the lack of quality standards on the day to day development:

"Demand higher standards. (Heck, demand standards at all! "

All I can say is that I don't know JS and I don't want to know.

However, a series of articles with examples of code and the mess that they keep creating would help more, so that could be a next step maybe without mentioning the library/tool cause that's not the point.

Collapse
guledali profile image
guledali • Edited

I agree with everything said in this blog post, probably the best thing I have read so far this year.

I have been reflecting lately on Ruby on Rails, how it brought two developers to the same page.

For example let say your manager comes to you one day and says,

"Hey you see this username field in creating a new user, I like it to be required to fill in when creating a new user"

You thinking to yourself yeah that make sense.

If you ask three rails developers from different part of the world, one junior, mid-level and senior. They all going to present the same answer

class User < ApplicationRecord
  validates :username, presence: true
end
Enter fullscreen mode Exit fullscreen mode

The difference might be that the mid-level and senior are going to make constrains in the database level. Probably having model-test, controller-test and system test as well and maybe some better validation-rules some nice validation message along side but the bottom-line is.

At the core they all have the same answer and they know where to fix it and what or which methods to use.

Now ask three javascript developer and you will get 3 different answers and none of those answers look a like. Not only that, but should it be handled in the backend or the frontend? What npm-package should we use?

There is this famous quote of javascript

"Any application that can be written in JavaScript, will eventually be written in JavaScript"

We are living in that reality right now and honestly I don't think it's good one to live in and we have seen that play out for the past 10 years the Everything.JS movement

I also believe frontend frameworks themselves are bringing some issues with them. For example rails provides awesome form builders that are nicely integrated with rest of the framework(rails routes, controllers and so forth).

Why would you wanna replace that and rest of ActionView library with react.js or any other javascript framework?

The sad part most people are doing that for no reason spinning up rails api instead using the framework as MVC and spending days building a CRUD app that would have take you 1-minute to implement in vanilla rails app that's well tested.

Collapse
mangor1no profile image
Mangor1no

Bruh. w3schools.com/tags/att_input_requi....
You don't need a package to make a field to be required when submit. It's just there are many different ways to do it. There are simple ways and advance ways. Just the personal decision to finish the task tho. IMO I follow KISS principle and try to reduce libraries/packages in my project as much as possible.

Collapse
guledali profile image
guledali • Edited

Make a field "required" and adding a validation to a field, are two different things number one. Let's get that straight. Btw you can easily go around this by inspecting and remove the flag required but to the point and you said it yourself,

" It's just there are many different ways to do it "

Which is the main problem with JS development that we see today so many ways of doing this and bike-shedding and no-one agrees on anything even if they are using same tools, libraries & framework. It's still different enough somehow.

One thing that all JavaScript frameworks and projects have in common,

"Is that they can easily get of the rails, whereas ruby on rails stay on the rails"

Thread Thread
mzzfederico profile image
Federico Muzzo

If your backend isn't doing validation there's no amount of JavaScript that can fix it.

Collapse
ivanjeremic profile image
Ivan Jeremic • Edited

I hope Node JS, JavaScript, TypeScript,WASM, Deno, Webpack, Babel, Snowpack will be one day put in a mixer and out comes a standardized new rebranded JS with an offial compiler who can compile code for legacy JS and also compile directly to web assembly this is the only future for JS that would make everyone happy! Imagine this one language with no third party tools for building around it just one official compiler that does everything.

Collapse
leob profile image
leob

YES that's it ... we share the same dream :-)

Collapse
asyraf profile image
Amirul Asyraf

" MINASWAN, which stands for Matz-is-nice-and-so-we-are-nice."

So true 😂

We need people who have a mindset like DHH or Matz in Js community ;p

Collapse
thegoldyman profile image
talamaska

I was wondering how to comment this and search the least offensive word here.
I see here a bunch of whiners came toguether here to whine. Been developer since php 3. A Front-end from 10 years. Livewire? Are you kidding? This is a step towards old asp.net apps which I hated so much. People here hate babel, comparing it with code generation that it was cheating, yes it's cheating blame MS and Safari for that. Hating TS of it's magic decorators or w/e than what's this - @livewire('search-users'). How do you expect to run the same code with upgraded tools. Can you compile .net core 1 with .net core 3 tools? I doubt it, in fact everything breaks just from VS 2015 to VS 2018. Yes the web is in fluctuation and fragmentation. So what? If it wasn't we would still be writing prototypes and monkeypatches. We would still be paying for backend work to render content in the cloud, instead of cdn-ing the front-end and pay less. And yes the fragmentation is caused by the enormous number of browsers doing its own thing, IE, Safari, Firefox, Chrome. And yes not everybody can update its browser. You can't compare backend env with front-end env. Tooling - what about it. gulp, grunt, webpack, npm scripts. not so complicated to learn. Composer came after npm and it learned from the lessons and that's why it's better. And before that we had Zend 1,2, yii, and not package manager except pear. There were others it was not only Laravel. It was not there, but you whine about how many frameworks we have in JS, that's ridiculous. I take the big number of choices over any walled garden and single way to do it dogma. For a large part of it's life, Js was not changing. People were whining about that. Then it start's changing - evolving, people again whine. Like really????

Collapse
jaredcwhite profile image
Jared White Author

I see here a bunch of whiners came toguether here to whine

This is exactly the mindset I keep coming up against. Elitist "software engineers" who consider the complexity they wield and try to keep up with on a daily basis with as a badge of pride. I simply want nothing to do with it.

Collapse
thegoldyman profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
talamaska • Edited

No pain, no gain...whining will not change anything either learn it or change it. Did you read the rest of the comment or you are just of those cancel culture individual? Obviously reporting this comment only support my impression of the people here - cancel culture at it best. Leveragin COC to block people wth different opinion. By doing that you actually acknowledge that you haven't worked hard enough to learn JS. The truth hurts.

Collapse
blnkspace profile image
Aviral Kulshreshtha

I'm not the biggest fan of JS if I compare it to Haskell, Rust or even TS. But unfortunately this article failed to give me any real information about what's wrong with the ecosystem around JS than one person's struggle to make sense of things. And I come from a background of creating apps with a scale of 100s of thousands of users and like 10k concurrent users.
I started reading this article with a predisposition of actually understanding issues.
I'm not sure if you should use the language as a sum total of the tools you know of or available to you. If you do need to focus on said tools; try purchasing some tutorials. That's how I get up to speed to any new thing, be it GraphQL or whatever. There's crazy good resources around.
Also, no offense, but with the current functional capabilities of JavaScript, if I see an actual for loops instead of functional maps; I'm gonna call out that stale style of coding for what it is.

Collapse
jaredcwhite profile image
Jared White Author

You're literally doing what I said not to do in my article: "RTFM is never the correct response to DX issues."

😅

Collapse
blnkspace profile image
Aviral Kulshreshtha

That still doesn't form any coherent argument. Assertions without reasoning hold no value. I'm all ears to actual issues. It seems you're just pissed there isn't easy to follow docs around specific tools?

Thread Thread
jaredcwhite profile image
Jared White Author

That's not what my article said at all, but I have no wish to banter further. Cheers! ✌️

Collapse
guitarino profile image
Kirill Shestakov

You don't seem to be grateful for the tools you are given, for free, developed by community in an open-source way. Now, nothing prevents you from building your software completely from scratch, without any dependencies. Otherwise, yes, some set up, some building steps, some bundling and transpilation is needed, but it ultimately saves thousands of hours. If you do things in a standard way (yes, there are standards like NPM, using common js / es modules, plus some babel and webpack), then you're probably not going to have any issues, and you will even have a variety of tools that you can choose. All you need is some patience.

I think you're misidentifying the problem. The problem is that javascript is easily accessible for the beginners, and, hence, is prone to be built in an unstable / unmaintainable way. Ideally you'd want an experienced person to set up infrastructure in a way to ensure maintainability and ease of development. And since you somewhat impatient and expect everything to be given to you on a silver platter, then of course you will be disappointed. It doesn't mean the community needs to change to fit your needs, it means that you should start learning again and potentially even start contributing to the solutions, which you can do due to the web's open nature.

Collapse
spronkey profile image
Keith Humm

What exactly are these “standards” and how does one expect a developer to learn them? You can’t find them with a a search, for example, and the language itself has no opinion about anything.

There’s nothing even close to JSR, or PSR or any of the other single source of truth attempts you see in other ecosystems, and it doesn’t seem like there is any real attempt to move to that way.

There’s zero good reason why code written 2, 3, 5, 20 years ago shouldn’t be almost immediately useable with quick tweaks. We haven’t really changed anything fundamental here for more than a decade, and yet even a seasoned engineer would struggle massively to grok the current JS ecosystem without a helping hand from some people who are up with the play of the various sub-communities.

Collapse
jaredcwhite profile image
Jared White Author

Good job proving exactly my point in the article about the gatekeepers and the gaslighters. 🤦🏻‍♂️

Collapse
guitarino profile image
Kirill Shestakov

Do you mind expanding on what you mean?

Collapse
blindfish3 profile image
Ben Calder

TBH from the title I didn't expect anything less than a rant; but I hoped for a bit more substance. It's not that I disagree with all that you're saying - far from it - but you basically seem to be complaining that there are too many tools to choose from; not enough quality control; and some people are either over-enthusiastic, or just downright dishonest, in their marketing of what those tools can deliver. Big deal: welcome to the real world...

In any profession the most important things to learn are the fundamental skills; and how to select the right tool for the job. Anyone who buys into the "tool X will deliver all your possible needs" is naive and will learn the hard way that it is not so.

To focus on a particular language and then provide no evidence to justify your click-bait title other than vague generalisations, because you want to "refrain from blaming any one project or source", is a cop-out and not especially constructive. If the JS eco-system has a problem it's that it's too open and moving too fast; though some might argue that's a positive :D

As a senior dev it's your responsibility to choose tools that are appropriate for your project. You make those choices based on your experience and with an awareness of any limitations they may have. When you select a library or framework you don't waste your time on marketing hype; but instead look at the source; look at documentation; check issue trackers to see the types of bugs being reported and how well these are handled. Then you weigh up the pros and cons and make a choice; and live with the consequences :)

When you see people ranting about the latest new-and-shiny that can't possibly deliver on the promises it makes you can just sit back, wait for the dust to settle, and be satisfied that you didn't fall into the trap. Ideally you can also voice your reservations in a constructive manner; providing appropriate evidence and offering reliable alternatives.

Collapse
nickfazzpdx profile image
Nicholas Fazzolari

Great post. You summarized and supported your arguments in a way that I'm sure many of us front-end developers can relate to. The part about ES modules hit home. It would be so nice to see a stabilization of the JS front-end, and even back-end ecosystem.

However, I think another step in the process of getting there is pointing out that programming languages and their tools are TOOLS. They're not things to favor because of marketing campaigns, or popular opinion. Cutting through that mentality is hard. Because aspiring developers want to build software while being gainfully employed. If the marketing and community communication strategy is largely based on promoting the 'hip' regardless of context, need or demand we will continue to see this trend.

Really great post.

andrewmcodes profile image
Andrew Mason

Why are you gate keeping who can complain about JavaScript? It’s really not that serious.

Collapse
peppesilletti_4 profile image
Giuseppe Silletti

The JS ecosystem is fragmented, there's not a single way to do something and newbies get feel overwhelmed by that. I totally agree with it.

But is it really a con?

I would argue that it provides flexibility and constant innovation. It provides you the freedom to choose the right tool for you starting from a really minimalist setup. I personally prefer the small and friendly web frameworks like express or fastify over a magical framework like Laravel (or many others). I really didn't enjoy working with the latter, I felt constrained and way less productive.

Working with JS requires devs to think even more about the impact of their decisions. Experienced JS devs know what are the best libraries out there. Oh, a new one is out? If it's REALLY something valuable, why not trying it out? I love this flexibility.

Newbies may feel overwhelmed maybe because they haven't developed a good engineering mindset yet, and that's normal. I wouldn't say the JS ecosystem is bad because of this though, it just requires a different approach.

If you prefer the tools to think for you, go for a framework. Nothing wrong with that, I won't rant over it :)

Collapse
spronkey profile image
Keith Humm

I think the main problem is that it has resulted in an “everything is always in some state of broken” problem. You can’t really depend on the tools you have to work for longer than a very short span of time, and unless you have a really large amount of time to dedicate to maintenance of the churn, it can really kill your efforts.

Try maintaining projects in JS that aren’t high priority, for example. Almost every single time you need to make changes, there is an inevitable massive and very difficult to estimate period of dependency and toolchain hell to get through.

You also can’t really avoid it, because vanilla JS really doesn’t have much in the way of a standard library.

I think its overall a good thing when people can agree on at least a few central aspects that will be common to many projects, even if there are a couple of variants of them.

Collapse
mraszplewicz profile image
Maciej Raszplewicz

Thanks for this article!

My main problem (not the only one though) with JavaScript tooling is that my code doesn't compile after some time.

A recent example: I had to change something on our website which is built using Gatsby, I did it and was surprised that I can't deploy it anymore. It was about half a year since the last change and yes we have package-lock.json committed to the repository. This is not an exception - I had a lot of similar issues in the past mainly with Angular projects, this is just the most recent example.

Soon we will have a big issue in the java world too - JCenter is going to be shut down, but at least I know it in advance and can prepare for that!

I hope that non-javascript frontend frameworks like Blazor will become popular and we will have other options than JavaScript tooling.

Collapse
jaymeedwards profile image
Jayme Edwards 🍃💻

Love your post. Personally I believe this is true of more technologies than JavaScript. That’s not to disagree what you said - all your observations are valid.

There are a variety of challenges our industry is experiencing that I personally believe stem from the desire to be popular with other developers, the misnomer that the best code comes from younger people, and a desire for developers to insert their personal preference into existing problems that have already been solved.

Of course that’s just my opinion, and I’ve been one of these people so I attribute this phenomenon to the growing popularity of our profession compounding these issues - not a specific generation of developers.

I’m thankful you’re raising awareness of this issue! We need more voices. I echoed a similar sentiment in an episode on my channel “Why are you you making programming harder?”

youtu.be/s87Y-6EgwFI

Collapse
jaredcwhite profile image
Jared White Author

That video was awesome! thanks for sharing, it really resonated with me. 👍👍

Collapse
jaymeedwards profile image
Jayme Edwards 🍃💻

I had a feeling it would - your article definitely resonated with me too 😊.

Collapse
raspberrytyler profile image
Tyler Smith

I had a similar experience with JavaScript and have moved my projects towards Laravel/Django/Rails with fancy front-ends only when necessary. It took me a year of wrestling with Node to realize it was more trouble than it was worth.

I do love TypeScript though. That's the one thing I feel like I miss out on with these backend frameworks.

Collapse
ingosteinke profile image
Ingo Steinke

I see the quickly changing trends as a main reason for instability. For example, learning React in 2021 using hooks, CSS-in-JS, and server side rendering is quite different from what had been recommended best practice only three years ago. But maybe you should rather switch to Vue or Svelte or another promising hype that we will read about soon. What we will also read about: "21 JavaScript tools every web developer MUST learn in 2021", and "Why I am not using XYZ anymore, and neither should you".
A possible solution? Use less JavaScript and rely less on JS frameworks!

Modern CSS features allow us to build fast and accessible websites without overusing JavaScript! And if you want server side rendering, why would you use ReactJS when there are so many back-end languages to choose?

There have been many new JavaScript features that became widely accepted like arrow functions, async etc, so hopefully the attempts for stability like data types and interfaces, probably even best practices for unit testing, will become part of core "vanilla" JavaScript one day, so we might look back on 2021's frameworks with the same feeling of nostalgia and obsoletion that many developers feel about jQuery today.

Collapse
zerobias profile image
Dmitry

I think you shouldn't hide the names of projects from which you was taken these quotes. The first quote is from gatsby.js, second one is from next.js and the third is from typeorm. All these projects are overwhelmed with bugs and flooded the ecosystem with their irrepressible marketing.

I think we should tell this clear and loud: don't believe them, and lean yourself to detect marketing buzz

Collapse
dodiameer profile image
Mohammed Ali Agha

Couldn't agree more! I started web-dev a year ago (had been coding before that for fun in Python) and wrapping my head around the ecosystem was a headache, especially when all I heard was "frontend is easy to get into!!!".

It's got manageable for me, but I say that not having worked on a large project.

It's also funny the amount of people that say "Ruby / Python doesn't scale well", while companies like Shopify are doing just fine lol

I've heard good things about Elixir, Golang and Ruby, and I remember Python also being nice to work with in terms of tooling, Javascript really needs to follow the lead of some popular tools in those languages to really establish itself

Collapse
7tonshark profile image
Elliot Nelson

Although I'm 100% with you on your call to action, and I'm a huge Ruby fan, I'm not convinced the differences are as stark as you describe. Today I'm writing almost 100% nodejs, but in my years of writing Ruby & Ruby-on-Rails websites, I spent just as much time monkey-patching weird broken globals in Rails, fixing breaking changes in code resulting from Ruby 2.x upgrades, helping people fix frustrating module auto-loader breakdowns, etc.

It's possible individual packages were more stable overall, but that was partially because there were so few of them, because it was so difficult to maintain them. The task of maintaining a popular Gem is infinitely harder than maintaining a popular NPM package because of the stricter versioning requirements -- you either stay daily- or weekly- up-to-date with latest and greatest from all your dependencies or you inflict Gemfile.lock nightmares on your users.

Making something easier to do inevitably results in more of it, which means the sheer number of packages in the middle-to-bottom of the quality bell curve is that much bigger.

Collapse
jaredcwhite profile image
Jared White Author

You're kind of making my point for me though…the Ruby ecosystem is 5-7 years ahead of the Node ecosystem in stability. Yeah going from Ruby 1.8 to Ruby 1.9 was painful. Bundler and Gemfiles could be pretty finicky. But now it's rock solid. The kind of JS problems my team and I deal with today feel like Rails 2 -> 3 era shenanigans.

Will the JS ecosystem finally catch up? Perhaps...but in that span of time other ecosystems may progress even further. Full-stack JS will continue to be the default choice, but it's doubtful it will ever be the best choice.

Collapse
7tonshark profile image
Elliot Nelson

OK... maybe I agree with more of your article than I thought :).

Something I really value about the nodejs ecosystem that doesn't come through in your OP is this rough and ready sense of community that I feel was largely the result of choices made by NPM (despite all of its mismanagement and flaws). Even though Ruby is more mature, and Python much more so, I never felt that sense of community in those languages that I feel in node/JS.

Maturity isn't everything, is I suppose what I'm getting at!

Thread Thread
jaredcwhite profile image
Jared White Author

Everybody's experience is unique, certainly. I've personally not gotten much of a sense of warm-and-fuzzy JS community, although there are some good podcasts and Slack channels I enjoy…particularly related to web components. I agree with you that community is important, and that's why I'm always cautious to recommend anyone leave behind the stack they're most familiar with and enjoy using.

Collapse
cswalker21 profile image
cswalker21

The thing that stood out the most to me in this thought-provoking manifesto was "Slow down your progress on shiny new features and fix the features you've already shipped." I feel this is sage advice that could be applied WAY beyond the JavaScript ecosystem.

Collapse
asyraf profile image
Amirul Asyraf

"Decision fatigue"

I want Javascript at least to have a basic Convention tho.

Right now, most of the JS conventions are decide by the JS's pro guy. A beginner needs to listen to them to look cool like them. Imagine if there have tons of JS pro, and there would be tons of different options. This makes beginners bewildered.

Collapse
theowlsden profile image
Shaquil Maria

I agree with this article. I still have to get my hands dirty with Ruby, but the DX in JavaScript might be most of the time a pain in the ***. And JS fanatics that want to create new features instead of solving old bugs make it impossible for the ecosystem to become the perfect ecosystem they proclaim it is.

The thing I hate the most is when you install a package and see that there are 5 or 6 or more deprecated packages inside of it. You are basically bloating your application with deprecated code and you cannot do much about it.

Collapse
valeriavg profile image
Valeria

NPM has lots of packages. They are posted by humans, with human limitations. Sometimes dumb humans, sometimes greedy humans, sometimes trolls. And hype attracts more of those. Now what does this say about JavaScript itself? That it's a popular language.

I have trust issues with frameworks and tools overall and so should you. Try it, test it and don't roll them into production unless you're sure. Is it any different from other languages?

Collapse
jaredcwhite profile image
Jared White Author

Yes, it is. 😄

Collapse
crimsonmed profile image
Médéric Burlet

Agreed the ecosystem does not define the language. Javascript is actually pretty old and goes through proper validation before having new versions out.

Ecosystem of libraries is like that on many many languages php with composer also have bad ecosystem, some people also publish on open source C libraries that are not useful.

You can't judge a language for the content people create with it on the side.

Collapse
artworksetc profile image
Michael Barnett

Thanks for this, crystal clear. In my case as an aspiring dev, figuring out what to learn is tricky when you don't have a well developed conceptual overview. I settled on Ruby, glad I did so far. Need to learn js of course but the framework dependency dance is scary, and I really don't want to install the tools- even Homebrew, which has no proper support system, worries me.

Collapse
janpauldahlke profile image
jan paul

Bro, JS is the attempt to unify different browser APIs. One should know the genesis of a language. It's not a drawing board language, since every brwoser in the good old days worked different. Nodejs can be considered consistent, but please stop the hate about something you dont fully learned yet, or understand. ty

Collapse
jaredcwhite profile image
Jared White Author

I'm not sure who or what you are addressing this to, but let's be clear: it is a demonstrable fact that "JavaScript ecosystem fatigue" is a real issue in our industry. My article is years late to the party—I'm not really stating anything that hasn't already been stated numerous times by many others. Even your assertion that "NodeJS can be considered consistent" is false, because the Node ecosystem is in a major upheaval right now as folks are attempting to switch from CommonJS to ESM—theoretically a good idea, but in practice a massive headache. Then there's the fact that the actual creator of Node, Ryan Dahl, has built an entirely new and minimally-compatible system, Deno. It's the Wild West here.

Collapse
janpauldahlke profile image
jan paul • Edited

but why not be edgy and just write UI in godot or similar and use webGL, like flutterplasma.dev/

Collapse
zieg profile image
Duncan Fruslov

I just cannot agree more. For almost 10 years of my career I try to avoid working with JS as much as I physically can. I even fully embraced F# and Fable as it allows you to not touch JS at all. And my own projects are desktop apps, for the same reasons. I really hope something will change in future, but at this moment - mainstream frontend is just a big dumpster fire.

Collapse
phantas0s profile image
Matthieu Cneude

I coded with PHP for years. I didn't see its problems before trying another language... because I couldn't compare it.

PHP is not horrible and JS either. But I definitely believe that other languages are more... consistent, with less traps.

At the end of the day it depends how you use the language, in what context, and your mental model of it.

Collapse
kl13nt profile image
Nabil Tharwat

This is very much true, sadly. The ecosystem, despite being large and backed by a strong community, lacks support for newer developers. Maybe that's a side-effect of being so huge, but that's only my speculation. There are more beginners than there are experts and thus the majority of library users will not consist of highly experienced developers who can actually lead a library to become a better one. "It gets the job done" is what many say, a lot of it is just mislead, inexperienced preaching, unfortunately.

Collapse
khorne07 profile image
Khorne07

I have encountered feelings after reading this. I'm a frontend dev for 1+ year. I certainly have faced with many problems by installing this library to solve some problem, then I encounter my self trying to solve new problems created by that library, try to find another and ended up even more messed that with the first one. But that problems I have faced have been only with 3rd party packages, not with js itself. Still I'm too young in the frontend world to refute any of your reasons 🙂. By the way (and is completely offtopic) I have some interest in learning Ruby on Rails and after reading so many good opinions about it I certainly going to get into it soon 😁

Collapse
jaredcwhite profile image
Jared White Author • Edited

Yeah modern JavaScript itself (or TypeScript if that's your fancy) has gotten pretty good as a language, certainly far better than in the past. The challenge is there's not much of a "standard library" as compared to other languages, so you have to know what to pull in (lots of Node utilities and related packages on the backend, or various libraries/frameworks on the frontend), plus often various build tools you have to run to get from your source code to the destination runtime. All I can say is, I hope you find some solutions that make sense and work well for you and you stick with it! Also…yes, Ruby on Rails is still a great platform. Definitely worth a peek. 👍

Collapse
uzitech profile image
Tony Brix • Edited

I have a had almost the opposite experience between ruby and javascript ecosystem. My experience in ruby has been that there are very few tools that are actually worth using and contributing to them is like trying to changing something in government. The javascript ecosystem is much more open to new contributors. Maybe that is the reason for the lower quality of tools, but I, for one, enjoy that quality of the javascript ecosystem over ruby.

Collapse
jaredcwhite profile image
Jared White Author

Bummer. I'm sorry you've had that experience. I've mostly had nothing but friendly encounters with other Rubyists and am maintainer on several Ruby projects, but everyone's journey is different of course.

BTW, I'm not actually arguing that the JS ecosystem suffers because it's too easy to contribute to. In fact I think that's a bogus argument. Most of the problems I've had are with the top tools in their field—some with large amounts of cash thrown at them by VCs and Big Tech. The quality/complexity problem most definitely isn't an inevitable result of questionable NPM contributors.

Collapse
akashshyam profile image
Akash Shyam

Hey! After reading your post I haven't understood the problems with JS. I know it has it's limitations but JS is expanding with new APIs. Could you give some specific examples for the issues you face. I use JS(frontend and backend with node) and it works fine.

Collapse
brianmcbride profile image
Brian McBride

I can't agree that Ruby is a superior option to NodeJS. And I also won't say that Node is the best solution for building services.

I build a lot of services and manage teams that build services. When we build for Node, we use Typescript. Type safety does help the developers. My Go developers love go. My Java developers just have used Java forever - same with C# developers.

What I do see is that C# and Java both have. a lot of historical ways of doing things. Springboot and .NET are both well-baked libraries. They also tend to drive developers into building monoliths and always choosing SQL databases. Since our development target is usually highly scalable serverless architecture, we often have to continuously break those patterns.

But, honestly, I don't find that I am spending a crazy amount of time debugging libraries. I do thing documentation sucks for too many NPM libs, but since I am doing client work I need to stick to pretty popular/supported packages.

Collapse
yucer profile image
yucer

I would just say... If you see a problem ... you see a Market.

So from a optimistic perspective we can say ... the more standardization in framework and tools the more solid is the development.... but the opposite provide more competence and speed in the ecosystem evolution.

Collapse
capripot profile image
Ronan

People want to advance their career. If you release something in the JS's open-source world, you can get career advancement, conference spots, views on Medium etc. And these are rarely indexed on quality, rather quantity and shininess/newness.

I think that's the consequence for having the world moving toward virtual/internet. It's a broader audience, it's harder to differentiate, and to make it known. So one use marketing strategies, often disregarding the real work (one person has only 24h/day..).

Collapse
frozenbyte profile image
Frozen_byte

JS got a rather young boom. With such a hype of course there is an overwhelming choice.

The Time will filter the lowers. And the quality will sustain over time and become a standard.

Yes. Currently, JS is chaotic and overwhelming. I consider it as a good thing in the long term.

Collapse
jaredcwhite profile image
Jared White Author

JavaScript is 25 years old. Node is 11 years old. React is 7 years old. Given that, I have no confidence everything will inevitably get better soon.

Collapse
acezalba profile image
Ace Z. Alba • Edited

Though this article is indeed a bit ranty, I am actually sympathetic with how horrifying the JavaScript world is becoming for beginners. The dependency hellscape, multiple frameworks competing for attention, and the sheer number lf opinions that are clouding the development landscapes that makes it both confusing and painful for beginners to know what should be followed.

For developers with solid fundamentals, navigating the JS landscape is a breeze, because they are familiar with what problems the frameworks are trying to solve. However, for beginners, what is happening is that trying to learn JS is becoming more of learning the tool than learning the why of the tool, and shifting between frameworks becomes incredibly jarring. Couple this with the way the framework explosion is making job requirements more unreasonable.

It is partly because of JS that i decided to step back and learn Java development instead because of its relative stability and maturity, which gives me ample time to learn problem solving principles in software development that i can carry in between languages.

Collapse
edwinm profile image
Edwin Martin

What I often see is that developers are used to an other eco system (like Ruby) and try to apply their mental model to the JavaScript eco system and they discover there's a mismatch.

And instead of learning the new eco system, they start to fight it, and blaming the new system for not matching their own model.

Another problem I often see is the "JavaScript is a simple language" idea. And then complain they actually have to learn the language.

The strange thing about this article is that not one example of how bad JavaScript is, is given.

Even more strange is that one aspect of modern JavaScript development that's regarded as backwards and unfriendly to beginners is WebPack. And then the author writes: "I've actually written a Webpack plugin and found the experience enjoyable."

If Jared started out with JavaScript and then would switch to RoR, he would've complained about RoR.

Collapse
jaredcwhite profile image
Jared White Author

Well I started out in PHP to be honest. No wait, I started out in BASIC. 😄

I've also worked with Python, Objective-C, and a bit of Java. Dabbled in Swift.

I never said I hate JavaScript the language, quite the opposite in fact. I don't think it's a great language, but that's somewhat due to its very odd origin story. It's gotten much better in the ES6+ era.

The problem is virtually nobody ever uses "just" JavaScript. Many languages come with a robust "standard library", but JS doesn't (Node maybe a little). You have to import everything yourself. So the quality of the experience writing JavaScript is particularly dependent on the quality of the ecosystem of libraries and frameworks available for it. That's where my beef lies.

If Jared started out with JavaScript and then would switch to RoR, he would've complained about RoR.

I've programmed JS much longer than Ruby.

Collapse
kigiri profile image
Clément

Honestly I have an issue with demanding anything from open source project.

Don't like them, use something else, quality library and tools do exist in JS, but it's also a community that embrace change and experimentation.

Multiply the size of the community with the ease of making your own library, this can lead to madness in this ungoverned NPM land.

Deno is an attempt to unify the community, but before the stabilization of the STD it's not a suitable start point for production. A move in the right direction non the less.

Node API is also pretty rich and fairly well documented.

My solution in the mean while is to use as little external dependencies and tools as I can, try to find what I need and avoid to try to NPM install your problem away !

Collapse
akashkava profile image
Akash Kava

Its not problem with JavaScript, it is problem with money !!, open source developers do not have money, and are not liable to maintain as the MIT license does not offer any warranty.

GitHub's sponsorship program is heavily biased towards western county developers. It is not fair and open to whole world. Also sponsorship does not guarantee support.

Open source JavaScript frameworks and packages are somewhat "One man's junk, another's treasure", so if I wrote a piece of code, I put it in GitHub and someone might find it useful.

Collapse
ryansolid profile image
Ryan Carniato

I can appreciate the sentiment, but things are still moving at a rapid rate. It's possible that given that, not enough people are working on the tooling, or there is too much fracturing. But this isn't a new problem, nor one that isn't actively being worked on. The problem is that by the time any project has reached maturity something "better" now exists. Partially due to the facts of shifts in the languages, shifts in best practices, or even occasional innovation.

So while there may be this overhype thing going, you see it again in the comments when people are offering ways to consolidate. For example, Deno and ESBuild, are relatively new technologies. The reason for the overhyping might just be as much of a combatant to try to drive people the "right" way. It's hard to argue either of those projects for example is not a sizeable improvement. Now apply that to everything.

What motivates this. Well, it is UX and DX the same very things that ultimately we fail on. Now the grass is greener syndrome definitely has its role. And in that sense, this self-propagating. Bad DX leads to the next mismatch. Stuff does wade to the top over time. But I also think there is some amount of use to this. I think it is less the DX (unless that is the focus) but rather the incremental desire to improve that drives most of this. Is it necessary.. probably not. But it definitely feels like the cycle of improvement moves faster than anyone can keep up with. And no one wants to be left in the dust.

I get annoyed by the marketing hype and have been vocal about that. But it isn't like it's wrong. Svelte 3 (2019) represents a big enough paradigm shift that it probably deserves your attention. Now, one could argue that the writing was on the wall and if we were more attentive maybe we would have skipped over the last hype solution. But for a decade straight other than the odd patch, things haven't slowed down. Not even remotely. Picture if something groundbreaking as Rails or ActiveRecord came out every 2 years. That's basically the JavaScript ecosystem.

This is a maturity thing, and JavaScript seems to be forever young. There are some mature solutions people can go use. But standards can't even keep up. Like Web Components are great, but if you were hoping to use them solely as a framework, frameworks have moved on from there. They look dated. The capability of the tools already looking so much better than the next standard to come out. I mean a certain amount this comes with the territory. It takes time to standardize.

Part of this comes from the fact that through tools like Babel we've been able to create our own language to a degree. These have become so much a part of what we do we have meta programming of metaprogramming. It's like Skynet (Terminator reference). The machines are responsible for creating the machines. Now that potentially puts things in a myopic place. Maybe we've lost touch. But like a train that has gone off the rails, we are flying on a trajectory that has already been set. I think it would take something monumental to stop it. Or even slow it down.

So enjoy the ride, or not. You can always use Rails, or do it old-fashioned with notepad++ and index.html. In fact with things like Skypack(also relatively new) it hasn't been this easy in years to just pick up a package and go to it.

Collapse
bracikaa profile image
Mehmed Duhovic

Well, every language or ecosystem has its drawbacks, C++ with its huge compiling time, dealing with memory, bad optimization, Java is sluggish, C# doesn't run on Linux (as a Linux dev that is really bothering me, having to run VMs all the time)..., and hacks are part of the game, maybe more in JS than in other languages but still (anyone remembers the inverse square root?)

I came from C++ and I fell in love with JS, and it is a tough relationship, but I love that little bastard :) I also hate often on it but mostly because it is everywhere.

A smart guy once said - There are only two kinds of languages: the ones people complain about and the ones nobody uses

Collapse
eidellev profile image
Lev Eidelman Nagar

My initial gut reaction is to stand up for the ecosystem and language I love and work with every day, but unfortunately you're spot on. We do need better tools and real frameworks.

Collapse
devdufutur profile image
Rudy Nappée

Please put some examples dude... 😓

Collapse
jaredcwhite profile image
Jared White Author

Industry: JS fatigue, people walking away from their careers, fullstack design patterns invented often to avoid writing frontend code, multiple competing "standards" on every level, etc., etc.

JS Devs: we need more examples.

Collapse
devdufutur profile image
Rudy Nappée

Ok now you're the voice of the industry... Maybe the Ruby industry who represents 10% of the programming industry ?

No example, no fact, no interest.

Collapse
hemiltherebel profile image
Hemil Ruparel

Biggest problem with JS is low barrier to entry and no collaboration

Collapse
alaindet profile image
Alain D'Ettorre

I honestly don't understand what these errors you mentioned are really about. Just a personal note: I think it's unfair to compare JavaScript to Ruby, since JavaScript is at least 10 times more used than Ruby in a surprisingly wide variety of environments. It's obvious that the more people use anything, the more they find bugs and either complain or fix them.

Collapse
michi profile image
Michael Z

There's always Adonis.js on the backend if you want something Rails-like ;)
adonisjs.com/

Collapse
uzitech profile image
Tony Brix

Enough with the hyperbolic statements like "It includes everything you need to build fantastic applications". Lol that is Ruby on Rails.

Collapse