Hacker News new | past | comments | ask | show | jobs | submit login
The JavaScript ecosystem is a hot mess and so is software development (nadh.in)
102 points by opsec on Oct 17, 2021 | hide | past | favorite | 90 comments



This is a rant I can appreciate. Two subjective takes on the same subject:

1) As JavaScript became ascendant, it seems like developers lost their fear of dependencies, for some reason I don't understand. Dependencies came to be seen as "time saved" rather than "something out of your control that can hurt you."

2) When dependencies don't fit together, things fail in a way that makes it look as if the code is simply wrong. Yet everyone working in the environment ends up conditioned to run to google with the combination of (circumstances, error string) to find someone who has figured out what the actual dependency issue is. It's automatic behavior. At some point it would make sense to include automated googling in the CI pipeline just to add some necessary information to the errors.


I agree strongly and think once you regain your fear of dependencies the JS ecosystem actually isn't that bad. The kinds of packages that save me months or years of work are generally of reasonable to great quality, it's packages that (theoretically) save a couple days or weeks that tend to be the real stinkers.


I’ve definitely spent a ton of time on dependency work. I think the web app ecosystem is unique compared to its counterparts because the platform is really not designed for applications; it’s designed to render documents. You get so much more out of the box when developing for proper application platforms like iOS. For example, dealing with dates and internationalization. iOS gives you enough tools to not really need an extra library. Not so with the web.

Plus, the std for these platforms is much larger too, because you get access to the huge API surface the platform provides. Apple has spent a significant amount of resources making the platform decent to develop for. They even include reactive UI patterns out of the box now; something you’ll need a library for on web.

I think that’s the real shame. The web platform is very flexible and ubiquitous, so most people try to target it. But in doing so, you’ll need to account for web standards differences across browsers (using a tool like browserslist), the cost of downloading the source code when navigating into a page (with webpack and minification to make bundle sizes more reasonable or split up), and the cost of not having strong default patterns for stateful, interactive UI.

Every other platform will include nearly all of the tools you need within the IDE and on the platform. Web just doesn’t have that, unfortunately, and it has further problems that really don’t exist on other platforms. (For example, other platforms don’t rely on downloading the app source code from a remote server when launching it every time.) It relies on the open source community to provide solutions to so many problems, resulting in the complex dependency trees we see in large apps.

On the one hand, the OSS spirit is admirable. There are competing projects for nearly everything, similar to Linux programs. (Just like there are many Linux dependency managers, there are multiple JS dependency managers.) This allows projects to “get better” by competing with each other, but at the cost of breaking changes and maintenance over time. (For example, there are many projects aiming to provide the fastest JS bundler.) But there is something to be said for having an opinionated platform with more features like iOS or UWP for windows.

All that to say, I don’t think this is a JS shortcoming, but a shortcoming of the web platform in general. And some of those shortcomings are inherent to the benefits of the platform.


A side rant: for some reason in recent years it has been OK to make breaking changes. I remember a time when these were considered a nuclear option -- now popular libraries will make breaking changes for minor aesthetic reasons, resulting in billions of wasted developer hours changing foobar to foo_bar.


Yup, this is what major releases are for and frankly we need more people like Linus reminding people don't break your external APIs!


Some projects _never_ make breaking changes, and major version bumps represent major additions.


Very true and these are the gold standard in some regards. But not everyone has a crystal ball and are beholdant to external factors they don't control. E.g. the pcie bus evolving forces Linux to change, and not all change is bad.


> At some point it would make sense to include automated googling in the CI pipeline just to add some necessary information to the errors.

Sounds like a decent feature to include in a compiler!


I installed ESLint into a new project and my package.lock file expanded to 3000 lines. I understand what problem it was trying to solve but the sheer inelegance of it sort of gives everything a jank feel, like you have no idea what’s running.

Or perhaps it’s more that it’s exposing a bunch of things that are hidden or tucked in standard libraries in other languages.


hep me understand this. I need a binary called eslint. I put its version x as a dependency. why can't i just get a fat eslint@x blob of code? Why do I have to care to fetch all eslint's dependencies? is this because they don't "bundle" things like eslint? Should they then?


> for some reason I don't understand

