Ask HN: Getting tired of complexity in web development

270 points by jelan 3 years ago | 282 comments

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.

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?

coffeefirst 3 years ago |

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?

ScottStevenson 3 years ago | |

>Why does this happen?

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.

the-printer 3 years ago | | |

> (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

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.

h4ch1 3 years ago | | |

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.

hooloovoo_zoo 3 years ago | | |

I call these games ‘using emacs’. (as an emacs user)

blacksmith_tb 3 years ago | | |

I am certainly guilty of those, but I would point to larger pressures at the team and org levels - continuing to do things "the old way" (regardless of how old, just "the way we have been doing them") means no budget for big new projects to "modernize" apps and systems, no chance for managers to put their stamp on things with big new projects, etc.

domnomnom 3 years ago | | |

Based on this description, I should vary my playing of games.

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.

kirso 3 years ago | | |

Isn't this literally just self-sabotaging? :)

johnfn 3 years ago | |

> Why does this happen?

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...)

ok123456 3 years ago | | |

Typescript is basically required to keep you from shooting yourself in the foot with Javascript.

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.

frankfrankfrank 3 years ago | | |

My sense is that is wrong. Case in point, I deal with a group that has a relatively elaborate set of excel workbooks to manage their process. None of the workbooks are great, all of them created and maintained by different teams, and there is persistent discussion of needing to accrue tools or some guy even threw together his own MS Access db to substitute for the workbooks. What they do is not at all beyond what Excel could handle, but it is the lack of fundamental process and methods to design a proper system that is the code and fundamentally problem.

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.

CodeSgt 3 years ago | | |

I agree with the sentiment so this comment is more of a nitpick than anything constructive, but I do feel you may have missed the mark with the typescript example.

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.

cyanydeez 3 years ago | | |

Basically, it's the problem with vaccines and the rise of antivaxxers.

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.

hnuser847 3 years ago | |

> 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?

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.

somehnacct3757 3 years ago | | |

I worked at a company long enough to go from young dev who wants to use shiny new tech (and is told no by party pooper experienced devs); to the party pooper experienced dev for a new group of young devs.

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.

idlehand 3 years ago | | |

As a younger dev I see the opposite in my corner of the world. The senior developers spend countless hours debating the best design, engineering large architectures to bounce a handful of kilobytes of information around in the just right way to achieve architectural purity. Then they do greenfield development with old tech that is simultaneously somehow both old and barely used, as if to generate their own job security.

michaelchisari 3 years ago | |

| Why does this happen?

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.

tomg 3 years ago | |

> 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.

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!

noduerme 3 years ago | |

I just still use jQuery or vanilla typescript when building frontends. To me it's so much more readable, and I almost never have to worry about newer code not playing well with older code. No client has ever even asked me what framework was being used. If the software works and the code is well documented, the fewer frameworks you use the better.

CM30 3 years ago | |

In addition to what the other commenter says about wanting to postpone the 'creative' aspect of the work, I'd also say this happens because of:

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.

deltasevennine 3 years ago | |

>Why does this happen?

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.

hsn915 3 years ago | |

> Why does this happen

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?"

hsn915 3 years ago | | |

I should also add that people who advocate for simplicity primarily do so because they want to solve bigger / more complicated problems, but the complexity level gets in their way.

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.

mmgutz 3 years ago | | |

I'm guilty.

> "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."

invaliduser 3 years ago | |

>Why does this happen?

A lot of people value more enhancing their résumé than solving problems

agumonkey 3 years ago | | |

a lot of companies value shiny resume than complex problems solved

Simply this

tejtm 3 years ago | |

In scientific/academic environments (the only type I can speak of) I have sometimes wondered if my fellow computerists have complexity envy.

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.

bobthepanda 3 years ago | | |

This is basically the technical equivalent of bikeshedding, which has been known for a while. https://en.wikipedia.org/wiki/Law_of_triviality

P5fRxh5kUvp2th 3 years ago | |

It happens because everyone wants to imagine they're smart and just happen to work for a no name company.

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.

adrianmsmith 3 years ago | |

> Why does this happen?

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.

plugin-baby 3 years ago | | |

I’ve observed the opposite - less experienced devs tend to want to use more complicated and extensive/invasive tech, without understanding if it’s appropriate or what its limitations are.

Buttons840 3 years ago | |

> The only thing you can do (besides leave it all behind and open a taqueria) is be a voice for simplicity.

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.

ksec 3 years ago | |

>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.

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.

schwartzworld 3 years ago | |

> 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?

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.

unity1001 3 years ago | |

> Why does this happen?

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.

deltasevennine 3 years ago | | |

except nothing was improved. Just changed.

kbrannigan 3 years ago | |

Speaking of ops. What is the simplest reproducible way to accomplish this task.

- create vm instance ( setup firewall, users, network dna, stuff) - install : apache, runtime - install app.

bingo-bongo 3 years ago | | |

There is already many answers to your question and not to be rude, but I think it perfectly shows part of the problem OP is talking about.

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.

