My satisfaction as a software dev has increased massively since I've renewed my focus on the backend, and also spent some time with Java and other mature languages.

We still get things badly wrong but at least it's wrong in a way I can understand. I've looked at some new frontend projects and I would have to learn 7 or 8 different abstractions, inside a monorepo, just to understand how to build a simple interface to a collection of APIs.

Fuck that. The churn is too high and you might wonder how people built GUIs at all when you look at a modern web-app codebase.

You write as if we didn't understand the technical value of those things before a couple of years ago when the current crop of JS frameworks arrived, and as if using one of those frameworks is somehow necessary to achieve them.

In reality, everything you mentioned has been widespread in other software development fields for decades. It's stuff the junior guy on the team learns in his first few months.

Moreover, I think there is a reasonable argument that of your chosen examples, testing is the only one that has sufficiently common requirements for building large but general tools to be worthwhile. The other design principles are valuable, but how best to use them will be highly project-specific, and therefore any widely useful framework will tend to be over-engineered and over-generalised for most applications. See also the Java nightmare I mentioned previously, the trend toward lightweight frameworks on the server side, etc.

Edited to add:

The myth that front-end developers are not "necessarily from a programming background" is poisonous thinking and it unfortunately usually comes from older programmers or non-front-end developers; the very people who could help guide the front-end world into maturity.

There is a difficulty in the industry that significant numbers of people are coming into this kind of front-end development from some sort of HTML/CSS and/or design background. They used to use a bit of JS here and there that they copied off a demo site to get their buttons to animate, and now they're being asked to move into more of a mainstream programming role, but neither they nor the people asking them necessarily appreciate what that involves.

That's not anyone's fault. It will be fixed over time as the industry matures, both because knowledge will spread and because more specialised roles than "front end developer" will probably evolve. But right now, today, it is the situation in large parts of the industry.

Facebook did something super valuable, that is ReactJS, and this is becoming the _de facto standard_. ReactJS is simple, opinionated, and supported by a large corporation. Thanks to ReactJS a new ecosystem was born, and now finally you have many projects gravitating around it, and this is good. It's just a matter of time IMO.

I strongly disagree with _"the browser is a bad app platform and javascript is a bad language"_. JavaScript has its quirks, but it's also really plesant to work with if you don't do weird shit like `isNaN('wft' - 1) // it's true`. The browser is a great virtual machine that is democratizing the web. If you are doing things right, you can have graceful degradation (it degrade gracefully to a lower level of user in experience in older browsers) to increase the audience of your web app, from the dev in SF with gigabit internet to someone living in a rural area in a not so tech advanced country. This of course has a cost, that is spending time developing your app.

That has been said. To answer your question, I think if user experience is not high on priority and there isn't much point re-use a lot of UI code, the company is fine with back-end framework and many do. I do believe front-end framework provide many benefits, code re-usability, loose coupling from back-end code, easy for team collaboration, such and such. Company should only switch to them for reasons not the fuzz it generates.

With the web platform everything is sat on top of shifting sand ... i.e. changing browsers, standards and devices. Almost nothing in the tech world has changed so fast over the last 15 years than the software and devices web platform code is expected to run on. I'd say that given that churn, the quality of modern web languages and tooling is remarkable.

Writing backends vs frontends is a totally different thing. Backends tend to run in stable environments, and mainly you concern yourself with data in and data out. That's not to say its easy, there can certainly be be plenty of "essential complexity", and infrastructure and scaling is a whole additional set of concerns. Frontend by contrast is a much more fuzzy issue, clients need to run across many unstable environments and require skills very far from traditional programming - sensitivity to design, UX and animation for example. If you're good at backend, it doesn't mean you're going to enjoy frontend too. And if you don't enjoy frontend it doesn't mean all the frontend tech is "bad".

Well, we don't have to do things this way just because everybody else does... developing "vanilla" Javascript is actually a pleasure especially with tools like Chrome's debugger. In my experience, front-end "frameworks" like Angular and React provide very little value and tons of unnecessary overhead.

Or at least, they're not worth the hype they're given. The wheel is constantly turning, and the hot new framework of today is just a re-hash of something already done years ago with a pretty facade.

You probably learned the actual fundamentals of the web, which is exactly what a good developer should do. Nowadays "frontend devs" don't know how to make the most basic functionality without React, Bootstrap, and 99 other pieces of bloat.

