Getting tired of complexity in web development

I call this the "path to enlightenment." You have discovered that the most popular toolchain is overkill for 95% of the things its used for.

The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you try mobile app development, let me know, I've never tried but I doubt it's exempt.

Why does this happen? No idea, but it's not lost on me that a lot of these things are backed by huge companies with giant piles of money who are using them as marketing.

The only thing you can do (besides leave it all behind and open a taqueria) is be a voice for simplicity. What are we going to build? What tools make sense for it?

The problem I'm running into is a lot of people expect to use React in the same way many of us once relied on jquery. So if that's the case and we must use some React, what can I do to use it in the simplest and clearest way possible?

I feel your pain. My career happiness peaked around 2014 or 2015, when I was writing Rails monoliths. I felt like I could focus 100% of my energy on business logic since the framework was so opinionated and the stack was simple. Things went rapidly downhill after that, once microservices, SPAs, node.js, NoSQL, and serverless computing started becoming popular. Everything just felt like a step backward. Microservices made simple things (like transactions) impossible. Express felt like a degraded version of Sinatra. NoSQL, frankly, is utterly pointless, and I have no clue why it ever caught on. Serverless computing is interesting in some respects but the places that I've worked that have gone all in on AWS were total disasters. SPAs are definitely useful for rich, interactive front-ends, but the trend to make everything a SPA and render everything in JS is totally nuts.

I ended up switching to a PM role, where I can focus on the business problems without having to worry too much about the implementation. I do miss coding a bit, but it's not fun enough to do full time anymore.

>I’ve hit a point where it just doesn’t seem like the end justifies the means in the vast majority of cases anymore

I agree, but the only path forward is to change the specifications for HTML/CSS/JavaScript.

As an industry we need to accept that these technologies get used to build web pages as well as software and adjust. This will remove a ton of the tooling. I think there are 3 basic things we could do to solve this:

1. Add dynamic interpolation to the HTML spec. This stops every framework from having to invent it's own version of it. 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier. 3. Update the HTML spec to allow for semantically describing user interface elements of software applications.

But it's going to be a hard sell. I am slowly writing a blog post about this, but I'm not sure I will be able to get anybody to listen. I feel like now, when we're in a browser monoculture where the browser vendor is actually competent is the perfect time to push this stuff through.

BTW: You can put your email in at daniel.do to get emailed when I release my post.

Using React with an API back-end is only 1 of many choices.

There's tools like Hotwire[0] and htmx[1] (both are back-end agnostic) that will let you create good old boring web apps with any back-end language where you don't need to write a ton of JS. You can sprinkle in front-end quality of life enhancements as needed to make nice feeling web apps with reasonably minimal complexity.

[0]: https://hotwired.dev/

[1]: https://htmx.org/

I bumped into an old friend recently and he and his wife work at a real estate company. They were raving about this new system they are a couple of years into the development of and how it's built on this great "Kubernetes" system.. they asked what I develop my products with and I almost felt embarrassed to say PHP and a couple of servers in two locations for redundancy that run Archlinux with a LAMP (LNMP? I guess with NGINX/MariaDB these days) stack .. same thing I've used for 20 years now (I was one of the first AL volunteers). When I asked what language their system is developed in they said Kubernetes, of course.

Anyway, it kind of reminds me of the days when everyone was developing a PHP Framework .. I've never used one and if I was to apply for a PHP job I'd be unlikely to succeed as I'm very specialised in getting shit done.

no such thing as frontend development. only full stack. and react for all the trillions of words written about it, what can you actually do with it? not much.

also it's over-saturated as hell. you think there's high demand, you're right, now try applying for a position and see how it goes.

there are two types of roles in modern web dev:

1 .90% of jobs are code monkey work: extremely saturated, you are competing with global workforce who will work for half your salary or less. i will get downvoted, probably cos there so many bootcampers and others who don't like to hear this reality.

2. 10% of jobs at top tier tech companies that pay the top salaries. good luck with the 10 stage interviews, aptitude exam, leetcoding and then getting ghosted.

the complexity itself just comes from the amount of steps required to do something trivial:

2010 edit an html button:

1. pull the file from ftp or sourcesafe/svn

2. edit the button

3. upload to ftp

2020 edit an html button:

1. install git

2. install npm, node

3. clone and install the code

4. deal with myriad node js errors

5. deal with myriad deprecation warnings and other issues in npm

6. start local environment

6.1 local requires docker

6.2 install docker

6.3 try to start docker

7. docker requires sudo

8. request sudo from IT

9. fill a form explaining why you need sudo

10. install docker

11. start the local environment

12. edit the html button

13. local server not refreshing

14. fix local tooling issues

15. commit changes

16. your changes are 10 commits behind the branch

17. try to merge automatically, cannot be merged

18. make a PR

19. smug know it all "senior" developer with 2 years experiences, gives a bunch of nitpicky comments on the PR and refuses to merge it

20. go back to step 6

A couple people have asked what complexities I’m referring to and mainly what I mean is just how much bloat goes into making anything, and at a higher level the general course of action seems to be to just keep adding to the system until you get what you want out of it instead of trying to fix or improve underlying problems with the web.

I know we can’t just pause the internet while everyone comes to a consensus on how we want to make it more interactive and fix underlying problems, but at least to me it seems like all the effort that could be spent working towards that is instead being spent figuring out ways to just avoid as much of the underlying pieces as possible by jamming your own implementation on top of it.