Eduard 3 years ago | | |

All the responses you got so far suggest exactly what this "Ask HN" actually wants to avoid: Terraform, AMI, Packer, Ansible, Chef ..., the list goes on

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.

gregjor 3 years ago | | |

Set it up once. Snapshot an image (called an AMI on AWS, but applies on all cloud services). Use the image to make new identical instances.

You can also script the process with (for example) Terraform.

eddsh 3 years ago | | |

Honestly I use bash for this. I keep a local repo of .deb/.tar.gz files and scp them onto a machine which makes them reproducible. I use uvt-kvm for VMs, config files to cover basic settings, and that's basically it. I run a fairly decent sized test lab with multiple servers that have to be reproducible, quick to edit, and install fairly complex toolchains.

icedchai 3 years ago | | |

You launch the instance with "aws" CLI, passing it a user-data script (cloud config) that does all the things you describe with simple shell scripts. You install the app by copying it from an S3 location (build output), which is also defined in the script.

If you later want to port this into terraform, you can.

skydhash 3 years ago | | |

Either the snapshot route to have a base image you can then run a single script to install the app. Or use something like Ansible to have reproducible configuration.

aprdm 3 years ago | | |

A single ansible yaml

nikanj 3 years ago | | |

Heroku or alternatives

betaby 3 years ago | | |

create - terraform, install / manage - cfengine / ansible / chef

mpweiher 3 years ago | |

> If you try mobile app development, let me know, I've never tried but I doubt it's exempt

It's just as bad. Different, but bad.

eternalban 3 years ago | |

> Why does this happen?

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.

dominotw 3 years ago | |

> The only thing you can do (besides leave it all behind and open a taqueria) is be a voice for simplicity.

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.

hnuser847 3 years ago |

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.

dimmke 3 years ago |

>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.

nickjj 3 years ago |

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/

xd 3 years ago |

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.

yrgulation 3 years ago | |

Thing is if you understand php you dont really need a framework. Sure composer packages are a must to avoid rewriting whats out there, but a framework not so much. When i conducted interviews i was shocked at how many php devs had no clue about what an sql injection is, they almost all answered “the framework does it for you” and it was such a basic thing.

xd 3 years ago | | |

Oh god ORM's, pointless waste of time and just an excuse not to learn SQL.. almost as bad as the #1 PHP fallacy; Smarty (which is still a thing).

Too 3 years ago | | |

I ask this question a lot too, and yeah it’s shocking to see how many that believe things like magic quotes or some other unknown layer solve everything.

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.

mouzogu 3 years ago |

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

jelan 3 years ago |

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.

iamsaitam 3 years ago | |

Web Development is as complicated as you (or the team) makes it. Your issue seems to be with people's choices rather than the ecosystem. Changing to another area won't solve anything for you. Choose the right team for the kind of work you like.

tonto 3 years ago | |

everyone has a choice in taking on those dependencies. as a solo dev you get to make those choices. In the context of work, it is harder because you have to balance many other needs from technical to just the human squishy feeling of making people's code get accepted and not fighting everyone on every damn thing. It's hard to get everyone on the same page!

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

jt2190 3 years ago |

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.

stavros 3 years ago | |

I think we'll just go back to the old approaches. I already build apps with thin frontends, and maybe use HTMX if desired. Fat frontends aren't worth the complexity unless you have an interactive app (e.g. Google Docs), which you very probably don't.

jugg1es 3 years ago |

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.

alberth 3 years ago |

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.

andrejandre 3 years ago |

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.

engineerDave 3 years ago |

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.

boxed 3 years ago | |

I've looked at Elixir a bit, but I came away with the expression that it would be a bit like doing Django before 1.7 where I had to do schema migrations manually. This is a huge deal to me.

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?

a_bored_husky 3 years ago | | |

Fwiw I was afraid of manual migrations too, coming from Django, but its not that terrible once you get used to it. There should be a few form libs out there but I havent needed one so far. Chris McCord said at ElixirConf that there are plans of reworking the forms api to make it work better with LiveView.

sergiomattei 3 years ago | | |

I also felt that way coming from Django, but I got used to it and embraced it

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.

0xblinq 3 years ago | |

Elixir is a great idea, but it's already dead. I know of several companies here in Europe that already ditched it and went back to other older technologies or moved to Go, etc. because the Elixir ecosystem is so small. Also they had tons of trouble hiring for it.

carom 3 years ago |

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.

kim0 3 years ago | |

I'm trying to do the same. How do I make a kinda pretty frontend without much effort though

nop_slide 3 years ago | | |

Tailwind, DaisyUI, and AlpineJS has been my recent simple jam.

ostenning 3 years ago |

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

cercatrova 3 years ago |

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.

0xblinq 3 years ago | |

> 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.

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?

cercatrova 3 years ago | | |

> I've literally always had need for validations, background jobs, translations, authentication, authorization, migrations, orm/data libraries, CLI commands for maintenance tasks,

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.

