I’ve hit a point where it just doesn’t seem like the end justifies the means in the vast majority of cases anymore which really doesn’t make me excited to work on much in this space now.
The one redeeming quality of doing this kind of work is that it is in very high demand, and I worry that the price of becoming more specialized or doing something more enjoyable with less bloat is that it becomes much harder to find jobs.
Has anyone either switched from doing web development type work to something else they enjoy more for similar reasons? If anyone considers themselves very specialized in an area, do you worry about job opportunities?
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 wrote about a hypothesis here: https://medium.com/@scott.stevenson/how-to-finally-make-some...
Most of us are scared by the ambiguity of actual creative work, so unless we are under the threat of deadline, we seek out "structured games" to play so that we can put off the anxiety of freeform work. These games are:
(1) Tool Game: Researching and setting up tools (2) Learning Game: Books, podcasts, courses (3) Maintenance Game: Cleaning up our desktop, desk, house, etc. (4) Process Game: Setting up new processes and following them
The knowledge that things are actually easy and straightforward means we actually need to do the creative part of the work--many people are not ready to face that knowledge.
I…I…I am triggered by this.
So it’s as if, people such as myself are on the hunt for artificial positive feedback loops that are functionally beautified masks of procrastination. Fueled by, perhaps a subconscious lack of confidence, or a sense of ignorance. Something to that effect.
So now imagine an entire department, teams, organizations all suffering from this? This can explain a lot.
This is exactly what I have been doing for so long (~2 years), I get hyped about a new project, delve into the "best" way of solving the problem and encounter 4-5 shiny new things, spend an unreal amount of time scaffolding and using new tech to create a base framework for whatever I am doing, and then when I actually have to solve the problem my productivity stagnates and I procrastinate more.
Even now I am conflicted/lost on what to do, this response is tbh a cry for help from people who have encountered something like this. Any insight would be great.
Anyway, I find the usage of the term "game" to be quite odd. Why not "strategy?" I'm not sure I agree with the overall point, but enjoy how you've operationalized/categorized behavior in this way. There is value in that.
It happens because these technologies solve real problem for some subset of their users. Usually when people are saying that technology has become too complicated, it's because they happen to be looking from a perspective where the problems that the technology solves are invisible to them. That doesn't mean that the problem isn't important - it just means the problem isn't important for them. The easiest way to motivate this is to imagine the kinds of problems that need solving at large companies with thousands of employees. They look vastly different than the problems of someone like me working on a side project by myself.
e.g., TypeScript might not be useful for some single-person teams of developers. It's quite useful for teams of around 5, and it's unthinkable to work without it in teams of 100+. Does this mean that the single-developer team is wrong?
(I'd actually say the same thing about React. If you're a one-man team, go ahead, do whatever you want. But if you're working with 100 other engineers, god help you if you're all directly manipulating the DOM with vanilla JS.)
Most "complex" technology is solving many problems for many different smallish subsets of its users at the same time. To the average bystander, it can look like the technology has gained huge amounts of unnecessary complexity, but it hasn't, not really - it's just complexity which isn't directly relevant to you.
(OK, and yes, some other technology is just needlessly stupid, but...)
Type annotation also serves as a form of 'hard' documentation. If it's wrong or no longer correct, it will make things turn orange in your IDE and make your type linting tool go bonkers. Even as a single developer this has tremendous benefits. It's much easier to come back to something you wrote months/years ago and get back into it rather than having to go through each function to see what it returns under every situation.
I feel that is frequently the issue, fragmentation and derivation caused by a lack of fundamental first principles thinking, willingness to tackle the issue from the ground up. The outcome is then talk of bolting on yet another tool or some fix that really only ads debt.
Even if you don't want to use TS in it's full glory, you can just rename your files with a `.ts`, turn strict mode off, run everything through the compilation step, and weed out a category of simple mistakes from that alone. Add in that you can slowly add in certain rules to reach a level of strictness as you need and I see no reason how a JS dev would be better off writing vanilla JS than at least using TS and only running the compile step. Of course, I think taking the time to learn and fully utilize typescript the best path forward, even those with absolutely no desire to learn it can utilize some of it's strengths by reading the docs for 15 minutes.
Far from an unnecessary complexity, it's because an incredibly helpful tool at all levels.
Because vaccines were so successful in their harm reduction to even elimination, there h
created a perverse belief that vaccines
were not effective, and then that they were actually harmful. Being ubiquitous and their effects the same, and the absence of their necessary disease.
Tools that solve problems experience a lifecycle that eventually if successful get weilded by people who never had firsthand experience of the problem.
Really a very large fractal problem space.
We envision a similar problem in autopilot system with 'safety' fall backs. For now, autopilots can disengage and let a pilot take control, but soon, we will run out of qualified pilots to disengage to, and no secure safety procedure.
I tried to do this at several companies and ended up feeling like a pariah. At the end of the day, engineers, especially younger ones, like to follow trends, "learn new things", pad their resumes, and build bespoke solutions. Trying to fight against this will only make you look like a troglodyte or a party pooper.
I know I'm right, as I'm now sure the devs telling me no were right, but I'll be pushed out same as they were.
Young blood is naive and cheap and plentiful so they will always have the momentum advantage. They're the ones that promise the moon to other departments and then stay up all night covering their tracks when they were wrong.
Because nobody wants to hear "that feature isn't viable given our architecture."
So we build systems that can accommodate any possible future feature. No matter how unlikely. And no matter how much extraneous complexity it adds now.
In order to maintain simplicity you have to enforce simplicity. And tech business culture doesn't like that.
Your whole post is spot-on :)
My two cents on the answer to this question:
- New tools / frameworks / libraries / etc often position themselves as “solving” some perceived deficiency of the prior generation of that thing. So it can be attractive to want to move over to something that solves a pain point. (Whether it actually does, or whether it just replaces it with a new pain point is another thing…) Monolith to microservices is an example.
- At least for me, if I’m starting a new project (especially if it’s in a space I’m not that experienced in), it’s tempting to choose what looks to be the simplest choice, which could be for example a niche database technology suited for my exact need (even if in reality a regular SQL db would be just fine).
- Engineers like to play with new toys!
1. Boredom. Everyone wants to be doing interesting work, and doing the same thing that's been done a million times before is probably pretty dull. Devs don't want to feel like code monkeys piecing things together assembly line style, even if that's exactly what's needed for many sites, apps, etc.
2. CV/Resume padding. Perhaps many people see every job as a stepping stone to the next one, and hope a complex solution will get them hired at a FAANG company or fast growing startup in future.
3. Expectations. Problems at large tech companies like Google are more likely to be documented online, since the folks working there tend to have more of an online/social media/blog presence than the folks doing 9-5s at more traditional companies. So people think "hey, if this is how others are doing it, this must be the proper way to do it", ignoring the fact that it's the proper way for a company expecting X billion users a year rather than a more reasonable number.
4. Ego/online reputation. Saying you used a fancy framework and hosting setup with microservices for your project gets a lot more votes on Reddit and Hacker News than saying you used say, basic HTML and CSS.
5. Lack of training/learning opportunities at work. Companies tend not to give workers much of a chance to learn new tech or work on interesting projects in work hours, which would provide them a place to experiment with these new technologies. So they try and integrate it into their normal work instead, even if it's completely the wrong solution for the problem at hand.
I highly disagree with everyone else. This is the answer why:
Because there's no clear or definitive answer to What's best the "best" architecture or system for building these things. The entire industry is full of people making up stuff without anyone truly knowing anything.
For the shortest distance between two points we can calculate an answer. there's a definitive optimum. The question of what's the best web service is infinitely more complex. The inputs are huge in number and even the definition of "best" is complex and hard to define... So in short we essentially have no mathematical theory for software design and technology that can help us define what is "best." It's the same problem they have in Art and Design.
So nobody actually knows what is better BUT they think they know so they build wrappers around bad technology or they build completely new frameworks NONE of which actually provably move the needle forward. In fact the needle can move backwards and nobody knows!
When something can't be calculated, it's "Designed." This is the difference between "design" and calculation. Anything that's designed is basically some human wandering around in an area almost aimlessly without ever truly knowing what is optimum. They just use their gut and find some sort of answer that somewhat works. This is the current and past state of the programming industry. That is why on some intuitive level we can see that a lot of the industry looks like it's moving backwards.
Let's say we do have an equation that can take all the components that go into web application development and give you a numerical rating on how good it is. If we had such a model, my best guess is that if we took a system from the past and compared it to a system now, the Modern system will actually have a LOWER numerical rating.
But that's just my guess. As of now, nobody can truly define what that numerical rating represents and nobody knows whether some new framework or design methodology actually increases the amount of points. We are doomed forever to exist in this endless design loop until someone finds a mathematical model that can prove and layout the big picture from a quantitative perspective.
I wrote up my hypothesis here: https://hasen.substack.com/i/52275953/why-the-situation-pers...
Basically, programmers love complexity.
If they can't solve real problems, they will create fake problems so they can solve them.
They might not realize that's what they're doing.
Programmers love solving puzzles. It's why they program. The problem arises when they can't solve the real puzzle due to lack of experience (and lack of skill which comes from lack of practice), they solve secondary and tertiary puzzles that contribute nothing to the real problem at hand.
Instead of "How can I write 1000 lines of code to solve this problem?" they opt for "how can I configure these 20 libraries and glue them together so that a solution to the problem emerges from their interaction?"
People who don't see the existing solutions as overly complex are content to stay at their current level and have no vision of solving bigger more difficult problems. They think they are already working at or near the peak of human possibility.
> "How can I write 1000 lines of code to solve this problem?"
I opt for "Why are these libraries so complicated? I'll research all 20 libraries and take the parts I like and build a newer, simpler framework."
A lot of people value more enhancing their résumé than solving problems
What we need to do is not that complicated but making it so distracts from understanding the harder problem at hand while appearing to be working furiously.
The intelligence is in the end result of the engineering, but no one wants their work to be so simple it could have been done by a junior.
A few answers already but let me add one: Complex technologies favour seniors who are capable of understanding the complexity, over juniors who might struggle more. And it's seniors who make the decisions on what technology to use, so I think it's "rational" if they (even subconsciously) make choices which benefit them. They don't want to get replaced by cheaper juniors.
You can also learn to leave work at work. Keep your side projects simple, if you have any. And rest easy knowing that at work the efforts of one person, you, create enough maintenance work for two people; enjoy that job security.
1. New Tools, in the modern era means Promotion, VCs, Money, Prestige. personal branding.
2. Creating complexity, in the name of needs for these Big Tech is a great way to create a moat for themselves.
3. Ideology, web development is possibly the 2nd worst places if it wasn't for Rust evangelism strike force. The idea that every single god damn thing should be in Javascript or SPA.
4. The Act of design before coding is gone. Especially in the era of Web Development. Lead by Google and Facebook which later spread across Silicon Valley and later across the world. An Act which is even seen as evil or forbidden.
The answer to that question has been the same as long as I've been using react. Represent most of your app logic in pure functions. This has been the React team's recommendation, pretty much since the beginning.
Once you get hit to the idea of making everything a function, it pays to learn some functional programming design patterns. This increases your vocabulary for abstracting your application logic into a function.
Once almost everything lives in functions, your react components should really only care about managing the view.
We humans are creative creatures. When we are doing the same thing for a long time, we tend to get bored and make change happen. We 'improve' things, we move things about. We 'make things better'. So we are not bored anymore.
- create vm instance ( setup firewall, users, network dna, stuff) - install : apache, runtime - install app.
Every single answer goes straight to name dropping various specific techs/tools and I don’t doubt it really is the most simple way for each poster. But I think a much better answer, would be a bunch of questions that dig into what kind of problem you are trying to solve, what are the circumstances, skillset, limitations, budget, is it 1 tiny private app for fun or a couple of apps your team or even company depends on etc.
Because it depends on the specifics in _your_ situation and jumping straight to _a_ solution, without understanding _your_ problem, is imho part of the over-complexity-problem in our industry.
Here is my suggestion for keeping it simple, by solely relying on skills you will need anyways: git and shell scripting.
- Write a shell script that executes all those commands you would run manually to set up your system.
- Put up a git repository in the `/` directory, `.gitignore` everything by default, and explicitly git-notignore all those configuration files and user files/maintenance scripts which are relevant for your environment. Use githooks to also track/restore file permissions and ownerships of these tracked files.
You can also script the process with (for example) Terraform.
If you later want to port this into terraform, you can.
It's just as bad. Different, but bad.
These teams lack technical leadership that is based on professional experience. This is the sort of lesson that is acquired after at least 10 if not more years of professional work, however the industry tests for algorithmic performance art on whiteboards to select software engineers.
This can seriously limit your earning potential by limiting your career advancement. You are forced to create complexity monsters for promotions at the type companies I've worked at.
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.
It caught on because "feature factory" startups used simple frameworks to make an MVP and didn't know shit about RDBMS administration, optimization, or schema planning so when it was schema migration time it was time for things to start breaking. With NoSQL (specifically the "document store" types) you could just keep throwing shit in there whenever you needed it -- magic schema migration! And it was "Web Scale"©!
If data requires reloads or manipulations a side restful api needs to be created along the main endpoint which renders html. But it's fairly straightforward with DRF and the enforced by default apps/models structure of Django.
Until a certain point I find this arrangement enjoyable to work with. Once it stops, it's clear as day that the page should be rewritten from scratch with rendering on client side.
I moved to writing web-code for personal purposes only. Now, I specialize in other types of technical areas for paycheck purposes (C++, Git, PM support, computer HW maintenance and procurement, similar overly niche technical tasks, etc).
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.
Just imagine for a second we were to start from scratch. Imagine an HTML/CSS Spec thats easy enough to implement so that we have multiple independent vendors with competing, correct implementations. Imagine something like web assembly as the basis for scripting those HTML/CSS Engines. Imagine the amount of energy, developer time and bugs we could save with a sane, modern standard that implements all the lessons learned from what came before...
One can dream...
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
Like take this for example: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
Did we just give up on using semantic elements? People barely know how to write regular HTML anymore, and the ARIA spec is confusing. I'm glad it exists, but to me it fits into the same category as "Web components" - a bad idea that isn't widely adopted because it sucks.
So the unfortunate reality is that any well-intentioned attempt to reform them would be used instead to reshape them for corporate interests, with no guarantee that we even end up with better specs from a developer point of view. The incentives lay in the direction of guaranteeing corporate interests, with users losing more of their freedom to choose how they access and use the Web; the developer concerns will at best be used as a PR front for the press headlines.
And the follow up question, which is pointed, is: if your proposed solution would look similar to current JS solution X, why would it be better than X? Is the goal removing the build process? Increasing uniformity across the ecosystem?
>Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers?
The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does.
I think under the hood, the people who actually write the DOM apis would know how to do that in the most performant way possible. I know any native approach would certainly be faster than a Javascript framework. To me the more important part is getting the API surface right.
That's the big problem with a lot of these standards updates. They kind of half assedly add a feature that's inconvenient and then nobody uses it. They need to think more like "How can we incentivize people to drop X framework and do it natively?"
>if your proposed solution would look similar to current JS solution X, why would it be better than X?
It'd almost certainly be faster being built into the native code, but yes the goal is to remove the build process and tooling. But also to bring things back into balance. Right now, most web apps are a big bundle of JavaScript. But with these changes, it'd be several HTML files, JS files, CSS files. In balance again. Each technology has its own place. I think the average skillset of front-end developers would improve massively if they didn't have to do stuff like chase down NPM problems or debug Webpack.
Not sure what this means exactly
> 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier.
Something like AlpineJS built-in?
> 3. Update the HTML spec to allow for semantically describing user interface elements of software applications.
ARIA roles kind of already do this.
The same thing happens in all of comp-sci: we create a new programming language that compiles to an old language (C to Assembly) because changing the old one takes longer than inventing a new one.
They all implement these concepts in Javascript. But if we don't standardize and allow browser vendors to implement at a lower level, we will always be taking a speed hit and on the framework treadmill. We need to take what we know works and do it.
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.
[1]: https://htmx.org/
The benefits react provides in functionality (page transitions and controls) could have been better addressed within web browsers, but the process of web design is constantly trying to resolve front end issues in code to suit a wide variety of OS versions and browsers, which is where a big problem lies...
i don't have the answers myself, but this urge to use tons of different libraries, langs, services, and tools just to build web apps, and then the never ending cycle of updating things daily to maintain stability and security may make people money, but it's really not sustainable in the long run. This is why most sites are beginning to be run on platforms like WIX and sharepoint, while independent developers and small app companies go broke. There is just too much damn complexity gumming up everything.
Basecamp has been around for ~20 years. I have a lot of confidence that it'll be around and supported because it's a substantial part of the stack involved with a real world application that is their primary business. It's also from a group of folks who have an impeccable track record for supporting the tools they use.
I use it to replace almost all "api" calls to the backend and for the "turbolinks like" navigation, modals, etc. Then I use Alpinejs for the really interactive/complex parts.
I'm not doing a React/SPA ever again if I have any chance to decide on that.
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.
Magic quotes is of course very different from an ORM doing the application-specific encoding. It’s just very worrying when people don’t know which layer of the stack sanitizes for them.
For those of you young enough to not have witnessed php. Magic quotes used to be a popular configuration option that would sanitize all GET and POST inputs to make it safe to use in sql. Needless to say, it didn’t work and instead corrupts user data that is not intended to go through sql.
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
Old software sucked a lot, and automation sucked a lot. Weird issues where you HAD to know what went wrong, because handholding was looked down upon. The lack of automation meant that servers were pets, you looked after them, groomed them, maybe even sang a song to get the piece of junk going. Modern automation means you mostly care about the blueprint, not the actual instance. If it's not working properly, you reimage. If you need more, fire up more instances.
Also, what can you do on the frontend only? I have two examples from the top of my head:
I was talking specifically about React. But it's not a surprise that "modern front end" devs conflate React with JavaScript.
If you work for a company that doesn't give you Sudo on your own machine as a developer by default, find a new job
Don't work for companies that still treat their professionals like children.
If your employer won't give you the tools you need to do your job you should find another one. If your IT/security department is there to block you instead of help you get work done, you should also find a new job. I'm not saying walk out the door today, just that you don't deserve to be treated like that.
2010 edit an html button:
0. Install an ftp client (you need to mention that if you mention installing git)
1. pull the file from ftp or sourcesafe/svn
2. edit the button
3. upload to ftp
2020 edit an html button:
1. clone the code 2. edit the html button 3. commit changes
obviously sarcastic. most of the things you are complaining about bring to mind a person who is bored of doing responsible coding.
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.
Not really related to the above but I learned React when I started my current job and I hated and did not understand it when I first started https://cmdcolin.github.io/posts/2020-07-04. Now it has changed my thinking entirely, and I think react is very powerful. Not without awkwardness and whatnot, but it's better than spaghetti jQuery era
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.
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.
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.
- mostly backwards compatible with easy upgrades, even between major versions
- many new features all the time for better static analysis, type safety, speed, succinct code, etc
- designed for use with Web
- PHP itself is a (good) templating langue, so no need to reinvent the wheel there
- FFI interface for integrating native code
- easy to learn
Some downsides though:
- Single threaded with typically blocking I/O and no built-in async paradigm means it’s like 1/1000 as fast as something like node for I/O heavy applications, even when using something like ReactPHP
- Need something like FPM to fire up one whole process per visitor
- Many core language features like OOP, type hints, lambdas, etc are a bolted-on afterthought and still only 60-90% there
- Still no typed resource handles until PHP 9+
- Syntax is cumbersome in many ways, though improving
You know why there are amateurs? Because it's simple, understandable, maintainable, low barrier of entry.
You know what amateurs do with simple things and time? Become professionals. Then they solve other people's problems, rather than solve never-ending developer problems we create ourselves.
Having done PHP development for +12 years, I have never once had a debate about getters and setters. Nor did I know that was something to even debate about.
The good client side rendered js frameworks, react/svelte/vue have SSR solutions, but they also have their own servers for enabling SSR - next.js and sveltekit. So if you need SSR, SEO, good client side interactivity - you might as well as used those pre-packaged servers. You also have the added benefit of working in a single language across the stack. Laravel's front end recommendations aren't great - https://laravel.com/docs/9.x/frontend
I do like how react packages html/css/js as components and that you get static typing across the typescript to html bindings which makes the code more maintainable. Also react has a pretty good front end component library with MUI. You kind of have to 'kitchen sink' the front end libraries with PHP as there's no compiler to weed out the ones you're not using - plus you need to use a CSS library, and 'bring your own javascript' to utilize them with where MUI includes everything wrapped as components already.
Interested in others thoughts on this.
Ehh, what? Sessions are state.
> - just drop a file on web server and it works (no crazy CI pipeline)
Except when I have to set-up php-fpm, opcache and configure countless parameters in php.ini.
> - the documentation is fantastic,
Yes, but I still have to check it for useless constructs like "mysql_real_escape_string" vs "mysql_escape_string" which should have never existed in the first place.
PHP didn't earn its reputation without a reason. But I'm glad to hear that certain things are improving.
Is database state?
> php-fpm, opcache
Nope
> countless parameters
Certainly not
> "mysql_real_escape_string" vs "mysql_escape_string"
There are only a handful of these, and you can learn about them with a simple google search.
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.
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 didn't see any forms libraries either, so the forms situation seems even more primitive. I'm the author of iommi so I now have very high level abstractions for forms/tables/menus/etc, and a transparent way to compose these. I would hate to start over from scratch...
Am I just missing some libraries?
It’s a lot like Rails in that regard, where you have to model the data yourself. But it’s a part of the job — and it teaches you take advantage of the DB in ways that Django can’t.
That said, I primarily work in other areas. This is just for when I need a web app.
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
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.
Every time I read things like this I wonder if most people here are just building landing pages or side projects.
I've literally always had need for validations, background jobs, translations, authentication, authorization, migrations, orm/data libraries, CLI commands for maintenance tasks, etc, etc. "Just next.js and express" or "just next.js and prisma" is still missing a TON of stuff for me. Of course you can npm install 3000 other packages to achieve all of this, but that's a lot of work to get it right, documented, secured and battle proven.
> I just write React code and it automatically shows up on the page.
I just write HTML in a file and it shows up on the page. My solution is simpler, isn't it?
Sure, I was simplifying to make a point, of course I use all of those. My main point however was that there are defined, standardized solutions for all of those. It's not like there's that much churn in authentication libraries for example, most people would use Passport or just JWT.
> but that's a lot of work to get it right, documented, secured and battle proven.
It's really not, because again, solutions are pretty standardized.
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: ‘<Foo {…fooProps} />’. 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.
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.
Electrician
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 :)
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.
</two-cents>
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.
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.
All no-framework-needed examples seem to boil down to having a simple enough problem needing just one (or few) front end developers. Would be good to hear how a larger team (say 10+) managed without one.
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.
* "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/
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.
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
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.
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.
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.
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.
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.
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.
Still in use, still killing it.
The problem I find with Django is that it's a purely backend framework. The moment you want to use their highly outdated templating system it becomes evident it's from the 00s. It doesn't even handle assets bundling.
Laravel and Rails instead can be considered more "full stack" solutions, as both have really nice frontend stories too.
But Django is great if you want to build a backoffice with the Admin and django-rest-framework. That's how we used it back in the day anyways.
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?
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.
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.
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.
For one, we had to rewrite the app 3 times because the library switched from Less, to 2 different css-in-js solutions across 3 different major versions.
Then we switched to server side rendering and suffered some weird glitches. Turns out, when using SSR, styles get rendered twice: once on the server and once in the browser. So you have to write a custom logic to remove the styles that are rendered on the server.
What I'm trying to say is that React was invented at Facebook to solve problems they were having but the industry was too quick to adopt it as a solution for their own problems. Facebook can afford to rewrite a piece of software 100 times because of their unlimited budget. They can also deal with all the bs that comes with frontend frameworks because of their ability to throw an unlimited amount of engineers at a problem.
Small company with 10 engineers? Just use something appropriate for problems you're trying to solve at your budget.
https://mui.com/system/styles/basics/ It looks like MUI had some decent intentions in their changes.
https://mui.com/material-ui/guides/server-rendering/#mui-on-... It also looks like they called out how to address the SSR issue (maybe they recently added these docs?).
I kind of accept this type of friction as a part of libraries changing (As long as the upgrade paths aren't insane).
There are also more easier-than-Heroku competitors than ever.
I'm more productive than ever, but I suppose mileage varies.
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.
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.
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.
It all sounds great in theory, but it comes with so many baggage, and only tends to work in certain SV type companies.
don't use tools just because it's popular but make your productivity plummet..
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.
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.
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...!
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.
Angular, on the other hand, it's quite simple and helps you to get the shit done.