I agree that getting setup and using things like React or Node for a backend is easy, but the number of dependencies, size of the app, tooling needed, memory used are all going to grow exponentially as soon as you start trying to do something non trivial, and the solution to fix these problems is yet again to add more complexity, where you will need to learn a lot more about how all of those nice tools that just worked for you out of the box are actually working

This isn’t a React or a frontend specific example entirely, but I’ve seen many people jump into creating a simple app and right off the bat implementing a federated GraphQL design because of all the great things they heard about GraphQL from the community, which is fine but a very simple REST design would have worked just as well if not better and would be in my opinion much simpler to maintain and manage complex things like caching.

It sure looks like we’re nearing the “peak Java Enterprise Edition” moment for frontend web development space.

We got here honestly: Single Page Apps made “fat” clients possible in the browser, but that meant a lot of logic had to move to the front end, so they naturally became bigger and more complex. Meanwhile, we still want to have the “lazy installation” experience of browsing to a web page and having things load quickly, and this adds all sorts of complexity like bundle splitting, hydration, “edge” hosting, etc.

I’m not sure where we go from here, complexity-wise, but here are some guesses:

* no/low code will produce a new “ruby on rails” for the modern SPA space. (There are already contenders.) * increased environment complexity will move development into the cloud and off of our local machines. * there won’t be a sudden disappearance of the older approaches, just like SPAs didn’t kill RoR.

I've been doing front-end development off and on for 25 years and I still had a moment like this just this week.

A different team updated a library we're supposed to use and all of a sudden, the deployed service was crashing on startup (worked locally). It appeared as though the problem was some EMCA6 syntax wasn't playing well with Babel configuration that seemed fine to me.

I got so frustrated that I ended up removing Babel (because it wasn't needed to begin with), which meant I had to change all the import statements to 'require' and had to change all the export syntax to CommonJS. Finally got it working after many hours and refactoring...

Except then I realized that the base docker image in the dockerfile was node 12 and not 16. If I had just updated the dockerfile, I wouldn't have had to remove Babel and would have saved myself a day.

Modern front-end development is sort of like child birth. Your brain conveniently forgets what it felt like to push a watermelon through a straw.

PHP.

Use PHP, it’s so crazy easy for web development.

- No compiling,

- no middleware,

- no state (which also means no memory leaks),

- just drop a file on web server and it works (no crazy CI pipeline),

- the documentation is fantastic,

- it’s extremely fast, and

- no surprises because it’s tried and true.

PHP is so under appreciated.

Yeah web development went from being a passion to just being a job where I now feel like I just play the complexity game with teammates, managers, and stakeholders.

I don't care about this stuff anymore. I only care about the paycheck.

Yeah, the technology is cool... we do Docker containers... so its a 'microservices' web app with a remote registry for our containers plus a bunch of disgusting npm packages and weird frontend react client bloat.

I prefer my side-projects. They are succinct and concise. No bloat. Just DIY simplicity.

I don't know if this helps or hurts but I took up Elixir a few years ago and was liking it, the way the FP simplifies the scope you have to operate within and the general stability of the API that Jose has stated, i.e. it's feature complete for the foreseeable future, changes now are mostly optimizations such as pushing more into the erlang layer.

Then they introduced releases which can package everything into a tar file that has all the CSS, JS, HTML, erlang VM, etc. in it and runs as a binary via systemd and proxied through your .

Then they introduced LiveView and it was the first time I really had a "wow" moment since first learning Rails many many years ago. I can do nearly everything I want in real-time with it + JS hooks.

I really do think this addresses a lot of the frustration I keep experiencing w/r/t complexity in web development. I can just write Elixir code and get about 90% of the features of a JS framework like React.

The only real knock on it is it's strongly typed not static typed (they're working on a solution) but with code analysis tools like dialyzer and credo a lot of that worry is addressed. It's not for everyone but FWIW it has been a breath of fresh air to me a 10+ year web developer.

I just use Go for a self contained back end and server. For the front end I use the html templates, but for the most part it is traditional html, css, and js. No compiling js.

That said, I primarily work in other areas. This is just for when I need a web app.

My academic background is Electronic Engineering and embedded development but found myself in fullstack and then frontend development roles for over 7 years. I began to experience what you described, essentially a bunch of hype technologies bandwagoned by junior devs and HR recruiters spouting buzzwords and insane abstractions, npm dependency hell and glue code coming out of my ears. The whole ecosystem is crazy.

The worst part about it is the technical debt that companies encounter. Technology should be serving business objectives, first and foremost. If your tech-stack is outdated in 2 years time, something is really wrong.

I’ve gone back to EE, hardware engineering and embedded development. I think this specialization probably reduces job availability, but I can always fall back to webdev in tougher times if I have to, and its something to set me apart from all the 8 week bootcamp coders flooding into the webdev market

As someone who works in full stack development, what complexities are you talking about exactly? I just spin up a NextJS app with an express server if I need a backend as well. In a way, it's been easier than before where you'd have to set up Webpack and friends. I just write React code and it automatically shows up on the page.

You can do more complex stuff, sure, but it's not necessarily required. So it depends on what you're doing, which if you can answer I can help give an answer to.

I was thinking the same thing recently. I’ve finally realized that React is painful and overly complex. I just followed the crowd and got too deep. Backbone was elegant and simple. I could step through all the code being executed with my debugger. React is impossible to step through and the error messages are still terrible. It’s like an entirely new programming language and runtime. This “it’s just javascript” bullshit is so far from the reality now.

There is sooooo much you have to think about when writing a good React component with hooks and to ensure it remains performant and is bug free.

I really want to go back to basics. Using as little framework as possible.