Frankly the stuff I look at just disgusts me on a fundamental level. Like as soon as you decide to use React, you've just mandated up to several megabytes of JavaScript simply to render your HTML. That's abhorrent.

I think learning new "frameworks and methodologies" only makes you a better developer to the degree that they are well thought-out. It seems like a lot of JavaScript stuff is basically still in a state of flux, where people are experimenting and figuring things out.

I spent a lot of time learning Python, C++, C, R, bash, OCaml, and HTML/CSS/JavaScript. All those things have lasting value, and I expect to be using them in 5 years, and probably most of them in 20 years.

I would say jQuery has lasting value, since it has an elegant data-driven / document-driven model. I look a new things to understand if they have lasting value. React does seem principled to me, and I was interested in playing with it, although these threads have what dampened the enthusiasm.

I am using HTML/CSS/JS to display statistics and visualizations, and it works perfectly for that. In any case, I do think there is a problem where a lot of front end devs don't actually understand the abstractions the browser presents. It's basically the same problem as Python or Ruby programmers not understanding what syscalls are and writing horrifically slow code.

As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team. People who do this stuff every day can easily follow the standard, understand the flow and be very productive. They did invest lots of time to learn about all those tools and libraries and probably had an overall productivity gain compared to writing native JS.

If you don't really enjoy front-end development, and your comment reads like you don't, get on your high horse and join me for a ride while the "web-boys" make our hacked UIs usable for end-users and maintainable for the next "web-boys" who have to hack on it. When we get back we'll probably be very grateful for a great UI(X). ;)

Front-end libraries and frameworks should be trivial because front-end web development is largely trivial, it's the ecosystem around it that has bloated in complexity, including Vue.js and React.

Take a standard API that is already simple enough to understand and use (DOM), and re-package it for people who wish to call themselves "software engineers" to justify the time they spend on making simple things work in a complicated fashion. If you disagree that front-end complexity is getting way out of hand, just read the source code of any modern single-page app including its dependencies.

I think that code written by amateurs cobbling together vanilla JS is generally faster in development and performance, more easily understood, and easier to maintain than code written by a professional web developer using whatever framework. The early web itself was largely cobbled together by hobbyists, and so should it continue to be.

The industry disagrees with me, that's fine. I'm aware there are many reasons why my views are the exception not the norm. I just hope that something far better supercedes this era of web development, which would require social and cultural shifts to occur.

Additionally, this 'fatigue' with front-end is getting a bit over told, I suspect it might be more alienation from developers who hacked jquery scripts together and feel they need to transition to app frameworks (I see so many simple websites and landing pages as react etc now).. where as those sites should just transition to vanilla js + dom..

The thing about inspired frameworks and 'churn' isn't a javascript/front-end thing, it happens everywhere, constantly... how many IOC, DI, ORM frameworks did Java and .NET have..

The tide is slowly turning though with Next, SvelteKit, Remix, etc. But still these frameworks are basically just rendering HTML and going full on fat client which is overkill for 80% of interactivity in web app but adds a lot of unnecessary complexity.

Your comment about 1990 seriously rubs me the wrong way because it seems to imply React et al. actually does something to address the points you make. It does not, at all. You still need to test your code on every viewport you support. And now you have to deal with an insane build process that rivals some C++ projects while doing it.

And there is absolutely an objective argument that staying close to the web platform is preferable than 200 layers of leaky abstraction and a 10MB uncompressed bundle of transpiled JS. The language itself is pretty okay in 2020, certainly not worse than anything else from the TIOBE top 10. I would definitely say writing a bunch of plain JavaScript is all that’s needed for most applications out there. If you can’t manage that without a frontend framework, the problem is certainly not with the platform or language.

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.

* [1] https://primalskill.blog/a-brief-history-of-javascript-frame...

I'm not here to piss on JS frameworks, it's good that devs push the limits of what's possible, I guess. But there's something to say for simplicity and stuff that's so matured that you can really rely on it. Making sound decisions for your product, your stack and your architecture is a skill.

Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore.

anecdotally I got out of JS / frontend mid last year after many many years in it and felt at the time that I was burnt out and had lost my passion for development. Maybe it was just too long for me in one area.

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.

And frameworks do expire quickly. Therefore it's hard to be determined to devote time to learn any of them seriously. And plain old DOM manipulation and CSS clearly cannot beat the development speed of modern frameworks.