Fear of writing original code. There is less perceived risk (actual risk is slightly increased) if you can defer blame.


it's not true that all this mess was caused simply by irrational emotion. There is actual cost involved in writing original code.


How much?

Until there are numbers, as in qualified by data, its all irrational. It doesn't matter that something costs money. What's important is how much more it costs (the difference).


People don't add more dependencies into ther code out of fear that's just a weird idea.

I'm not saying I know the cost, I'm just rebutting the comment about this being driven by fear. It's not, this is cost saving, and might be lousy at that, or not data driven.

By the way there is no such thing as "data driven software methodology", no one has ever done such a thing, so asking for it is just rhetorical.


> People don't add more dependencies into ther code out of fear that's just a weird idea.

Weird or not it is the reason and most commonly expressed as vetted by the community.

> By the way there is no such thing as "data driven software methodology",

There is. A/B testing is a form of that. Running tests and experiments, even against developers, was my job for awhile.

What I find most strange is that this comment expresses the opposite position of your prior comment.


> vetted by the community

I think that's the reason why a certain 3rd package is chosen.

the decision between roll your own and 3rd package often comes down to whether you want to sidetrack engineering _right now_ to write code that's not your product's functionality.

> A/B testing

you're talking about data driven product decisions. What we are talking about is data driven engineering decisions. Show me one article on such experiment?

the first problem is that there is no data. Last I checked developers are not fond of telemetry in their dev tools.

my point is not that's it isn't desirable. It's just not a thing that exists to bring up in arguments.

there is a difference between emotions (fear) and heuristics (this will cost time and is potentially buggy). I mean they are actually same in nature but at different points on the spectrum.


I'm embarrassed to admit that for web development, I'm afraid to try frameworks like React/Vue/Angular as well as package managers like NPM/Yarn. So I settled on writing raw (X)HTML code and using only vanilla JavaScript APIs provided by the browser (ECMAScript standard library, DOM, multimedia, etc.).

Because of this, I can't bang out complicated software quickly and easily like the stereotypical front-end developer. In exchange, the techniques that I learn essentially don't go out of date and don't randomly break. I settled for only applying what I understand.

I made an exception for TypeScript; I acknowledge the compiler is enormously complicated and requires Node.js to run. But static type checking has saved me from my own silly mistakes very often. And if armageddon ever comes, I can always strip out the annotations from existing TypeScript code and continue with plain JavaScript.


I work on a dependency-free, build-less library called htmx:

https://htmx.org

It's more an extension of HTML than a JS library. It might be a good way to gently introduce more dynamic behavior without blowing out the complexity of your projects.


I am with you. Don't be embarrassed. I spent a lot of time looking at Vue, React and the others and frankly I don't see how the time and effort are worth it unless you work in a large firm that has a lot of developers working on a large project.

I use npm and node because it allows me to write local tools that I write to help me manage data and convert it. I have a lot of other tools that I have access to but I can thankfully access it via CodeKit on my Mac so I don't have to waste time installing and learning them all.


> I made an exception for TypeScript

I was nodding my head until TypeScript. I still don't like it even after years of people telling me it's the future. Maybe this is what it feels like to be older.


TypeScript's the first thing that's made JS tolerable, if I have to touch or use anyone else's JS code. It's pure misery, otherwise.

Writing solo and using no libraries, plain JS is... OK. Anything else, TS is the only thing that keeps me from hating life the whole time I'm working in JS.

FWIW I'm a huge curmudgeon who's usually (eventually) proven right when I hate some new thing that everyone else seems to think is great. TypeScript is wonderful.


Nah you're probably just wrong. Generally speaking it's the older more experienced developers who demand typescript in my experience.

Writing raw javascript is genuinely painful, I literally don't understand how people can even do it. Like, how do you even refactor code safely?


>" I literally don't understand how people can even do it."

While I definitely appreciate types and normally work with the languages like C++ sometimes I do some front end JS libs and frankly do not have any mental troubles using plain JS. As for whether it is "safe" - all that matters to me if it works to specs and the customers are happy. Since I am programming since like forever I guess I've got enough discipline, common sense, knowledge and experience to produce decent code.


> Like, how do you even refactor code safely?

I've never had issues doing huge refactors in JS. But thanks for telling me I'm just wrong.