I’d much rather something simple that I have full control over and that I can trace the entire execution with a debugger than all this magic crap.

I don’t even like JSX. I always pass an object in like: ‘’. Would much rather just use a literal js object.

I feel like React is a lot like dependency injection frameworks. The initialization code you would have to write without using one is actually very simple and straightforward.

Is it really that difficult to manually render components as needed? Do we actually need this huge runtime vdom overhead? Or any of these other compilers/transpilers.

I had an epiphany two years ago when GDPR came into effect. USA Today had this fancy page, but to comply with the new law they created an eu.* subdomain where they basically just showed articles. Text and images and very basic css, not even a fancy navigation. It was blazingly fast, just doing normal complete reloads between pages. I bet it was even cheap to make. So I realized, actually most of these things like SPAs are not truly needed, not even AMP was needed, they are just a bandaid on the complexity we add ourselves, and the kicker is, the users for the most part don't care about any of that. They just want to consume your content.

If your heart is still in it, I'd try to learn a skill that will be relevant forever. Something that would be a part of a university curriculum, not a framework. As others have pointed out, other areas of the industry are not necessarily better. An anegdote from a colleague there: he was maintaining a simple PHP backend where people bought stuff the company was selling. Another team built a replacement for this, real engineers, microservices, elasticsearch, containers, kubernetes, took forever. They switched it on and a week later noticed they are having less sales. They switched back to their legacy backend and everything was fine again.

edit: also I interviewed a bit last year and it was mostly that you'd think people are making space shuttles. You get asked all these technical questions, about JS and so, and then when I asked about, hey what do you actually do as a developer, what are your daily tasks. And the answers are, well we had to recently make our gallery page responsive. Sad.

I’ve bounced around between frontend and backend and devops, plus some iOS and one Android project. I’ve hopped in and out of various languages/frameworks. For the past year or so I’ve been using elixir which is my first big functional language job, as an example.

I would not worry about job opportunities. Here’s why:

General problem-solving abilities (eg. breaking down work into smaller chunks of work until you have something actionable) translate well to all kinds of software.

Skills like being able to communicate well with other engineers, product folks, etc is also similar.

Also, tech moves fast. Even if I were to have stuck with only frontend work, that landscape has changed so much in 14 years it’s not like the way I built things in 2008 is the same as 2022. Which is to say that regardless of staying in one area or moving around, I’ve always had to keep learning new things. I think other areas are like this too, eg Apple coming out with new ways of doing things every few years; Android SDKs having major changes over time.

Maybe I’m just feeling preachy at the moment but follow what excites you :)

I transitioned from product work to platform/dev productivity work (think frameworks, internal tools) surrounding the web stack, which is a form of extreme specialization. It effectively means I'm not directly dealing w/ useEffect stale closure sort of crap, but instead I work w/ things like supply chain management, CI flakiness and build optimization, which involves developing a skillset that doesn't really fit into the "jack of all trades, master or one" narrative; it's more like developing depth in a wide array of obscure things plus a large dose navigating "working groups" to complement a workforce composed largely of React experts.

Career growth is currently primarily coming from increased internal impact at a large company. In terms of future career growth, most of the recruiter spam I get for Senior/Staff/Principal roles is below my current pay grade, so I expect that further growth will require shifting more and more into director track.

There are a few things I think you could do about it:

1. Find somewhere to work were they use a tech stack you feel is more appropriate.

2. Work at a smaller company where you have more say in the tech stack and tooling.

3. Find a company or team where someone else works on developer tooling and automation, so you only need to worry about site building.

4. Freelance and specialise in what you enjoy working with.

I work at a small (15 people) web agency where I have a large say in what we use. It's surprisingly little React/Vue, a bit of WordPress (not everyones favourite maybe) and a lot of backend work on APIs and admins in Laravel and plain PHP/HTML with some vanilla JS. Only about 10 percent of the clients ever care what stack we use.

All of our 60+ projects are setup the same way:

1. Pull down the repo and run "docker compose up" to start you local environment. Any composer or npm commands should be run through docker compose, so no local installs (except docker) are needed.

2. Push to staging branch to deploy to staging and merge to production branch to deploy to production.

Not that there might a a huge market for it, but I'm going to attempt provide "least complicated solution" service to potential clients. While results might not look very fancy or have many animations, client will get working website faster and cheaper, and their customers will actually get superior experience, as website loads fast and doesn't do annoying things. Wish me luck.

I haven't done proper web development in a very long time, but I recently did some work with a front-end contractor. I made some self-effacing comment about not knowing frameworks and all that, and he gave me an amused look and said that he doesn't bother with them. He showed me his code, and it was all quite easy to read and looked very maintainable. His output is great, and to my knowledge we've almost never had post-deploy issues.

In my career, I've witnessed a lot of "framework"-style vanity projects (several were my idea). Fewer than 100% of them have been boondoggles (but that's the most generous estimate I'll give).

Food for thought, you might be better off without.

I noped out of the whole web development thing. I know its where the world moved to, but I always felt it was a technological wrong turn. Java applets were great, sure they had issues, but they were solvable. But the tech giants had to ruin it so now we have JS frameworks of the week built on top of a system never meant for rich clients.

I stuck with desktop thick clients for embedded devices and scientific computing. Mostly C++ / Qt or Java / Swing / JavaFx as a tech stack. Couldn't be happier, the tech stack isn't changing under my feat constantly and I can quickly bang out features.

That's why I stick with Ruby/Rails (while having 20 years of experience with variety of other languages/frameworks like C, C#, Go, JavaScript/React):

