DEV Community

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

The Shocking Immaturity of JavaScript

jaredcwhite profile image Jared White ・6 min read

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.

The ecosystem of JavaScript frameworks is almost unbelievably unstable. Yes, even now in the year 2021.

From backend ORMs and headless APIs to frontend site generators, package managers, and build tools—it's a miracle any of it actually works properly in production!

Some weeks I spend literally hours debugging and researching all kinds of weird, arcane bugs or conceptual hurdles related to performance, hosting, payload sizes, full-stack architectural gotchas, and the list goes on and on and on. And it's not just me. I'm on a team that is in a constant mode of struggle and churn due to dealing with largely obvious issues related to the most popular tools for backend & frontend JavaScript (at least according to their massive star counts on GitHub).

Now the reason this really grinds my gears isn't just related to my particular project. In a purely cynical sense, what do I care? I'm getting paid the same whether I'm writing code or debugging it.

The thing that bothers me is how awful of an experience this is for people with far less experience than me. I've been in this industry for over 20 years. However, other people are attempting to get into web development this year. And they're being told in order to do so they have to learn X, Y, and Z tools…all JavaScript of course. The problem is if they run into major issues—and they do, believe me, they do—they don't know enough to grasp just how buggy and incomplete the tooling is. Instead, they think they must have just made a mistake, or simply haven't learned enough yet. The cognitive load required is staggering.

Or perhaps they haven't run into too many issues yet. (Lucky!) That's possible, because the vast majority of tutorials and examples out there for the top JavaScript frameworks are laughably simplistic. If I see yet another example of how to use a GraphQL query to pull a blog post from a headless CMS to statically render an article using a component tree built with You-Know-What.js, I'm going to rip my hair out of my skull. This isn't where any real-world applications of any reasonable size get tripped up. The devil is always in the details. The problems typically arise well beyond the scope of clickbait-y "Build THIS in 10 minutes" articles.

How Do We Fix This?

The path to correcting any sort of systemic problem is to first acknowledge it and then to define its scope with honest and sober reflection.

We all need to start being forthcoming about just how shockingly buggy and incomplete most of the JavaScript tooling is across the board. Compared to what, you might ask? Maybe this is just an artifact of web development, period. It's the nature of the beast.

Wrong. You can hop the fence over to other programming languages, frameworks, and ecosystems, and discover that the tooling there is far more stable and usable over the long haul. I don't wish to turn this into a pitch for Ruby, but let's just say in my many years of extensive engagement with the Rails framework and related projects, I've never encountered the sheer volume of bugs, glitches, gotchas, and limitations which I encounter on a regular basis in JS land. And it's not just me…I'm in chat rooms and Twitter threads all the time where other folks are losing their minds over some latest craziness. All we can do is shake our heads and go take a walk or something to relieve the pressure.

So how do we fix this? Here's one suggestion:

Start Telling the Truth

Get off the off-the-charts hype machine, stat. Enough with hyperbolic statements like "this is the modern way to build the web" or "this gives you the best developer experience with all the features you need for production" or "write high quality, loosely coupled, scalable, maintainable applications the most productive way". (These are all real quotes, BTW.) The constant marketing is not only exhausting, it also feeds newbies a bunch of malarkey.

Start by being honest about what doesn't work as much as what does work. Warn people about building battle-hardened, production-level code on top of your buggy and incomplete foundations. Steer people towards other, better solutions—even other languages and frameworks—if you know your tool-du-jour isn't quite up to snuff yet. Slow down your progress on shiny new features and fix the features you've already shipped.

Label releases and techniques properly. It's perfectly serviceable to have something in alpha or beta state for quite some time, or to say a particular technique is probably only suitable for the stout-hearted with time to kill. Also, stop with the "old-school code" shaming. The world isn't going to end if you write something in a manner that's been proven to work for several years by now, rather than the "flavor-of-the-month" according to some code-school blog. We snicker at one person's var or another person's $.get to fix the fire extinguisher and meanwhile the house is on fire.

Feel the Users' Pain

This all mainly boils down to something we learn in the world of UX (User Experience) design—you have to feel the pain your users go through when they use your software. In the case of developer tools, developers are the users! That's why the term DX (Developer Experience) gets thrown around a lot now. The thing is, good DX isn't just some whiz-bang ooo, that's cool reaction to a new blog post. It's "how well will this work for me and my team over the next several years??!" In that sense, the DX of the JavaScript ecosystem has a lot to answer for. Sometimes you even see it in GitHub issue and PR comments: rude, curt dismissals of genuine problems people are having in the real world. RTFM is never the correct response to DX issues.

Again, I come from the world of Ruby—not perfect by any means. But we have a saying, MINASWAN, which stands for Matz-is-nice-and-so-we-are-nice. In other words, the creator of Ruby (known as Matz) is in most respects a pretty genteel fellow. So let's also be nice and help out our fellow developers, particularly the newbies. That doesn't just mean in terms of sharing ideas or providing education. It means the tools we build should themselves be pretty nice! Crappy code smell and lousy DX often gets called out in the Ruby community because we've been handed a high bar. Name your variables well. Reduce boilerplate. Use a small surface area for your API whenever possible. Cultivate well-organized codebases. Convention over configuration. Maximize programmer happiness. And so on and so forth.

The result of all this is I sometimes look at the bugs or issues with I deal with when using JavaScript tooling and my initial reaction is: this would never fly in Ruby. Developers would simply laugh and quickly move on to a better tool. I'm not saying this to prop up Ruby. I'm saying this to convince you that you need to demand more of your JS tools.

Demand more stability.

Demand more clarity.

Demand more honesty and less marketing fluff.

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

Stop putting up with the nonsense. The excuses have run out. How long have we had Node? How long has ES6+ JavaScript been with us? How long have we had other, more stable ecosystems to be inspired by?

Conclusion

You might conclude, after such a rant, that I hate JavaScript and just want to leave. Actually, I don't! 😅 There are JS projects I love which offer great APIs in my opinion. LitElement for example is one of the best developer tools I've ever used in any language. Native ESM support in browsers and modern CDNs like SkyPack are wildly exciting. I've actually written a Webpack plugin and found the experience enjoyable. In fact, unlike some fellow Rails devs I know, I rather like configuring Webpack. (Now who's the crazy one?!) PostCSS is a nifty Node project I benefit from every day. Shoelace web components are the bees' knees.

So I don't hate JS. I don't hate frontend engineering, and I don't hate Node. What I hate is developer tools with awful DX due to hacks upon hacks upon endless modules of widely-varying quality as a result of constant churn in "best practices" and what's compatible with what, where, when. I simply no longer have the patience to deal.

Thus I'm begging you—imploring you—if you build or maintain any tool in the JS ecosystem, pause for a moment and consider how you can reorient yourself around upping the long-term quality level of the tools you produce. And if you are a newbie, DEMAND your tools give you the quality you deserve. And if you do work on a tool that's actually pretty stable, fun to work with, and hasn't tried to take over the world with ridiculous claims—kudos to you! You're breathing rarified air. 😜

Discussion (148)

pic
Editor guide
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
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
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
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
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.

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

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

andrewmcodes profile image
Andrew Mason

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

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

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