erlich 3 years ago |

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: ‘<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.

zxcq544 3 years ago | |

I have same opinion on react and after trying sveltekit I was really surprised how simple front end could look like. Now I can't even use anything except svelte and it's kinda sad but man it feels right for frontend.

locallost 3 years ago |

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.

gjvc 3 years ago | |

If your heart is still in it, I'd try to learn a skill that will be relevant forever.

Electrician

tomg 3 years ago |

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 :)

lhorie 3 years ago |

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.

</two-cents>

mediascreen 3 years ago |

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.

butz 3 years ago |

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.

klyrs 3 years ago |

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.

npalli 3 years ago | |

>> but I recently did some work with a front-end contractor

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.

not_the_fda 3 years ago |

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.

RomanPushkin 3 years ago |

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/

0xblinq 3 years ago | |

Have my upvote. Full stack frameworks like Rails, Laravel or Adonis are not "fashion" anymore apparently. And people keep wasting time reinventing the wheel because that's the fashionable thing to do.

didip 3 years ago |

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.

incrudible 3 years ago | |

You can do that if you're building a website, but people want to build desktop-class applications these days, and you can't just sprinkle some JS on server-side rendering and make it behave like that. Also, the same people with a lot of experience in backend work probably aren't that good at creating GUIs, and vice versa.

throwaway0asd 3 years ago |

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

karaterobot 3 years ago |

> 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.

kyleyeats 3 years ago |

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

rpgbr 3 years ago |

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

shtopointo 3 years ago |

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.

ruduhudi 3 years ago |

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.

phendrenad2 3 years ago | |

I think that developers will always complicate things to the point where they can't complicate it any further. If something is already complex (due to browser incompatibilities, weird HTML/CSS/JS bugs, etc.) then developers can't raise the complexity much. Now that those issues have mostly been resolved, we've invented build systems and weird declarative/functional frameworks to bring it back up to that same complexity level.

phendrenad2 3 years ago |

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.

willhslade 3 years ago |

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.

0xblinq 3 years ago |

> 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.

jitl 3 years ago |

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.

usgroup 3 years ago |

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.

gatinsama 3 years ago |

I can't believe no one is mentioning Django.

Still in use, still killing it.

0xblinq 3 years ago | |

Django is great, I've used it for many, many years until about 6 years ago.

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.

levkk 3 years ago |

I had a great experience with Hotwired Turbo and Stimulus.

rms93 3 years ago |

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?

WheelsAtLarge 3 years ago |

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.

jbirer 3 years ago |

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.

NotYourLawyer 3 years ago |

Everything since static HTML has been a mistake.

nymanjon 3 years ago |

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

BrandoElFollito 3 years ago |

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.

sebastianconcpt 3 years ago |

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

knackfuss 3 years ago |

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.

i_like_robots 3 years ago |

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.

jb3689 3 years ago |

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

uhrush 3 years ago |

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

jmconfuzeus 3 years ago | |

Not OP but I'll give you an example concerning a project that used Material UI which is a React UI component library.

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.

uhrush 3 years ago | | |

That's very fair, do you still think it was a net positive opposed to writing your own component library?

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).

threatofrain 3 years ago |

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.

reducesuffering 3 years ago | |

That this realistic comment is showing downvotes is worrisome about the general aptitude of HN wrt front-end dev. Good ol' Gell Mann Amnesia...

diob 3 years ago |

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.

iamsaitam 3 years ago | |

Ditto.

timvisee 3 years ago |

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!).

ackatz 3 years ago |

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.

This is very interesting. Where can I start and learn more about it?

ackatz 3 years ago | | |

This article is a really brief primer on this line of work. A lot of it is working with Python, JavaScript, APIs, and building custom solutions to get different COTS security tools and things like Jira to talk to each other. It may not be for everyone but I really enjoy it.

https://www.cadosecurity.com/the-next-in-demand-job-title-se...

pjmlp 3 years ago |

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.

dpedu 3 years ago |

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.

npteljes 3 years ago |

>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.

pcurve 3 years ago |

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.

dudul 3 years ago |

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.

nokya 3 years ago |

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

jwmoz 3 years ago |

Server side rendering ftw

exabrial 3 years ago |

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

icemelt8 3 years ago |

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

motbus3 3 years ago |

Everything is complex and many analysis looks like CSI investigations.

kokizzu2 3 years ago |

been there, just move to Svelte XD simplicity is king

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

hdufort 3 years ago |

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.

oneplane 3 years ago |

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.

solardev 3 years ago |

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...!

yrgulation 3 years ago |

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.

erlich 3 years ago | |

A big problem is for anything to be successful it had to be similar enough to the last thing. E.g. all the new frameworks that look and feel like React. Every new thing is constrained and sticky taped onto the older thing. So no one can ever step back and ask themselves what the truly ideal thing is.

skrowl 3 years ago |

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

wetpaws 3 years ago |

Good, mor job security for us.

hdufort74 3 years ago |

tasubotadas 3 years ago |

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.