* "Optimized for Programmer Happiness"

* The Principle of Least Surprise

The knowledge you gained 10 years ago is still applicable, language/framework is not going anywhere soon. I kinda love what I do.

Shameless plug - my Ruby book https://leanpub.com/rubyisforfun/

Frontend development jumped the shark for sure.

Why can’t we go back to the old server-side template rendering and use progressive JS for interactivity? Just like the good old days.

Then stop using these large frameworks. You don’t need them. They aren’t there to build your product for you. They are there to ease hiring.

When you return to vanilla JS you have the freedom to dramatically reduce your code size and increase performance.

See this comment upvoted 27 times: https://news.ycombinator.com/item?id=32914694

> Has anyone either switched from doing web development type work to something else they enjoy more for similar reasons?

Yes, I quit being a FE developer in 2019, after around 13 years. There were a few reasons, but one of them is just what you describe. Looking ahead to the rest of my career, I knew I wanted to make things and not be a manager, but I could not imagine myself living in the world that front end development had created for the next 20 years and also being happy.

In my case, I had been a hybrid developer / designer for most of my career (as a contractor, I juggled roles based on what the client needed). So, my mid-career change was that I just switched to not doing contracting, and only doing design.

It's not that I enjoy design more than programming, but I do think it's a more sustainable path. I never used to program in my spare time, but now I do it a lot because I miss the fun parts. I'm sure as hell not doing React on the weekends, though.

The design world has its own frustrations, but so far I think it was a great choice.

Don't tell anyone. They'll think you're the problem. Just smile and install the latest tooling.

I’m a journalist who learnt to make websites back in the day and never bothered with newer, fancier technologies. My background isn’t suited to take on big projects, but I still have lots of fun designing little projects, such as my personal page[1] and weblogs[2].

Bonus point: these websites are always super snappy and easy to navigate. I can’t understand big projects based on React and other technologies that, no matter what happens on development, result in slow, busy, and generic websites.

[1] https://rodrigo.ghed.in [2] https://notes.ghed.in

IMO, maybe some technologies do make sense for certain team sizes.

I haven't worked much with React, although every time I did, I felt like everything was overkill.

Then again, I've worked with k8s and while other people may think k8s is overkill, for a team our size – hundreds of devs working on separate microservices, I think it makes sense.

It doesn't make sense for a small startup, but once you get to a certain size, the pure human element forces you to look for alternatives. While complex, k8s is actually a great solution to a lot of the problems we were facing.

It's possible that React fits that same need, and while it may seem like overkill to me, maybe I don't know enough about it.

Web development is complex and has always been. 15 years ago you'd deal with complex hacks to work around the table based layout mess, the horrible browser APIs, javascript's prototype inheritance, Apache configuration and, god forbid, networks of .htaccess files.

10 years ago you'd deal with communicating stuff between language borders, what interaction to handle in javascript, what in ruby/php/perl/whatever and how to interact between the languages.

Now you deal with build processes, transpilers, bundle size optimization, framework configuration and broken react state updates.

It's intrinsically complex, deal with it.

I don't know how it happens, but you'll never escape it. Just give up and enjoy the suck. Do yourself a favor and start a side hustle project using plain javascript and python or something. But don't get too attached to it - if it gains traction and you get funding and hire a few developers, they'll rewrite your app in the latest trendy pile of abstractions. And the suck will be back. Just move on.

OK, so I am late to the party, but I have some thoughts.

One, if you search for the word complicated on HN, the top hit is the same complaint from 2019. This isn't getting better. https://news.ycombinator.com/item?id=20637849

Two, from the discussion in February, web development is literally the worst job in the USA for degree of change in complexity / lack of ability to build career capital over time. This is (and will in the future) driving talented people out of the profession. https://news.ycombinator.com/item?id=24910949 https://whoisnnamdi.com/never-enough-developers/

Three, I have a pet theory. Indulge me. We have noted before that there is a lot of overlap between software engineering contracting and, say, carpentry. Key difference: once a cabinet is done, it's done. There isn't any need for follow up, enhancements, new requirements, changes. However, if you make a software project so complicated that only you or someone with very similar experience can make changes to it, you drive up the likelihood of capturing the benefit of a future income stream. This is also the impetus behind very complicated frameworks: the more people adopt your complicated solution, the more likelihood they drive business towards you.

Lastly, this crowd isn't going to like this, but the solution in other engineering disciplines is standardisation and opinionated off the shelf solutions. It's that or wrestling with complexity forever.

> I have a few years of experience working mostly on the frontend with React and am getting more and more frustrated with all the added layers of complexity needed to work with most common frontend frameworks.

It's complicated because you (or your team) are using very, very low level tools, which were made for large teams, working at large companies with complex architectures adapted to fit more people working on the problem, with large budgets where all of this can be afforded. In fact, you might need to use those low level tools in most of those environments. I'm talking about React, GraphQL, SPA architecture, microservices built with microframeworks (some times in pretty low level languages for the Web such as Go, etc...)

Try Rails, Laravel or, if you want to stay in the JavaScript world: Adonis.js. Pick a modern "sprinkles" library for the parts you need interactivity such as htmx, unpolyor alpinejs (or Hotwire if using Rails). And boom... Everything is simple again. Just not trendy and fashion.

I worked in web development for about a year, then switched to general devtools and CI/CD, then to infrastructure orchestration work on deployment, Kubernetes, service proxies, deployment. After that I joined a startup and worked on backend, mobile apps (Android), and now I’m back to working on complicated frontend.

I think the fundamental reason this is true is because devs over engineer on purpose to make a meal out of simple things. Pretending that your thing will need all the bells and whistles means you can claim you did all sorts of glorious things on your resume and take yourself all that much more seriously.

I can't believe no one is mentioning Django.

Still in use, still killing it.

I had a great experience with Hotwired Turbo and Stimulus.

I completely agree with you. While I don't have a solution, I have a related question on next.js. (Shortlisted next.js since I liked the overall design). Can someone help? Posting here since its related.

Background: Primarily a backend developer. I had used java swing and struts long ago. Played around with vanilla react and next.js (through vercel). I had a look at the various samples provided by vercel. But I struggle with the syntax and hence finding it very difficult to write something from scratch. How do you guys write a new application in next.js?. Do you hand code it?. Also, is CSM a must ? Most of the examples in vercel are simple applications. How does one design a slightly advanced user interface from scratch?

This is why new frameworks are created. Someone gets upset over X, in this case complexity, and then creates something to fix the situation. That's why React came to be. The incompatibilities between frontends made it hard to produce a good product so eventually we get what we have.

The fix is to reevaluate and start over. That's way harder than continuing to use what's available so things continue as they have been.

I haven't used React for a while but it definitely made developing for different browsers much easier but it you wanted to do a simple app it was way harder to use it. It all comes down to what you are creating and reaching for the right tool.

It's simple, quit web development and slide into other niches. I found mine in blockchain and smart contract development. Now I find myself solving interesting problems rather than trying to make 1000 frameworks and libraries work.

Everything since static HTML has been a mistake.

I wrote a js lib similar to HTMX, which I call HTMF[1]. Unlike HTMX I try to stay as close to the metal of the current semantics as possible. So, all interactions are based off of forms. I also tried to keep the wording similar to HTML/JS semantics. It's pretty small lib but pretty amazing how far I can get with it. These days I mainly build offline-first apps with it. But I built it in such a way that it can easily be a progressive enhancement to an MPA app.

[1]: https://github.com/jon49/htmf

After jumping like a flea between frameworks for, what, 10 years (was an amateur dev), I came to the conclusion that I will use one well maintained framework for everything.

I settled on Quasar (based on Vue and recently also Vite).

If I need to have [a page with a button | anything really] I will use Quasar (and Typescript).

Yes, it is overkill. Yes, it is not lean. Yes, it is simpler to do it in 5 lines of vanilla JS.

But OTOH I always know what I will get, do not need to guess, know the time it will take me to write something.

And, notably, frees me from thinking what to use now. I have the hammer for anything that remotely looks like a nail, even if it is actually a screw.

I feel you. I feel this since 2014 actually. Same exact DX - Developer Experience.

Switched from web backend to unreal engine game programming dev. Havent started yet on the new gig but one of my main motivations to not do web stuff anymore was having to deal with people introducing unnecessary layers between you and what you want to do in code, all that time. It is just a thing because web companies can afford both the extra cost and extra performance hit that these "best practices" incurr (and cultural inertia, maybe), while in games, I believe, there isnt space for any of that, you must start simple to complex because of budgets. Not the other way around.

Like you I tend to agree that the effort delivering front end projects often seems to outweigh the value added over recent years. I can think of half a dozen projects I've seen over the last few years where the effort teams put into figuring out stacks of new tools was an order of magnitude greater than the value added (and most of the projects failed to deliver or became haunted forests soon afterwards which is even worse!) It's not sustainable, businesses are wasting far too much money and too many talented developers are left feeling inadequate.

The most important thing in any organisation is to ensure teams are setup to succeed - that means they're using tools which enable them to work efficiently, ship easily and reliably, and their work can be maintained in future.

With that in mind, my advice would be:

1. Ensure there is a process where new tools are scrutinised by peers. I always push developers and teams to explain their tech choices in terms of the value added and often as we dig into this together the justifications melt away. Asking for a timeboxed proof of concept can also be effective - battling toolchain woes and trying to manipulate tools into solving the problems a team actually has often helps lead to better decision making (think https://boringtechnology.club/)

2. Try to work in organisations where developers can be close to their users and are empowered to suggest new features and self serve analytics data. Teams able to build empathy with their users and are motivated to solve problems for those users are more likely to favour choices which provide value quickly - this is a big nudge towards making simpler choices.

3. Give developers space for learning and experimenting. Whilst tempting, picking up a suite of new tools to deliver each new project is a really crap way to encourage self development because those new tools will more often be a big distraction than a force multiplier. Many developers are highly motivated by trying out new tools and frameworks, and some of those might lead to something great in future, so give developers the time and space to try them and make sure their learnings are shared with the team to help level them up too.

Having complexity without understanding the “why” behind the complexity is a major issue. My best advice is to balance pragmatism with simplicity and always prioritize personal learning and understanding. If you use React, ask yourself why. You will eventually learn a lot of microtopics the more you do this. I like working in infra because microtopics are treated as first class. There is no shortage of articles about database consistency models for example. Learn the microtopics and you future proof yourself from mindless tech decisions

Could you give some examples of the complexities you're tired of?

React tooling is only getting easier, esp. considering anyone coming from the age of Webpack. The recent wave of framework innovation has been about DX by bundling things together into one cohesive experience. Also, nobody is required to keep up with the bleeding edge unless you're a framework author trying to breakout. If you don't like the marginal benefits provided by some performance story in React, then don't do it.

There are also more easier-than-Heroku competitors than ever.

The weird thing is, having been in frontend dev since around 2013 I feel like it's the simplest it's ever been.

I'm more productive than ever, but I suppose mileage varies.

I experience the same. I mostly stopped with web development because of this, and get a lot more satisfaction out of static pages, because it is so simple (and fast!).

There is a huge shortage of developers on corporate information security teams. Many organizations' CorpSec teams spend an egregious amount of time toiling in manual processes. In infosec, that is why you constantly hear of burnout.

If you wanted to switch into information security as a developer, many well-paying, well-known orgs would welcome you in with open arms in some kind of automation developer role. I have never felt better about my job prospects.

I focus on backend and native GUI development, when required to do Web GUI development vanilaJS + SSR are my tools for the last 20 years, I leave the deep knowledge of the FE framework of the day to the FE teams.

To this day I have been lucky to always been able to find something, maybe because I've always embraced a polyglot toolbox and not being int a silo as XYZ Developer.

Yes, I did exactly this and for the same reasons. I left web development in 2015 when the tooling was starting to get a bit silly. I had an opportunity to move into devops and system administration at the same company and team so I took it. I'm still finding it enjoyable and I do like how much more powerful the point of simplicity is in this field.

>Has anyone either switched from doing web development type work to something else they enjoy more for similar reasons?

I became a manager of engineers, so now these all are not my problem anymore. I'll do my tinkering in Factorio and Entropy TD, and I build as big of a spaghetti as I'd like.

Amen. I would even say the same thing about UI/UX design, with tight coupling with react components with naming conventions and tokens. Overly complex design systems.

It all sounds great in theory, but it comes with so many baggage, and only tends to work in certain SV type companies.

It happens on the backend too. For the infrastructure too. Honestly, maybe unpopular opinion but it's why I went into management. I was just tired of gluing together dozens of libraries to parse/format data around and deal with this crap.

This entire thread would look exactly the same if the main topic was cybersecurity. :)