I think that’s where unit tests come in. In Typescript, I have seen “any” type everywhere that doesn’t make things any clearer.


> Like, how do you even refactor code safely?

for me I make sure to write thorough unit tests along with clear, concise code


I think you can combine that with static types and come out further ahead.

To each their own though. I wrote code without any kind of autocomplete or tooling for a very long time because I felt like it. Sometimes when you don’t have something helping you all the time, it keeps you sharper.


As someone who has mostly the same approach, I too use TypeScript. It makes JS saner and brings it closer to its more advanced cousin from the past, ActionScript. It also adds proper Java-like classes with inheritance, which I, as primarily a Java developer, appreciate a lot.


What don't you like about it?


I'm a huge TypeScript proponent, but it took me a long time to get on board because getting it into an existing project structure is not easy. I don't even mean the translation portion (which you're also probably doing as you first learn the language), but the configuration of the tool. There are a lot of options and none of them are labeled "please just find my missing dependencies. I can see them right there".


Sounds like a solid/healthy strategy to me.

With ignoring package managers, do you mean that you instead of running "npm/yarn install/add <package>" you inspect said package (which does what you need) and cherry-pick the functionality into your own codebase (or just outright copy it if its functionality is elementary to you), or that you try to write/reimplement it yourself?


The browser environment enables you to do that, so why not. No dependencies. But do you build everything in house then (time unlimited), or the apps are not that complex? It is the same mindset as writing assembly or small Win32 in C, which I both admire and respect btw.


To get a good setup in JS there’s a ton of things that are nativeish in other languages (at least via IDE) that are wholly exposed via the package management stuff. The upside of the configurability is you can mix and match, and build something that works great for your needs and your project. Different framework, different test system, different linter, different SQL wrapper, etc. The downside is that it’s overwhelming, even when experienced with it.

I would suggest starting with a bundle created by create-react-app - you will get most of the cool tooling out of the box, and discover the usefulness of some of the libraries.

Having a live loading web app is a really neat and productive way to develop - but getting there can be daunting.


Despite the bandwagoning here, I'm going to say it's the authors fault.

They updated dependencies blindly upping the version of packages a leading digit. Of course things will break! That's what the leading digit is for!

Yes, there are problems with too many dependencies, but upgrading packages just because you feel like it is a recipe for disaster even with very mature dependencies with good governance.


I agree. I also think the author blindly followed up on some automatic GitHub bot suggestions only to find out you can't just upgrade everything.

My experience is actually the opposite: it's never been easier to develop at scale in frontend. People forget how hard frontend is. You need to ship everything and it needs to work everywhere. You have zero control over the code execution environment. The fact that build tools like Webpack and frameworks like Vue/React exist made it a breeze to quickly develop high-quality web applications, and that is actually a triumph of the JavaScript ecosystem.

Ofcourse it's difficult to understand the entire build chain, but often it's not necessary to understand every detail. If you use vue-cli/create-react-app you get a perfect bootstrapped environment that works out of the box. If you really need to upgrade, I would suggest creating a new empty project and migrate all the code to the new project, instead of changing dependency version numbers in package.json.

My personal experience is that I've run into quite some issues, but not necessarily more than when doing anything backend related. I've spent weeks trying to understand the Python module system. And worse, Python doesn't even have declarative dependency management built-in. Also it's very difficult to find high quality packages because there's hardly anything like npmjs.com for the Python ecosystem.

That being said, I love both JS and Python, but I don't think of the quirks of both languages and their ecosystems as a "mess", but rather an understandable reality we have to deal with it that is definitely worth the trade-off. Innovating and backwards compatibility are often orthogonal direction so it's definitely not easy facilitating both.


Exactly. The real "problem" is how easy it is to install and upgrade packages.

They took the painful part out of library management, and now they expect breaking changes should magically be resolved.

The funny part is that there is no comparison to other development ecosystems. "Oh yeah, in C++ we don't have this problem, since everything is even more painful"


So, `yarn upgrade` broke something, probably because some package down the road didn't respect SemVer. I guess failing to respect SemVer can happen in any ecosystem, now in other ecosystem you could have sealed dependencies that an upgrade can't break, but then it makes the whole upgrade action moot. In summary, you either, not upgrade, go deep in your lock-file and fix it manually, our you update your main depenency like you did. If your UI library doesn't support the new version of the framework, you either change the library or you bail out on upgrade for the time being.

It seems pretty reasonable process to me, I feel your pain on the wasted time and I wish github issues have something like "current answer" so we don't need to go through pages of comments to find out how to fix or workaround something. In any case, lock files are there to help and make everything more static like in other package managers that don't support the same kind of dynamism. Upgrade is just like wiping your lock file.


Yeah, while I think the blame lies on both Vue and the author, I feel like the author is shifting too much blame off of himself.

Vue messed up because eslint wasn't pinned I assume (looks to be pinned now at ^6.7.2, so it shouldn't happen anymore) so upgrading gave you an incompatible eslint version.

