The JavaScript ecosystem is a hot mess and so is software development
nadh.in
nadh.in
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.
Fear of writing original code. There is less perceived risk (actual risk is slightly increased) if you can defer blame.
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).
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.
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.
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.
Or perhaps it’s more that it’s exposing a bunch of things that are hidden or tucked in standard libraries in other languages.
Sounds like a decent feature to include in a compiler!
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.
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 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.
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.
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?
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.
for me I make sure to write thorough unit tests along with clear, concise code
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.
I've never had issues doing huge refactors in JS. But thanks for telling me I'm just wrong.
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.
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.
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?
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.
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.
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"
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.
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.
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"
},
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.
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.
CPAN for Perl and Java's rich set of libraries come to mind from before the mid 2000's.
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.
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.
Been developing with an HTMX/Django stack[0], and it has been a wonderful experience so far!
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.
1. https://the-guild.dev/blog/how-should-you-pin-dependencies-a...
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).
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.
All of these cli tools that people use make me think of that boiling frog metaphor.
I know this was meant to be rhetorical...but the answer is YES! ABSOLUTELY!
Having JavaScript app devs is basically a license for companies to print money right now.
Churn can easily be driven by fashion as much as what you call “progress.”
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.
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.
Pick one.
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.
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.
I doubt that I would have enjoyed developing in JS before JQuery or the new extensions added in ES6
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.