Server side rendering ftw

Use a component based framework like Primefaces and you’ll realize you can push code way about 10x faster than a js stack.

Web-development is still better than Mobile Development, just use NextJS and make your websites/webapps.

Everything is complex and many analysis looks like CSI investigations.

been there, just move to Svelte XD simplicity is king

don't use tools just because it's popular but make your productivity plummet..

I was active in web application development three times (1999, 2007 and circa 2010). Every time, I was horrified by the number of patches, workarounds and conditional code that were needed when doing "pure" web development. But at the same time, every application I developed was a little easier than the previous one, for four reasons.

First, the evolution of the web was pushing away the technologies that were the heaviest, most marginal and least standardized. I'm talking about ActiveX, Applets, Netscape frames, etc. The gradual elimination of these technologies was made possible by evolution of HTML and CSS towards more functionalities.

The second reason was the gradual standardization of key elements in web application rendering and execution. JavaScript behavior and functions, DOM structure and events, CSS element size calculation, etc. This standardization made it much easier to write code that "mostly" works cross browser.

Third, the modern web development frameworks and libraries. These contain the convoluted conditional code that you really don't want to write every time you want to implement something. Plus, once you've written your code, you don't have to completely revisit it every time a new browser version is released. I once wrote a nice website with drop-down menus which worked fine on Firefox and IE6 and IE7. Yay. But then, it was broken in the new version of IE. And then, Flash contents became "first layer" and opaque, and so the menus were rendered behind the contents. The amount of work I had to spend every six months to keep it running was not worth it. If I had used a popular framework maintained by the community (which were a little less common back then), it would have been less frustrating.

Fourth, mobile-friendly websites. The success of tablets and smartphones in the 2010s pushed web developers to have a simplified, more streamlined version of their websites available. Eventually, this had a major influence on the "PC" version of the same websites. Today, most websites have lots of functionality and interactions, but they're also simpler, the pages are shorter, there's less screen size conditional rendering, less overwhelming animations and extremely convoluted layouts.

All that to say... Web development is not as crazy and frustrating as it was just 10 years ago. One of the problems I'm seeing is that many designers still think in terms of fixed screen size, and full screen animations, and try to cram everything on the same page. These are really bad design patterns. Sure you want to dazzle you client with your HTML5 powess and ability to design gorgeous contents. But in the end, visitors and customers will be put off by imperfectly supported features, long load time, resource heavy rendering, clunky in-page scrolling, non-touchscreen-friendly buttons, and poor ergonomics in general.

Most sites that are a nightmare for the developer are also a nightmare for the users. In some cases, just reminding the designers they a load time should be under 2 seconds on a 4G connection might be sufficient to calm down their hubris.

It's business-generated complexity, not complexity out of necessity. And I don't mean business made the complexity directly, but it's an indirect effect of trying to commodify developer jobs.

If you have a job posting describing "work on our website" you get all sorts of random candidates that have no real place in your company, but when you say "developer with framework XYZ experience" you can skip everything, judge their framework experience and move on (or so it is thought to work).

This means that to be attractive you need to use it as a developer, but inside a company this stuff has to be used to make sure that the current developer(s) can be replaced easily (not how it realistically works beyond CRUD apps), and expanding the workforce is easier because attracting developers with technology keywords is easier than business job descriptions.

End result: using technology not because it's the best fit, but because it is off-the-shelf. Essentially a modern version of using Oracle and Windows NT 3.51 back in the day, you're using it because it's an easy off-the-shelf keyword, not because it actually has anything to do with what you are technically trying to get done. Enterprise IT and HR shaking hands all over again.

Some more expansion on this topic (story time):

Generally when you are large enough as a team or business unit to have lots of collaboration, you need some way to exchange information and ideas, and work together using similar-ish principles. That can mean various things, from all using the same OS and IDE to having up-to-date API documentation and integration tests. This means that if you have to transport some idea, project or application across people (and teams) you need a method and format to do so.