Author messed up by blindly upgrading all dependencies, jumping major versions, and expecting everything to work fine without putting in work to double check. Yarn even has a kind of `interactive-upgrade` command that shows versions/links to changelogs iirc. There is also documentation for upgrading project dependencies at [this link](https://cli.vuejs.org/guide/installation.html#project-depend...) that I came across while playing around with vue cli.

I took the liberty of generating a Vue 2 project and seeing what dependencies are in the package.json

    "dependencies": {
      "core-js": "^3.6.5",
      "vue": "^2.6.11"
    },
    "devDependencies": {
      "@vue/cli-plugin-babel": "~4.5.0",
      "@vue/cli-plugin-eslint": "~4.5.0",
      "@vue/cli-service": "~4.5.0",
      "babel-eslint": "^10.1.0",
      "eslint": "^6.7.2",
      "eslint-plugin-vue": "^6.2.2",
      "vue-template-compiler": "^2.6.11"
    },
I don't think it's too bad if you've ever seen create-react-app unloaded or whatever, although I've never used Vue so I could be missing the equivalent unload step that generates a million more dependencies.


Upgrading dependencies is never a safe operation regardless of what semver tells you. The version number is a suggestion and not a promise. I have had minor patches break things because it turns out that my app is depending on a behaviour which is a bug. But it’s no big deal, upgrading is something you plan out and spend the time on. Upgrade them all at once and spend the time testing everything and reading change logs.


Yeah for my new startup I decided to avoid javascript except where its absolutely necessary and then use css plus lots of server side python including template generation and system and database management. I was using spa+soa with node and angular, react and vue for years but decided to use django especially because it has a great security track record and changes very slowly and doesn't require tons of extra libraries outside of django.


I'm starting to do this with Elixir, even though I used to have a very favorable opinion of React on the front end. When you have a small, focused ecosystem when dependencies often have few or no upstream dependencies, things just work better. The story around testing in my preferred stack is miles better than anything in JS land, and runs in parallel. One of the apps I work on has thousands of tests and the test run is under 4 minutes for all of them. They almost never break when dependencies are upgraded. It's really nice.


This is a great strategy. Kudos to Django for simplicity and stability!


JustPy has been my dream come true for python based web-development.


The JS Ecosystem + The AWS / Serverless ecosystem is a love story of the likes of Harley Quinn and the Joker.

This week I picked up a gig working on a website for a non-profit organization, the needed some basic changes to a few forms. The reason they had to hire me, a web app developer, the site was built by some agency with Next.js / Jam Stack technologies, Contenful, AWS Lambda, AWS Amplify etc.

This simple website, is one of the most complicated monstrosities I've ever worked with. Every page downloads multiple megabytes of JSON from the Contentful API just to render dead simple pages with text and images. Every time there's a change in contenful, a new build in AWS Amplify is triggered to generate the site to static content... only the React code is so complicated with so many round-trip, nested server requests (n+1+1+1 etc) that the builds fail constantly because the API server (on lambda of course) which serves the Contentful content basically gets DOSed. I had to write logic to retry all app API requests just to get the builds to consistently work so I could work on the website. The code that transforms these megabytes of JSON into webpages must have been written by a mad man.

Also screw AWS for not building proper tools to debug AWS Lambda. Not having to manage servers sounds awesome, so everyone has started using lambda, but the developer experience of having to wait 10 - 15 minutes just to add a console.log line is like pulling out your own finger nails and then scraping them on a chalkboard. Then AWS built the most noisy, difficult to use and hard to navigate log management solution on the planet (CloudWatch), and started sipping their beers.

You can avoid these technologies all you want, but one day you're going to have to work with a project that choose to use them, and you can't control that. I believe library authors and service providers have a responsibility to think about developer experience that's being ignored. Or perhaps, since developers don't always have a choice in the technologies they use, building easy to use developer tools isn't worth it.


It isn't just JS apps that are like this though. I had to redo a site for a client a few years ago that was done in some horrific php CMS that had a whole site management architecture applied overtop of it. It was a nightmare to even change a page.


I can definitely appreciate rants like this, and I think anyone who has been in JS development for a while has hit some sort of dependency incompatibility headache like this. That said, I'm also always left a bit annoyed when the author isn't really introspective to think about what benefits came with the environment he is bitching about.

As much as everyone loves to complain about "dependency hell" in the JS/Node ecosystem, the fact that there are tons of high quality (or, at least discernible quality) components, largely for free, is something that really didn't exist before say the mid '00s. I'd also highlight that "component reuse" was literally the holy grail of software engineering for decades prior.

The simple fact is that to get the benefit of a very robust dependency ecosystem requires more work managing those dependency versions. Running the equivalent of `npm update` on a regular schedule is pretty much required lest your dependencies get too far behind, and then when you are forced to upgrade due to a security issue you find you have tons of backwards incompatible changes.

I'm not saying things like NPM can't be greatly improved, but I think it's important to acknowledge the benefits that the JS ecosystem provides.


> As much as everyone loves to complain about "dependency hell" in the JS/Node ecosystem, the fact that there are tons of high quality (or, at least discernible quality) components, largely for free, is something that really didn't exist before say the mid '00s.

CPAN for Perl and Java's rich set of libraries come to mind from before the mid 2000's.


Actually, I think the comparison to Java is a good one. Java had a pretty good standard library in the JDK (though I'd argue the latest ES and Node versions are pretty on par), but what it really had going for it was Apache Jakarta libraries. I think pretty much 95%+ of open source Java I used at that time was Jakarta.

The difference with JS is that there are actually a ton more open source libraries available in the NPM world, but there is not an overarching project to bless some of them as "standard" and high quality (though I could see some of the Deno libs changing this). Again, it's a tradeoff - there is much more choice but that requires more management.

Also, FWIW, I had many more dependency upgrade nightmares in Java vs. JS, primarily because Java's nominal typing can be very unforgiving (vs. Typescript's structural typing). I still have PTSD from Jersey 1.x to 2 upgrades.


You are 100% right. People simply want everything: rich, flexible and robust API's. That's not possible. Pick 2, not 3. Also think of the time you have saved by building on top of so many building blocks. Everything's a trade-off.


I stick to pretty minimal dependencies (and more recently, simple build systems like esbuild or parcel) and I don't have a terrible time maintaining things over the years. But I can sympathize (to a point) with folks who haven't learned this lesson.

The more packages you bring in the harder it will be for you to upgrade (anything).

You have to learn over time what you must have implemented in a third party library and what would be better for you to maintain yourself.

I do wish there were a public grading system for JavaScript libraries that failed them if they bring in X dependencies or have low tests coverage. Any automated way that publicly guided/shamed library developers toward fewer dependencies would be welcome.


I agree and have quit Javascript completely. The ecosystem just feeds on layers and layers of abstractions. It seems the mantra is complex is better than simple in JS land.

Been developing with an HTMX/Django stack[0], and it has been a wonderful experience so far!

https://htmx-django.com


What's worse: the JavaScript community has normalized making frequent breaking changes, something that used to be forbidden and considered a no-no, and this cultural practice is bleeding over into other languages, unfortunately.


Life is too short to put up with this nonsense. My take is the JS ecosystem is dominated by devs who like programming more than they like solving problems via programming. And that’s fine, but the culture doesn’t reign them in, and everyone takes a maximalist approach to things, believing that just a bit more JS would make things a little less crazy.

Fundamentally, the web is not a great application platform. Decent, yes. This is the fact that cannot be papered over by more software.

I left webdev back in 2012 after doing Rails. Best decision I have ever made for my career.


To be fair, I have had the same problems with Java, C# and Python packages. It's simply not an easy problem[1] once the project dependencies grow. It is a bit more apparent in JavaScript ecosystem and it is cool to hate on ofc.

1. https://the-guild.dev/blog/how-should-you-pin-dependencies-a...


I like how the giant monorepos (like Google's) serve as a forcing function against these problems.

When all of your dependencies are developed on the same repo and are part of the same CI they just won't break you (at least not your tests). And when you'll come back to the project 6 months later you'll find it building and passing tests against the latest versions of all dependencies.

This forces you to have a decent test coverage (otherwise they'll break you).

It makes library authors feel the pain of their downstream dependents and carefully consider breaking changes (otherwise they will need to spend time fixing downstream).

It makes people hesitant to bring in third party libraries that aren't very stable compatibility-wise (as the "internal owner" of the third party becomes responsible for updating it and unbreaking the world).


plot twist: javascript frameworks are an invention of a cabal of backend engineers attempting to sabotage the client side of things


“Just one dependency”. The author makes it sound like this is trivial because they have a single dependency therefore it should Just Work™. Author should have included how many node modules were installed for the one dependency.

The closing statements are just mind blowing. To say vue/js don’t bother you but continue to shit on everything is a tired argument. Even bringing up PHP! What are you actually doing to make it better or are you just piling on to the same shit we’ve all been saying for at least 5 years?

Be the change you want to see, accept the bull shit, or just don’t use it. No one forced you to write a vue app.


while this might be a valid criticism of the blog post, i think it kind of sidesteps the issue that what it describes is a common experience while working on javascript projects. for me, pinning days are dreadful. sure, hunting in changelogs to fix issues can happen in my django projects as well, but the frequency is orders of magnitudes lower, and more likely well documented. ymmv


I have recently come back into web development after a long hiatus and this article really touches on a lot of issues I have had with JS development and trying to learn new tools and libraries. I really feel what that author is saying.

All of these cli tools that people use make me think of that boiling frog metaphor.


> Do developers have to take the overhead of worrying about the numerous dependencies in the toolchain as much as their own business logic?

I know this was meant to be rhetorical...but the answer is YES! ABSOLUTELY!


Out of curiosity what is the best counter argument to the general thesis, eg either what positives come entangled in the hot mess or reasons it’s not a hot mess?


High tool churn creates an ecosystem where you get paid well for knowing the new hotness.


That's a myth. I've been in a lot of tech interviews, no one gives a shit about what tools you use. Maybe things like terraform or docker, but not the libraries or tools inside the projects, no. You get a pat in the back maybe.


Getting to the interview often means your resume making it past a recruiter that doesn't know much other than keyword matching. And there's plenty of job listings with granular things like redux, eslint, webpack, and so on in them.


I'd put them on the CV and add a line saying many of these are for SEO. No need to actually try to master them. Find more interesting things to learn that can enrich your software engineer mind.


Currently getting paid in the 4th percentile in Australia as a ruby/js dev with no formal education. Who cares what the js ecosystem is like if companies are willing to shell out whatever it costs to get devs to work on their web app.

Having JavaScript app devs is basically a license for companies to print money right now.


how do I find out what percentile I'm in?



I think this is the best defense of the churn.


The other side of the coin is that we are getting better tools. Vue 3 with the composition API is a lot easier to work with, reason about and maintain then the legacy API.

However the real counter argument is that vanilla javascript apps are also easier to write these days. If you have only a small interface to something that you have to maintain but only infrequently, perhaps a vanilla app is better suited. Vue apps are better suited if you want/need to a) get things running quickly (e.g. a prototype) and/or b) have a team of developers which need to maintain a large codebase together.


A developer today can create better apps with less experience today than they could 20 years ago.


Its a result of a lot of trial and error and finding better way of doing things. I dont think anyone likes it, but its byproduct of moving fast and of requirements changing.

Personally I think the web-frontend ecosystem is getting closer to stabilizing. For example React has not been changing much recently in its API and most of its development happens under the hood. A counterexample right now is bundlers. Webpack was the king for a long time, but it has gained more and more features and the code bases it is working on are bigger so its getting slow and complex. Competitors like esbuild and vite that are simpler and faster are popping up. However this is not the fault of webpack but simply that the requirements has changed so much and webpack always had to follow the requirements. Now that the requirements are starting to stabilize new alternatives can be built that can skip all the cruft.

I find it interesting how people in this thread are praising python frameworks for being so stable, I'm in my mid thirties and I clearly remember a time when they weren't.


That while it might be difficult to articulate, the churn of technologies does represent a meaningful search and forward march of progress. The churn is the result of ever more rapid progress on an increasingly abstract knowledge system. However, it is hard to recognize positive structural change as just another worker bee in the hive.


I don't buy this. The whole thing is enabled by hard work of browser developers enabling all this hot mess without much performance impact. JS is blazing fast and it creates a massive wild-wild-west of framework gold rush. Instead of being responsible, they create ever more bloatware that doesn't stand for 6 months.


It's interesting you chose "march" because I see it as not that. There is rapid forward progress, as you say, but it's individual parts sprinting at different paces. "March" would imply they were moving together.


This is too simplistic. Progress is not inevitable. There is no guarantee that the objective being optimized by the JavaScript Community(tm) is necessarily a better one than before.

Churn can easily be driven by fashion as much as what you call “progress.”


Don’t install a UI toolkit dependency because you heard it’s the new hotness on Twitter?


Either you move slow and keep things stable, or you move fast and break things.

Pick one.


well you can always write your own framework. I'ver had to do that a few times and the main benefit is that it fits your coding style and you're the only one that can break it.


From the recent trend I'm seeing in Hacker News, I'd suggest to the faint of heart to stop using bootstrapping utilities..


This reads more like an issue with Vue (social, not technical) than a valid criticism of the JS ecosystem.

Vue.js is a great project for front-end enthusiasts, but if you look at business objectives (aka getting things done) you would want to use React for any web app: The ecosystem in terms of libraries, help articles, developers is at least 10x bigger.

The release of Vue 3 definitely makes this situation worse for a couple of years in which using Vue 2 is still an option. Effectively fragmenting the Vue-camp further.

TLDR: Use React with vite and pin your dependencies to avoid everything mentioned in the article.


I disagree. The React API arguably changed more often than Vue. Remember the migration path from class based components > functional components > overly complicated React Hooks? And how about styling components? There are millions of ways doing it. Let alone the fact that routing and state stores don't have any first party support.

Vue in that sense is really simple: Vue + vue-router + Vuex still work together in the exact same way as they did 5 years ago.


The main issue is nobody is thinking for themselves, nor are they thinking critically about their call stacks...


Somebody teach the young ones. You need a text editor. Git is a very nice to have. Everything else is optional.


I ditched javascript long ago for exactly this reason. Spaghetti dependencies everywhere you look.


Back when I was originally doing web development I wouldn't have touched JS but I actually quite like it now. It might just be a sign of early-onset dementia though.

I doubt that I would have enjoyed developing in JS before JQuery or the new extensions added in ES6


Their are a few rays of hope. 1. Htmx 2. Alpinejs 3. Express


We need a Casey Muratori for the web.


tl;dr blindly upgrading 100s of dependencies didn’t work out. But, is this instability due to the ecosystem, or the choices of the developer?

I work on a large, highly interactive web app that does a lot of the fancy stuff like code push to native apps, offline caching, heavy use of browser storage, real time collaboration. Our stack is React, Express, Typescript, built with Webpack. Every year or so we upgrade one of these major components, like Webpack, which does take a week, following a semver major migration guide, but usually nets us some performance and developer productivity wins. I’m sure if I tried to upgraded all our dependencies at once, it’d explode. So, we don’t do that.

Maybe I sound like a C developer arguing “C unsafety is fine, just don’t make mistakes”. There’s a ton of hype around JS libraries — of course there’s bigger hype waves in this ecosystem given its population and ease of publishing (compare to Java where you need to open a JIRA ticket to publish to maven central) but it’s a personal choice to follow fads like installing this ChakraUI thing or to use boring tools that you already know work.


Yours sounds like a reasonable practice, I do the same thing myself. I agree that it's up to the developer to make things easier on him/herself or to bring in unneeded dependencies or complicate the build process.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: