A micro dependency system with never ending breaking changes to glue different tools and libraries together - bad idea.

Using un-opinionated "libraries" that don't scale well, but at scale - bad idea.

Technology organizations trying to stay relevant by simply adopting every next hyped fad out there, rather than stepping back to get a bigger picture of what the front-end space actually needs - bad idea.

The list goes on, for quite a long time.

And all of these issues are further exacerbated by an army of junior developers entering the front-end development space, along with recruiters subscribing to buzzwords to hire them.

Frontend web development is still absolutely painful and ugly. It's based on a broken paradigm (hypertext vs. interactive interfaces); relies on hacks for fundamentals (XMLHttpRequest is probably the best example); multiple standards pushed by organizations with special interests (remember having to encode video in 4 different formats?); is labour and time-intensive; tooling is still catching up with the 80's.

None of those, in isolation, are big problems though. The big problem is that, because you can always patch everything up with some javascript, there's no drive to have a platform that rests on top of more sound fundamentals - condemning ourselves to an endless cycle of frameworks.

I think it's mostly a perception issue due to the fact that front-end development was historically a poor experience and things have greatly improved in a very short time.

I am not against people trying to push front end technology forward, but it feels like we're just inventing a thousand different wheels when the first wheel wasn't really lacking much so long as you knew how to use it.

I am wary of any new JS library as if the past many years are anything to go by, it's practically technical debt the moment it hits v1, if it ever does.

Frontend work is unglamorous to a lot of developers but part of the more academic appeal is that it's still very much in its awkward teenage phase. That makes it appealing to tinker with and try to find a "better way." That's the churn.

Frontend is still a fast moving space with a large ecosystem - and I get for some, that's not ideal. But this 'frontend fads' meme isn't really reflective of the current reality.

Webpack - 2012, Next - 2016, Nuxt - 2016, Nest - 2017, Parcel - 2018, Blazor - 2018, React Hooks - 2019, Vite - 2020, Vue 3 - 2020, ESBuild - 2020, Sveltekit - 2020

They usually follow the pattern of 3 seconds of hype followed by 10 years of digging out a mountain of technical debt from some asshole who has since moved on.

I've heard so many front-end developers/designers say the opposite about their field though, and I wonder why that is. If the newer tools/frameworks are just adding more complexity, or reinventing the wheel, couldn't you just choose not to use them? I suppose some might reply that you're forced to use these new tools/frameworks, because of dependencies on other tools/frameworks that you actually care about. But if that's really the case, and if this frustration is widespread enough, wouldn't people/companies have invested time and effort into supporting the classic-but-equally-good tooling?

As someone watching from the outside, I can't imagine a world where an entire industry is running in circles, creating churn devoid of positive value. Maybe I'm too optimistic, but I suspect that many of the complainers are suffering from rose-colored glasses. As a heavy web-user, I've noticed that the functionality and aesthetics of websites have improved dramatically in the past 1-2 decades. The websites I see from the 90s and early 2000s, look like a joke today. I suspect that this improvement is only made possible by the new tooling and frameworks that exist today. That they are indeed more complex, but they still unlock new potential that would be too hard to achieve otherwise. That anyone who tries to use ancient tooling from 10-20 years ago, would find themselves unable to provide an equally good mass-market UX. If this is not the case, I invite someone to prove me wrong.

This generation is only just starting to learn important lessons that the wider programming community learned decades ago about maintainability, portability, the pros and cons of standardisation and of rapid prototyping/evolutionary development, how to design systems of non-trivial scale that can remain useful for extended periods, how to balance the overheads of introducing external dependencies with the benefits of using ready-made, tried-and-tested code and tools, and many other similar issues.

Consequently, that new generation is also only just learning how limited and unfit for modern purposes a lot of the foundations of front-end web development really are. As a direct result, we're now seeing a vast wave of tools, plug-ins, libraries and frameworks designed to paper over the cracks that should never have been there. And because there is little co-ordination or standardisation in the industry, there is also unfortunately a huge amount of wasted work, both for developers of those tools and libraries who are doing the same things repeatedly for no great benefit, and for the potential users who have permanent analysis paralysis.

That much will improve as the industry matures and consolidates, though I fear we are now stuck with HTML/CSS/JS as our foundation, at least until the successor to the Web comes along with things like interactive sites and security-by-default as primary design goals.

I think me and my team have spent 90% of our time working with tooling, and all creativity and joy has gone out the window - because you never become a master, an expert og know your way around the codebase before you're suddenly 2 years behind.

It's a shitshow and no one really seems to know what the hell they are doing - even the teachers of this stuff - they just know "how" rarely why.

Way, way too much complexity and abstraction for simple tasks. Some things "should have" become easier with quick scaffolding, auth templates or whatever, but they always only work 95% and you use an endless amount of time fixing the last 5% instead of building creatively.

Vite was the same thing, faster yes, but my VSCODE broke because of the myriad of build tools and plugins on top of each other from older projects.

The worst issue for me is how unfocused the efforts are. I experienced issues at a large media company where new features to the public site to improve user experience where delayed for entire sprints because someone in the team became obsessed with the notion that their env was wrong because they were using grunt instead of gulp, or they used a particular Sass processor that relied on Ruby and they could use one that was pure JS.

I quite like writing JS and have done on and off for over 17 years, I just don't understand the constant and wilful reinvention and fragmentation in front end development.

But what I feel quite frustrated about, is the pace at which tools become obsolete. It seems that you can be happy if you have two projects which actually use the same set of tools. And every time you want to fix a bug in some project which you didn't touch for a few months, you run into some kind of trouble while updating the dependencies.

Just today, I spent an hour getting a project to build again, which I built two years ago. I just hope that in the near future the community will settle on a common set of tools which will become stable and stay for a decade or so.