This nearly automatically also means you can't do solo yolo all day and you need to have rules and packaging standards so you don't end up figuring out what Pete did on his machine so it works on Jack's machine but not Jane's. Chroot-in-a-tarball works, virtual machine images, maybe autotools with a bunch of setup scripts. But most of the older methods all have the same problem: your systems all need to be rather similar to work with it, and you need to have systems knowledge to make use of it.

With the expansion of the workforce, that becomes more and more scarce, to the point where most Junior and Medior engineers have no clue how their computer actually works, how to manage an operating system, how how to understand the influence of externalities (be it them influencing other teams, or the other way around). People with less experience are easier to 'create' (yes, I know, we're not actuallt manufacturing people on-demand for work), as it requires less affinity, less time, and less education resources. So we can get more of them, and as long as they are put in an environment where they don't need to be as capable as 'full fat' engineers, the business can keep running.

So, what do we do? We package and standardise. First with environments, we have virtual machines, images, packer, and can see those local virtual machines with ansible and saltstack and if it works there, the project will work on other workstations and servers just the same, since it was all provisioned the same. No more guessing. But this is a really heavy method of doing this, and the greybeards will complain that just using some file protocol to directly edit something or a simple jail or chroot was much lighter (faster, less resources etc). At the same time, from a security perspective, sandboxing stuff gets more traction, and with namespaces and control groups we also get docker (pre-OCI), which gets a bunch of people excited because you can now make transportable environments that are essentially jails, but without having to know anything about jails or bsd and it works on Linux!

Parallel to this, we get various tools for dependency management, mainly derived from the same concepts that drive dpkg/apt and rpm/yum, because it worked so well for system packages, why not use it for nearly every language under the sun? This gets into DLL-hell rather quickly, contaminates the operating system by installing packages needed for your projects globally for the entire system, so now whenever you switch to a different projects you basically have to reinstall. Boo! But luckily someone heard of this fancy new container thing and you can just do all of that stuff in there!

Now we can simply create those project environments as container images (got some real traction once OCI was a thing), so an engineer working on some new feature has even less of a requirement regarding their skillset. Just hire someone who can run docker containers and work on framework XYZ! Tons of those available. So instead of having teams with 5 highly skilled workers with deep knowledge and a high cost, you just get 3 Juniors for bulk work, 1 medior for checking their work and 1 senior that's in that classic "know as much as possible" bucket do mitigate any complex issues that may arise.

Fast forward to today, the new greybeards are the senior engineers of a decade ago, less and less new people with deep knowledge have been added to the workforce, but large masses of either highly specialised or shallowly trained people are being hired. They are not unskilled, but just skilled for a specific piece of the business, because that works for other departments so why not IT? And there is a shortage after all...

The now rare and in high-demand deep knowledge engineers are tired of getting the same questions for the same architectural problems and same business complexities, so they come up with software frameworks that they can apply to the problem. It doesn't matter if the other team members have a varying gradient of understanding of the details of the solution, as long as the tickets get closed and added value is perceived by non-technical people. Those same people may see those framework names, and recognise them in various important places around the business. Hiring more people now focuses on making sure that they will be able to work with this stuff, because it's what the business is already using after all. And to be attractive, new engineers are trained to use those frameworks.. and now the cycle just repeats itself.

Moral of the story: it's a mix of race to the bottom, commodification, shortage and standardisation. That last one is important, because using standards is preferred in a risk-averse environment, and most businesses are just that.

Can I ask what exactly you're tired of in the frontend world?

Is it constantly having to relearn new ways of doing the same thing, without any tangible benefit? If so, yeah, that really sucks, but I guess that's the unavoidable growing pains of a rapidly-expanding industry with different companies all inventing their own wheels. Have you ever thought about working in a slower-pace field (whether it's a different vertical, or a different part of tech, like firmware, hardware, enterprise backends, legacy business apps)?

Is it having a bunch of competing Javascript frameworks (Next/Nuxt/Gatsby/Netlify) and languages (Typescript, React, Vue, Svelte)? If so, it doesn't really matter, just choose one you like and stick with it and find jobs that use it. It doesn't matter how many more spring up, wait a few years and either the dust will settle or something new will come along anyway, but you can skip all the in-between ones. They are all "good enough" these days, there's no need to let the perfect be the enemy of the good.

Is it the buildchain/toolchain, like webpack and babel and parcel and all that crap? If so, maybe use a bolts-included framework like Next.js that takes care of all of that for you with sane defaults -- that one framework can replace a lot of what Redux, React Router, Axios, Create React App, etc. do, and it preconfigures the common things (Typescript and ESlint) for you so you don't have to tinker with that.

Is it having to clobber together a hundred third-party NPM packages to make a functioning site? If so, well, you can either go bolts-included (something like MUI which takes care of a lot of the mundane UI), or go the opposite direction and make everything yourself. You don't HAVE to buy in to the greater JS ecosystem if you don't want to... most of us are just lazy.

FWIW, just as an anecdote, I moved from fullstack to frontend JS and have never been happier with the simplicity. Yes, the JS ecosystem is absolutely a mess, but at least it's ONE ecosystem with messy components, rather than ten smaller ecosystems trying to coexist. Back in the LEMP days (which wasn't really that long ago...), to be a web dev, you had to know some subset of HTML, XHTML, XML, JSON, SQL, Apache, Nginx, Varnish, SQL, Postgres, MySQL, Maria, Perl, PHP, xdebug, Laravel, Symfony, Ruby, redis, memcached, DNS, HTTP, HTTPS, ssh, VPNs, Linux, systemctl, monit, TCP/IP, iptables, Docker, Drupal, Wordpress, Liquid, jQuery, each browser-specific JS (no ES6 yet), CSS browser prefixes, CDNs, cache expirations, S3, EC2, EBS... it was ALWAYS a mess. But these days so much of it is abstracted away behind frameworks and Jamstack hosts. The frameworks are complicated, yes, but they are shielding you from even more complexity. In like 100-200 lines of Next.js code combined with a headless CMS (or someone else's backend), you can do what used to take ten different frameworks in four different languages. Then you can one-push deploy it to the web and it's automatically CDNed and HTTPsed everywhere... in like a minute. It used to take days & weeks to figure all that stuff out, and every part of it would constantly break under load or whenever someone forgot to update a certificate. These days we mostly take all that stuff for granted, and you can just write UI code and not worry about the rest of the stack so much. THAT should be the joy of modern frontend, to allow you to code for UX instead of against your tech stack.

Maybe, instead of hating the job overall, have you thought about what specific parts of it you actually DO like? If you like the design part, maybe move into UI design? If you like the UX part, become a UX person? If you like the actual frontend coding part but not the buildchains and third-party packages, find a company that already has their own devops and frameworks set up so you don't have to do all that? Or think about doing frontend work in a vendor-dominated space (meaning Apple/Microsoft/Google apps, not web apps) using a different presentation framework? If you like interactivity, maybe games dev? If you like solid engineering rather than quick and dirty UI code, maybe more enterprise backend stuff, or work for a SaaS/PaaS vendor instead of the frontend stuff -- i.e. you don't have to work on end-user facing frontends, but maybe dev-facing frontends like monitoring dashboards or the frameworks themselves or admin panels or whatever. Or are there some special frontend techs/use cases you really enjoyed working with outside the DOM, like Canvas or WebGL or WebAssembly or WebSockets or whatever? Real-time multiplayer sync? Web maps? Edge architectures and serverless?

TLDR (and really sorry that was so long and ranty), one of the incredibly lucky things for us as web devs is that there are a million sub-paths you can transition to without having to entirely reinvent yourself. Just a few weeks/months of learning a new system and you can start working in it, vs other professions that have to spend years back at school just to enter a field. You just have to find your own niche(s) and move towards them rather than letting your employers & jobs toss you about in a direction you don't like. For me, that was getting away from the backend and the rest of the stack, but for you it might be another direction. Good luck...!

This stems from the fact that many in web dev are not really engineers. There’s a lot of reinventing the wheel and cult like following of various tech influencers. Instead of extending existing libraries people just fork repositories, add minor changes, and advertise them as new. A lot of architectural patterns are just a soup of concepts thrown around without proper planning or understanding of dry or solid.

Try Blazor. Backens C#, frontend C$, shared project for DTO classes, 0 other required dependencies, no 1GB node-modules folder. Easy and fast.

Good, mor job security for us.

I was active in web application development three times (1999, 2007 and circa 2010). Every time, I was horrified by the number of patches, workarounds and conditional code that were needed when doing "pure" web development. But at the same time, every application I developed was a little easier than the previous one, for four reasons.

First, the evolution of the web was pushing away the technologies that were the heaviest, most marginal and least standardized. I'm talking about ActiveX, Applets, Netscape frames, etc. The gradual elimination of these technologies was made possible by evolution of HTML and CSS towards more functionalities.

The second reason was the gradual standardization of key elements in web application rendering and execution. JavaScript behavior and functions, DOM structure and events, CSS element size calculation, etc. This standardization made it much easier to write code that "mostly" works cross browser.

Third, the modern web development frameworks and libraries. These contain the convoluted conditional code that you really don't want to write every time you want to implement something. Plus, once you've written your code, you don't have to completely revisit it every time a new browser version is released. I once wrote a nice website with drop-down menus which worked fine on Firefox and IE6 and IE7. Yay. But then, it was broken in the new version of IE. And then, Flash contents became "first layer" and opaque, and so the menus were rendered behind the contents. The amount of work I had to spend every six months to keep it running was not worth it. If I had used a popular framework maintained by the community (which were a little less common back then), it would have been less frustrating.

Fourth, mobile-friendly websites. The success of tablets and smartphones in the 2010s pushed web developers to have a simplified, more streamlined version of their websites available. Eventually, this had a major influence on the "PC" version of the same websites. Today, most websites have lots of functionality and interactions, but they're also simpler, the pages are shorter, there's less screen size conditional rendering, less overwhelming animations and extremely convoluted layouts.

All that to say... Web development is not as crazy and frustrating as it was just 10 years ago. One of the problems I'm seeing is that many designers still think in terms of fixed screen size, and full screen animations, and try to cram everything on the same page. These are really bad design patterns. Sure you want to dazzle you client with your HTML5 powess and ability to design gorgeous contents. But in the end, visitors and customers will be put off by imperfectly supported features, long load time, resource heavy rendering, clunky in-page scrolling, non-touchscreen-friendly buttons, and poor ergonomics in general.

Most sites that are a nightmare for the developer are also a nightmare for the users. In some cases, just reminding the designers they a load time should be under 2 seconds on a 4G connection might be sufficient to calm down their hubris.

I think you should try out Angular. React ecosystem is a mess and needs extremely experienced developers to produce software that doesn't suck.

Angular, on the other hand, it's quite simple and helps you to get the shit done.