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

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

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

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

I wrote about a hypothesis here: https://medium.com/@scott.stevenson/how-to-finally-make-some...

Most of us are scared by the ambiguity of actual creative work, so unless we are under the threat of deadline, we seek out "structured games" to play so that we can put off the anxiety of freeform work. These games are:

(1) Tool Game: Researching and setting up tools (2) Learning Game: Books, podcasts, courses (3) Maintenance Game: Cleaning up our desktop, desk, house, etc. (4) Process Game: Setting up new processes and following them

The knowledge that things are actually easy and straightforward means we actually need to do the creative part of the work--many people are not ready to face that knowledge.

I…I…I am triggered by this.

So it’s as if, people such as myself are on the hunt for artificial positive feedback loops that are functionally beautified masks of procrastination. Fueled by, perhaps a subconscious lack of confidence, or a sense of ignorance. Something to that effect.

So now imagine an entire department, teams, organizations all suffering from this? This can explain a lot.

This is exactly what I have been doing for so long (~2 years), I get hyped about a new project, delve into the "best" way of solving the problem and encounter 4-5 shiny new things, spend an unreal amount of time scaffolding and using new tech to create a base framework for whatever I am doing, and then when I actually have to solve the problem my productivity stagnates and I procrastinate more.

Even now I am conflicted/lost on what to do, this response is tbh a cry for help from people who have encountered something like this. Any insight would be great.

Anyway, I find the usage of the term "game" to be quite odd. Why not "strategy?" I'm not sure I agree with the overall point, but enjoy how you've operationalized/categorized behavior in this way. There is value in that.

It's fine in moderation but tackling ambiguity regularly makes magic 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...)

Type annotation also serves as a form of 'hard' documentation. If it's wrong or no longer correct, it will make things turn orange in your IDE and make your type linting tool go bonkers. Even as a single developer this has tremendous benefits. It's much easier to come back to something you wrote months/years ago and get back into it rather than having to go through each function to see what it returns under every situation.

I feel that is frequently the issue, fragmentation and derivation caused by a lack of fundamental first principles thinking, willingness to tackle the issue from the ground up. The outcome is then talk of bolting on yet another tool or some fix that really only ads debt.

Honestly, I don't think it's even that bad for basic development (they literally have a CLI command that generates a very basic webapp immediately.)

Even if you don't want to use TS in it's full glory, you can just rename your files with a `.ts`, turn strict mode off, run everything through the compilation step, and weed out a category of simple mistakes from that alone. Add in that you can slowly add in certain rules to reach a level of strictness as you need and I see no reason how a JS dev would be better off writing vanilla JS than at least using TS and only running the compile step. Of course, I think taking the time to learn and fully utilize typescript the best path forward, even those with absolutely no desire to learn it can utilize some of it's strengths by reading the docs for 15 minutes.

Far from an unnecessary complexity, it's because an incredibly helpful tool at all levels.

Because vaccines were so successful in their harm reduction to even elimination, there h

created a perverse belief that vaccines

were not effective, and then that they were actually harmful. Being ubiquitous and their effects the same, and the absence of their necessary disease.

Tools that solve problems experience a lifecycle that eventually if successful get weilded by people who never had firsthand experience of the problem.

Really a very large fractal problem space.

We envision a similar problem in autopilot system with 'safety' fall backs. For now, autopilots can disengage and let a pilot take control, but soon, we will run out of qualified pilots to disengage to, and no secure safety procedure.

More on topic, web frameworks solve the following problems for me, which I guess are things now taken for granted:

1. Provide a standard API across all popular browswes by papering over subtle differences in JS- or rendering-engines. This is kess of an issue now worh the homogenization of browser engines

2. Provide components with out-of-the-box accessibility. For me, this alone is worth the price of admissions. YMMV if yiu don't care about your (potential) users who use assistive tech like screen-readers

3. Design systems, CSS frameworks and iconsets makw my webapps look much better than if I were to be left to my own devices. I'm no designer, but the added complexity is worth it to me (think internal tools, not public products with a design budget).

4. Job mobility and the ability to transfer knowledge from one employer to the next. When I put down "react" on my resume, the reader will know exactly what I mean (as opposed to "CorpWebVu revision 5". I am also able to get up to speed on a React codebase because I know the conventions. This also is worth the price of admission by itself.

[1] https://en.wikipedia.org/wiki/Wicked_problem

I tried to do this at several companies and ended up feeling like a pariah. At the end of the day, engineers, especially younger ones, like to follow trends, "learn new things", pad their resumes, and build bespoke solutions. Trying to fight against this will only make you look like a troglodyte or a party pooper.

I know I'm right, as I'm now sure the devs telling me no were right, but I'll be pushed out same as they were.

Young blood is naive and cheap and plentiful so they will always have the momentum advantage. They're the ones that promise the moon to other departments and then stay up all night covering their tracks when they were wrong.

Because nobody wants to hear "that feature isn't viable given our architecture."

So we build systems that can accommodate any possible future feature. No matter how unlikely. And no matter how much extraneous complexity it adds now.

In order to maintain simplicity you have to enforce simplicity. And tech business culture doesn't like that.

Your whole post is spot-on :)

My two cents on the answer to this question:

- New tools / frameworks / libraries / etc often position themselves as “solving” some perceived deficiency of the prior generation of that thing. So it can be attractive to want to move over to something that solves a pain point. (Whether it actually does, or whether it just replaces it with a new pain point is another thing…) Monolith to microservices is an example.

- At least for me, if I’m starting a new project (especially if it’s in a space I’m not that experienced in), it’s tempting to choose what looks to be the simplest choice, which could be for example a niche database technology suited for my exact need (even if in reality a regular SQL db would be just fine).

- Engineers like to play with new toys!

1. Boredom. Everyone wants to be doing interesting work, and doing the same thing that's been done a million times before is probably pretty dull. Devs don't want to feel like code monkeys piecing things together assembly line style, even if that's exactly what's needed for many sites, apps, etc.

2. CV/Resume padding. Perhaps many people see every job as a stepping stone to the next one, and hope a complex solution will get them hired at a FAANG company or fast growing startup in future.

3. Expectations. Problems at large tech companies like Google are more likely to be documented online, since the folks working there tend to have more of an online/social media/blog presence than the folks doing 9-5s at more traditional companies. So people think "hey, if this is how others are doing it, this must be the proper way to do it", ignoring the fact that it's the proper way for a company expecting X billion users a year rather than a more reasonable number.

4. Ego/online reputation. Saying you used a fancy framework and hosting setup with microservices for your project gets a lot more votes on Reddit and Hacker News than saying you used say, basic HTML and CSS.

5. Lack of training/learning opportunities at work. Companies tend not to give workers much of a chance to learn new tech or work on interesting projects in work hours, which would provide them a place to experiment with these new technologies. So they try and integrate it into their normal work instead, even if it's completely the wrong solution for the problem at hand.

I highly disagree with everyone else. This is the answer why:

Because there's no clear or definitive answer to What's best the "best" architecture or system for building these things. The entire industry is full of people making up stuff without anyone truly knowing anything.

For the shortest distance between two points we can calculate an answer. there's a definitive optimum. The question of what's the best web service is infinitely more complex. The inputs are huge in number and even the definition of "best" is complex and hard to define... So in short we essentially have no mathematical theory for software design and technology that can help us define what is "best." It's the same problem they have in Art and Design.

So nobody actually knows what is better BUT they think they know so they build wrappers around bad technology or they build completely new frameworks NONE of which actually provably move the needle forward. In fact the needle can move backwards and nobody knows!

When something can't be calculated, it's "Designed." This is the difference between "design" and calculation. Anything that's designed is basically some human wandering around in an area almost aimlessly without ever truly knowing what is optimum. They just use their gut and find some sort of answer that somewhat works. This is the current and past state of the programming industry. That is why on some intuitive level we can see that a lot of the industry looks like it's moving backwards.

Let's say we do have an equation that can take all the components that go into web application development and give you a numerical rating on how good it is. If we had such a model, my best guess is that if we took a system from the past and compared it to a system now, the Modern system will actually have a LOWER numerical rating.

But that's just my guess. As of now, nobody can truly define what that numerical rating represents and nobody knows whether some new framework or design methodology actually increases the amount of points. We are doomed forever to exist in this endless design loop until someone finds a mathematical model that can prove and layout the big picture from a quantitative perspective.

I wrote up my hypothesis here: https://hasen.substack.com/i/52275953/why-the-situation-pers...

Basically, programmers love complexity.

If they can't solve real problems, they will create fake problems so they can solve them.

They might not realize that's what they're doing.

Programmers love solving puzzles. It's why they program. The problem arises when they can't solve the real puzzle due to lack of experience (and lack of skill which comes from lack of practice), they solve secondary and tertiary puzzles that contribute nothing to the real problem at hand.

Instead of "How can I write 1000 lines of code to solve this problem?" they opt for "how can I configure these 20 libraries and glue them together so that a solution to the problem emerges from their interaction?"

People who don't see the existing solutions as overly complex are content to stay at their current level and have no vision of solving bigger more difficult problems. They think they are already working at or near the peak of human possibility.

> "How can I write 1000 lines of code to solve this problem?"

I opt for "Why are these libraries so complicated? I'll research all 20 libraries and take the parts I like and build a newer, simpler framework."

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

What we need to do is not that complicated but making it so distracts from understanding the harder problem at hand while appearing to be working furiously.

The intelligence is in the end result of the engineering, but no one wants their work to be so simple it could have been done by a junior.

A few answers already but let me add one: Complex technologies favour seniors who are capable of understanding the complexity, over juniors who might struggle more. And it's seniors who make the decisions on what technology to use, so I think it's "rational" if they (even subconsciously) make choices which benefit them. They don't want to get replaced by cheaper juniors.

You can also learn to leave work at work. Keep your side projects simple, if you have any. And rest easy knowing that at work the efforts of one person, you, create enough maintenance work for two people; enjoy that job security.

1. New Tools, in the modern era means Promotion, VCs, Money, Prestige. personal branding.

2. Creating complexity, in the name of needs for these Big Tech is a great way to create a moat for themselves.

3. Ideology, web development is possibly the 2nd worst places if it wasn't for Rust evangelism strike force. The idea that every single god damn thing should be in Javascript or SPA.

4. The Act of design before coding is gone. Especially in the era of Web Development. Lead by Google and Facebook which later spread across Silicon Valley and later across the world. An Act which is even seen as evil or forbidden.

The answer to that question has been the same as long as I've been using react. Represent most of your app logic in pure functions. This has been the React team's recommendation, pretty much since the beginning.

Once you get hit to the idea of making everything a function, it pays to learn some functional programming design patterns. This increases your vocabulary for abstracting your application logic into a function.

Once almost everything lives in functions, your react components should really only care about managing the view.

We humans are creative creatures. When we are doing the same thing for a long time, we tend to get bored and make change happen. We 'improve' things, we move things about. We 'make things better'. So we are not bored anymore.

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

Every single answer goes straight to name dropping various specific techs/tools and I don’t doubt it really is the most simple way for each poster. But I think a much better answer, would be a bunch of questions that dig into what kind of problem you are trying to solve, what are the circumstances, skillset, limitations, budget, is it 1 tiny private app for fun or a couple of apps your team or even company depends on etc.

Because it depends on the specifics in _your_ situation and jumping straight to _a_ solution, without understanding _your_ problem, is imho part of the over-complexity-problem in our industry.

Here is my suggestion for keeping it simple, by solely relying on skills you will need anyways: git and shell scripting.

- Write a shell script that executes all those commands you would run manually to set up your system.

- Put up a git repository in the `/` directory, `.gitignore` everything by default, and explicitly git-notignore all those configuration files and user files/maintenance scripts which are relevant for your environment. Use githooks to also track/restore file permissions and ownerships of these tracked files.

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

- packer for images

- terraform for prod infra

- vagrant for local dev

- pssh for ci/cd and config management

And in some cases I would say they'd be far more efficient with this setup.

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

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

These teams lack technical leadership that is based on professional experience. This is the sort of lesson that is acquired after at least 10 if not more years of professional work, however the industry tests for algorithmic performance art on whiteboards to select software engineers.

This can seriously limit your earning potential by limiting your career advancement. You are forced to create complexity monsters for promotions at the type companies I've worked at.

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

It caught on because "feature factory" startups used simple frameworks to make an MVP and didn't know shit about RDBMS administration, optimization, or schema planning so when it was schema migration time it was time for things to start breaking. With NoSQL (specifically the "document store" types) you could just keep throwing shit in there whenever you needed it -- magic schema migration! And it was "Web Scale"©!

If data requires reloads or manipulations a side restful api needs to be created along the main endpoint which renders html. But it's fairly straightforward with DRF and the enforced by default apps/models structure of Django.

Until a certain point I find this arrangement enjoyable to work with. Once it stops, it's clear as day that the page should be rewritten from scratch with rendering on client side.

I think stimulus is more like angularJS. But modern angular definitely isn’t.

I moved to writing web-code for personal purposes only. Now, I specialize in other types of technical areas for paycheck purposes (C++, Git, PM support, computer HW maintenance and procurement, similar overly niche technical tasks, etc).

From the top of my head, you'll also need libraries for:

- Background jobs - Validation - Translations/i18n - CSRF and other common security considerations - Testing (and integration testing) tools - Logging - Email sending - File uploads (S3 storage, etc) - Websockets

And then write the glue code to make all of this work seamlessly, document it for others to understand how you made it work together, ensure there are no security holes and battle test it in production.

Saying that Next + Prisma "is Rails for Node" is like saying a moth is an airplane just because both can fly.

The problem with the JS world is they can never coagulate around one solution. Everyone has this insatiable desire to roll their own. Next only works because it leaves out a bunch of stuff.

Instead of the examples/ directory they should build a plugin interface and roll out official integrations with lots of tools. This is the closest we would come to Rails.

So many "Look how easy it is to build a blog with Next.js/Remix/Nuxt.js/Whatever", and it is true. That's really easy and cool and has a really good DX and we all love it.

But in real life you need a ton more things to make things robust and secure. And when people start to patch together stuff to get, let's say, authorization or authentication, into their apps, is when things go wrong and you end up getting emails of "data breaches" from services you signed up to.

Had you used a battle proven full stack framework, 90% of the problems would have been solved in standard, well documented, secure and proven ways.

In the node ecosystem, the opportunities are right there. From what I've seen and tried, Adonis.js is the best thing that has happened in this regard. A real "full stack" framework following Laravel's ideas. It's opinionated, fully featured and well integrated as every feature works nicely with each other. And you're not handed over 40 decisions to make about the ORM, the templating system or how to do permissions. It's all there ready and documented. As with Laravel or Rails.

We just need to have people understand that there's a *very common* set of features every single non-trivial web application needs and that it makes no sense to rewrite it from scratch on every single project.

What scares me the most is all of those people saying that implementing all of this themselves or by tying together 10s of libraries every single time is easy. To me they just don't know what they're doing and what they're getting into.

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

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

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

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

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

Just imagine for a second we were to start from scratch. Imagine an HTML/CSS Spec thats easy enough to implement so that we have multiple independent vendors with competing, correct implementations. Imagine something like web assembly as the basis for scripting those HTML/CSS Engines. Imagine the amount of energy, developer time and bugs we could save with a sane, modern standard that implements all the lessons learned from what came before...

One can dream...

https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

Like take this for example: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

Did we just give up on using semantic elements? People barely know how to write regular HTML anymore, and the ARIA spec is confusing. I'm glad it exists, but to me it fits into the same category as "Web components" - a bad idea that isn't widely adopted because it sucks.

2. It's positioned specifically as being for accessibility. This is bad for several reasons. First, it's not necessary. The entire goal of semantic markup in the first place was to make it so that the content of documents can be read by machines (both screen readers and other systems) - tacking on a special system just for accessibility is basically them giving up on this entirely. Secondly, a lot of people don't care about accessibility. Like I said, in our current system people barely know how to write HTML. Or they write some bastardized version of it in JSX or w/e. You think they're going to learn the intricacies of ARIA? No.

The goal should be for HTML to be a language that when written properly is accessible by default. Not just "hey everybody it's cool if you use divs for everything, just make sure screen readers know what it's supposed to be."

So the unfortunate reality is that any well-intentioned attempt to reform them would be used instead to reshape them for corporate interests, with no guarantee that we even end up with better specs from a developer point of view. The incentives lay in the direction of guaranteeing corporate interests, with users losing more of their freedom to choose how they access and use the Web; the developer concerns will at best be used as a PR front for the press headlines.

And the follow up question, which is pointed, is: if your proposed solution would look similar to current JS solution X, why would it be better than X? Is the goal removing the build process? Increasing uniformity across the ecosystem?

>Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers?

The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does.

I think under the hood, the people who actually write the DOM apis would know how to do that in the most performant way possible. I know any native approach would certainly be faster than a Javascript framework. To me the more important part is getting the API surface right.

That's the big problem with a lot of these standards updates. They kind of half assedly add a feature that's inconvenient and then nobody uses it. They need to think more like "How can we incentivize people to drop X framework and do it natively?"

>if your proposed solution would look similar to current JS solution X, why would it be better than X?

It'd almost certainly be faster being built into the native code, but yes the goal is to remove the build process and tooling. But also to bring things back into balance. Right now, most web apps are a big bundle of JavaScript. But with these changes, it'd be several HTML files, JS files, CSS files. In balance again. Each technology has its own place. I think the average skillset of front-end developers would improve massively if they didn't have to do stuff like chase down NPM problems or debug Webpack.

Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables. To be fair, that might already be a substantial proportion of all web UI development.

But the kind of data binding you’re talking about wouldn’t help at all with implementing a word processor, an FPS game or a data-heavy app built around interactive visualisations. A foundation where UIs are built from simple pieces of DOM derived directly from corresponding variables in JS would severely restrict what we could build on top.

We will always need JS frameworks. It's where some of our best ideas have come from. I just think it's time that some of the most successful ideas make it into the standards.

That would be a very admirable and IMO sufficient goal. Being able to do "modern forms" with "native" capabilities seems fairly reasonable.

The word processor, fps, data heavy requirements are IMO being taken care of by WebAssembly, which is a more appropriate technology for those sorts of things than the DOM is anyway.

> they didn't have to do stuff like chase down NPM problems or debug Webpack.

The ship has well and truly sailed on that one. Building a reactivity framework into the browser isn't going to solve dependency management or transpiling.

But I wonder if ESM is going to change this game a bit. Now that dependencies are statically analysable in the page source, a CloudFlare or similar could sit between the "source" and the browser and do intelligent caching and bundling transparently.

Not sure what this means exactly

> 2. Update the DOM api to allow data binding/state and improve the Web APIs around routing/history to make SPAs even easier.

Something like AlpineJS built-in?

> 3. Update the HTML spec to allow for semantically describing user interface elements of software applications.

ARIA roles kind of already do this.

The same thing happens in all of comp-sci: we create a new programming language that compiles to an old language (C to Assembly) because changing the old one takes longer than inventing a new one.

They all implement these concepts in Javascript. But if we don't standardize and allow browser vendors to implement at a lower level, we will always be taking a speed hit and on the framework treadmill. We need to take what we know works and do it.

TypeScript has been very useful and successful but it hasn't touched the UI stuff.

We need a better alternative to HTML and CSS. With WASM any language can now be compiled to run in the browser, and it's a matter of time until WASM integrates with the DOM as well.

This isn't web specific. Desktop UI APIs change frequently too. UI is hard, and only higher level of abstractions can simplify things.

That's my point. The main thing that JSX does is address that you can't do conditional rendering or interpolation with HTML. It's the same with literally all of these other templating languages. Blade, Jade, Handlebars, Mustache, the list goes on and on. Typescript literally exists to address a deficiency in JS.

I don't think reinventing the wheel is the answer - it should taking these clear improvements and adding them to the core product. A big part of why technologies become popular is because of how accessible they are to newer or less knowledgable developers. I don't think some new idea would work, we should work with what's already there. I don't think there's any fundamental flaw in HTML, CSS or JS that necessitates a complete replacement. Just adjustments.

HTML's purpose is to semantically describe content. I don't see how that is at odds with describing the user interface for software vs. a web page.

CSS can lay things out great. It used to be a pain, but flexbox/grids have made it easy now.

JS is the most popular language in the world. If we added a "types" mode that just adds the typescript syntax and lets you set a flag for it, it'd be even better. We don't need a new programming language for people to learn.

See, that's where we differ. I think HTML and CSS are great. They just need to be improved.

>This isn't web specific. Desktop UI APIs change frequently too. UI is hard, and only higher level of abstractions can simplify things.

Yeah, and if you look at the popularity of electron apps it's pretty clear that people prefer doing this stuff in HTML/CSS/JS, even with all the hacks than trying to learn platform specific stuff. I'm arguing with tweaks, we could do it AND have it be performant and not a pain in the ass.

HTML was meant for hyperlinked documents. It may be ok for that, but it's inappropriate for apps. Who cares about semantic meanings of DOM nodes in an app?

I don't think people prefer web dev to desktop dev, but really there's no choice if you need to support multiple OSes. Swift UI is a much more consistent development experience for example. Visual Basic was that for Windows. But cross platform? The only real target there is Skia.

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/

The benefits react provides in functionality (page transitions and controls) could have been better addressed within web browsers, but the process of web design is constantly trying to resolve front end issues in code to suit a wide variety of OS versions and browsers, which is where a big problem lies...

i don't have the answers myself, but this urge to use tons of different libraries, langs, services, and tools just to build web apps, and then the never ending cycle of updating things daily to maintain stability and security may make people money, but it's really not sustainable in the long run. This is why most sites are beginning to be run on platforms like WIX and sharepoint, while independent developers and small app companies go broke. There is just too much damn complexity gumming up everything.

Basecamp has been around for ~20 years. I have a lot of confidence that it'll be around and supported because it's a substantial part of the stack involved with a real world application that is their primary business. It's also from a group of folks who have an impeccable track record for supporting the tools they use.

I use it to replace almost all "api" calls to the backend and for the "turbolinks like" navigation, modals, etc. Then I use Alpinejs for the really interactive/complex parts.

I'm not doing a React/SPA ever again if I have any chance to decide on that.

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

Edit: I once spent/wasted almost 2 years of my life trying to develop the ultimate ORM. In the end I replaced it for a simple directory structure of API end points where every .php file does a specific job with good old SQL queries in there.

Also working with databases with thousands of tables and relationships, hundreds of developers, weekly database schema updates, etc..

We still use raw SQL, stored procedures, jobs, profiling to understand current db hotspots, etc.. ORMs have their time and place just as everything else.

Not to mention that static typing which is going to ensure your query is valid when the code compiles, no typos. Plus maintainability of finding all references of tables/fields. Plus the ability to quicky refactor all of that. Plus mapping to DTOs.

I didn't even get into entity tracking which is a whole other heavily used huge use case for an ORM.

I feel like someone debating the merits of Typescript 10 years ago. Raw SQL is a mess to maintain for the same reasons.

  var results = db.myTable
    .where(x => x.value > 6)
    .where(mySpecialConditionalLogicFunction)
    .select(x => { 
      thing = x.relation.relation.relation.value, 
      thingList2 = x.relation.relations
        .groupby(y => y.value)
        .select(g => g.count)
        .orderby(y => y.value)
        .take(5),
      thing3 = x.relations
        .where(z => z.relation1.value < z.relation2.value)
        .select(z => z.relation.value)
        .max(),
      thing4 = myReusableSelectDTOfunction,
      etc..

However the code you pasted is horrible and easily replaced by sql. Not only does someone else need to learn your custom logic functions and dtos but they also need to read stuff like “ x.relation.relation.relation.value”. I see your point in regards to dtos “automagically” updating queries, but if you have queries laying around everywhere thats another code smell. Basically, this is solving artificial problems.

The code you pasted can be replaced by a trivial query, which should table columns be renamed (i mean whats the frequency of that anyway, potentially another code smell), it would take less to update than updating all the dtos custom functions and the sausage code.

Edit: i am not belittling you, my point is that the code above solves self inflicted issues that could be written in a basic sql query with bound params. Basically you spend twice as much to write and maintain code that is simply not necessary.

The SQL would be

  select w.value
  from x
  join y on y.relation=x.relation
  join z on z.relation=y.relation
  join w on w.relation=z.relation

In addition compiling will validate the ORM code generates valid SQL. On the other hand compiling will not validate a SQL string.

'Custom functions' are just larger versions of the anonymous functions in my example. Very easy for other developers to go to the reference and understand.

Either way what you are describing sounds like instead of maintaining sql code you prefer maintaining orm code. DTOs are just overhead.

I gave up on all these after 15 years of using them because the benefits are precisely zero (except for migrations). Similarly with typescript, if you are competent enough with js and as a programmer you dont need it. The web can overkill itself perfectly fine without a scripted language that transpiles to a scripted language.

Perhaps its just me, i rarely make typos and when i do the linter or ide catches them early on. In highschool they made us keep track of variables and their types with pen and paper and as a result i always know what type my var is. I was also taught that just because you can it doesnt mean you should. So i dont write a dto for transferring an object to a different api. It’s just a waste of time, specific to PHP devs.

Edit: the type of code you pasted is horrible to maintain. You can achieve that with less sql.

You should never rule out a tool as 'unnecessary' even if you can't think of any possible reason for it. Try to keep an open mind here, you may not know everything.

I do recommend reflecting on things as not knowing everything goes both ways.

Of course i wrote in large teams, thats why i know that a large codebase with hundreds of people working on it is usually a sign of either bad practice (the monolith that grew too much) or high turnover (php work places are often toxic and filled by mediocrity).

Instead of ignoring my advice on maintainability, consider breaking your code into smaller chunks and write less code that doesnt solve self inflicted issues (ie your complex queries across hundreds of tables, dtos that dont solve much, custom functions for stuff that can already be done in sql). Once you do the above you wont need all of the overhead you describe and so specific to php.

My code usually lasts a good number of years, often even after i’m no longer working on it. It’s difficult to break and easy to maintain. At least thats the feedback i get from repeat clients. The teams i lead have easily delivered code that generates returns in the billions. All without the mess you describe.

I think we’d need to know a lot more about each other’s projects and experiences to continue as this debate has become a bunch of generalizations.

You can deliver business value with boring glue code.

Edit: wait smarty still a thing!?

Edit: oh yeah Smarty is still a thing and so is PHPClasses.org whilst I think about it.. I've nothing against PHPClasses apart from it tries to pass itself off as something other than it is.. an amateur coders exchange.

Also what you just said is widely applicable - by your thinking, all programming languages are "a waste of time" and an excuse to not learn how to write binary files/machine code by hand?

Also, it doesn't have to be black and white - ORM or no ORM. No one is forcing you to choose between using an ORM for all of your persistence or not using an ORM for anything. It is continuous - you can use ORMs for a *proportion" of persistence logic.

Few more points, but I think the drift is caught.

The sad state of the php world is that there is no other option but to use it. If something is on fashion then it _must_ be adopted. Writing your own is considered insanity and so is taking a different path than the mass, regardless of for good reason or not.

Magic quotes is of course very different from an ORM doing the application-specific encoding. It’s just very worrying when people don’t know which layer of the stack sanitizes for them.

For those of you young enough to not have witnessed php. Magic quotes used to be a popular configuration option that would sanitize all GET and POST inputs to make it safe to use in sql. Needless to say, it didn’t work and instead corrupts user data that is not intended to go through sql.

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

there are two types of roles in modern web dev:

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

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

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

2010 edit an html button:

1. pull the file from ftp or sourcesafe/svn

2. edit the button

3. upload to ftp

2020 edit an html button:

1. install git

2. install npm, node

3. clone and install the code

4. deal with myriad node js errors

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

6. start local environment

6.1 local requires docker

6.2 install docker

6.3 try to start docker

7. docker requires sudo

8. request sudo from IT

9. fill a form explaining why you need sudo

10. install docker

11. start the local environment

12. edit the html button

13. local server not refreshing

14. fix local tooling issues

15. commit changes

16. your changes are 10 commits behind the branch

17. try to merge automatically, cannot be merged

18. make a PR

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

20. go back to step 6

Old software sucked a lot, and automation sucked a lot. Weird issues where you HAD to know what went wrong, because handholding was looked down upon. The lack of automation meant that servers were pets, you looked after them, groomed them, maybe even sang a song to get the piece of junk going. Modern automation means you mostly care about the blueprint, not the actual instance. If it's not working properly, you reimage. If you need more, fire up more instances.

Also, what can you do on the frontend only? I have two examples from the top of my head:

https://www.photopea.com/

https://simplepdf.eu/

Getting back to the point, my simplepdf.eu example is indeed using React - according to Builtwith, it's built with Next.js, which is used to build React applications.

If you work for a company that doesn't give you Sudo on your own machine as a developer by default, find a new job

Don't work for companies that still treat their professionals like children.

If your employer won't give you the tools you need to do your job you should find another one. If your IT/security department is there to block you instead of help you get work done, you should also find a new job. I'm not saying walk out the door today, just that you don't deserve to be treated like that.

2010 edit an html button:

0. Install an ftp client (you need to mention that if you mention installing git)

1. pull the file from ftp or sourcesafe/svn

2. edit the button

3. upload to ftp

2020 edit an html button:

1. clone the code 2. edit the html button 3. commit changes

obviously sarcastic. most of the things you are complaining about bring to mind a person who is bored of doing responsible coding.

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

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

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

Not really related to the above but I learned React when I started my current job and I hated and did not understand it when I first started https://cmdcolin.github.io/posts/2020-07-04. Now it has changed my thinking entirely, and I think react is very powerful. Not without awkwardness and whatnot, but it's better than spaghetti jQuery era

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

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

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

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

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

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

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

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

- No compiling,

- no middleware,

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

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

- the documentation is fantastic,

- it’s extremely fast, and

- no surprises because it’s tried and true.

PHP is so under appreciated.

- mostly backwards compatible with easy upgrades, even between major versions

- many new features all the time for better static analysis, type safety, speed, succinct code, etc

- designed for use with Web

- PHP itself is a (good) templating langue, so no need to reinvent the wheel there

- FFI interface for integrating native code

- easy to learn

Some downsides though:

- Single threaded with typically blocking I/O and no built-in async paradigm means it’s like 1/1000 as fast as something like node for I/O heavy applications, even when using something like ReactPHP

- Need something like FPM to fire up one whole process per visitor

- Many core language features like OOP, type hints, lambdas, etc are a bolted-on afterthought and still only 60-90% there

- Still no typed resource handles until PHP 9+

- Syntax is cumbersome in many ways, though improving

You know why there are amateurs? Because it's simple, understandable, maintainable, low barrier of entry.

You know what amateurs do with simple things and time? Become professionals. Then they solve other people's problems, rather than solve never-ending developer problems we create ourselves.

Having done PHP development for +12 years, I have never once had a debate about getters and setters. Nor did I know that was something to even debate about.

There are elites among php, you may be one of them, but having interviewed hundreds believe me the quality is very very low.

The good client side rendered js frameworks, react/svelte/vue have SSR solutions, but they also have their own servers for enabling SSR - next.js and sveltekit. So if you need SSR, SEO, good client side interactivity - you might as well as used those pre-packaged servers. You also have the added benefit of working in a single language across the stack. Laravel's front end recommendations aren't great - https://laravel.com/docs/9.x/frontend

I do like how react packages html/css/js as components and that you get static typing across the typescript to html bindings which makes the code more maintainable. Also react has a pretty good front end component library with MUI. You kind of have to 'kitchen sink' the front end libraries with PHP as there's no compiler to weed out the ones you're not using - plus you need to use a CSS library, and 'bring your own javascript' to utilize them with where MUI includes everything wrapped as components already.

Interested in others thoughts on this.

One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development.

I like next because I don’t want to build a SPA, I want multiple pages that are rendered server side - for the SEO benefits.

I think you're mixing different things here. Not liking Alpine because you don't like the components is like not liking React because you don't like some component library for it.

Alpine per se is a perfectly standalone library. I use it for my projects and I do not use their components library. Same I use React and don't use MUI either on some projects.

> Also the repo activity of next/react/MUI is much higher than PHP/alpine.

If the project is well maintained, widely used, documented and has no evident unsolved/ignored bugs... isn't this a feature? Why do we need things to constantly change?

> One thing you want to do is try to choose a stack with the best chance of not leaving you stranded in few years. Also a good set of components so I’m not stitching together random packages that may or may not be under active development.

I've worked for companies that, even using popular tools, ended up stranded. One of then with a Vue 2 project which they already "declared" they'd never move to Vue 3 because of all the third party dependencies and own code they had. Same at another job with Python 2/3. So choosing popular libraries, while safer, it's not always safe.

On the other hand, when you choose React (or any other "SPA" heavy tool) you will also need to decide on 10s of other libraries. From state management, to routing, maybe a meta-framework, a validation library, an ORM or data access library, some other for doing maybe background jobs, another for translations, another for graphql or your rest API, etc, etc, etc. Any of those can go unmaintained and cause big headaches.

I highly doubt anything such as Rails, Laravel or Django will go unmaintained and leave you stranded. Alpine.js doesn't look like it is going away any time soon as it is already pretty popular. Would love to say the same thing about Adonis, but I don't know many people using it yet, although I have big hopes for it. Unpoly, HTMX, etc... are more valuable by their ideas and ideology that by their implementation imho. They're small enough like to maintain it yourself or write your own implementation in a worst case scenario.

Same with ORM and state management - sequelize and redux seem to be the most active and compatible with next.

I had the same experience being stranded with AngularJS. You never know what will be abandoned next, you can only make choices to help minimize that chance.

Ehh, what? Sessions are state.

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

Except when I have to set-up php-fpm, opcache and configure countless parameters in php.ini.

> - the documentation is fantastic,

Yes, but I still have to check it for useless constructs like "mysql_real_escape_string" vs "mysql_escape_string" which should have never existed in the first place.

PHP didn't earn its reputation without a reason. But I'm glad to hear that certain things are improving.

Is database state?

> php-fpm, opcache

Nope

> countless parameters

Certainly not

> "mysql_real_escape_string" vs "mysql_escape_string"

There are only a handful of these, and you can learn about them with a simple google search.

Duh. I'm talking specifically about session_*. This data isn't magically stored in the air and if you use more than a single machine, you need to implement the SessionHandlerInterface with a solution like redis or memcached in a clustered setup. That's literally the same as using any other language, plus such map-reduce kv stores.

Since you mention that I wouldn't need php-fpm and opcache, I assume that you haven't worked at scale with php. php might be a good fit as long as you don't have any users, but this isn't true for everyone.

I'm curious, what do you think the OP meant when they said "stateless"?

> I assume that you haven't worked at scale with php

Oh I have actually! But I'm curious, how many sites do you think have a high enough scale to need php-fpm and opcache?

Any kind of user session where user information is stored for access across multiple pages. When you use $_SESSION and write a variable into it, the content is persisted on the server and the user gets a cookie with an ID which points to their session variables. This is state that needs to be shared across servers when want you scale out.

The opposite would be e.g. an jwt, where the state is stored in the token.

Personally I store a token in in my own cookie and then read from whatever storage. No need to correctly implement SessionHandlerInterface (which can be tricky to get right)

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

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

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

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

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

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

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

I didn't see any forms libraries either, so the forms situation seems even more primitive. I'm the author of iommi so I now have very high level abstractions for forms/tables/menus/etc, and a transparent way to compose these. I would hate to start over from scratch...

Am I just missing some libraries?

It’s a lot like Rails in that regard, where you have to model the data yourself. But it’s a part of the job — and it teaches you take advantage of the DB in ways that Django can’t.

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

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

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

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

Every time I read things like this I wonder if most people here are just building landing pages or side projects.

I've literally always had need for validations, background jobs, translations, authentication, authorization, migrations, orm/data libraries, CLI commands for maintenance tasks, etc, etc. "Just next.js and express" or "just next.js and prisma" is still missing a TON of stuff for me. Of course you can npm install 3000 other packages to achieve all of this, but that's a lot of work to get it right, documented, secured and battle proven.

> I just write React code and it automatically shows up on the page.

I just write HTML in a file and it shows up on the page. My solution is simpler, isn't it?

Sure, I was simplifying to make a point, of course I use all of those. My main point however was that there are defined, standardized solutions for all of those. It's not like there's that much churn in authentication libraries for example, most people would use Passport or just JWT.

> but that's a lot of work to get it right, documented, secured and battle proven.

It's really not, because again, solutions are pretty standardized.

Really? I have never seen two Next.js projects, open source or not, which use the same subset of libraries. Most don't even share the same "approach" to communication with the backend. Some use GraphQL, some other just API routes, other's proxy to another backend, other trpc, others firebase like solutions, etc... And none of them would qualify as "simple" to anyone else than the person that built it. Even more, no two single projects share the same structure or code organization.

> It's really not, because again, solutions are pretty standardized.

Tying together all of those solutions and guarantee you're not creating security holes in doing so, documenting it for others and making it robust and battle proven is complex for almost everyone, maybe not for you if you're top 1%, granted. I'd love to hear about those standard solutions you mention, because as I said above, those standard solutions are different for everyone. And I've seen tons of wasted time and effort in discussing what's the "standard solution" to use. From people discussing if they should do validations with yup or express-validator or joi to discussing if they prefer prisma or knex to entire weeks debating if migrating to GraphQL would be better.... tons of time and company money wasted.

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

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

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

I don’t even like JSX. I always pass an object in like: ‘<Foo {…fooProps} />’. Would much rather just use a literal js object.

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

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

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

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

Electrician

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

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

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

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

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

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

</two-cents>

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

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

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

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

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

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

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

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

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

Food for thought, you might be better off without.

All no-framework-needed examples seem to boil down to having a simple enough problem needing just one (or few) front end developers. Would be good to hear how a larger team (say 10+) managed without one.

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

* "Optimized for Programmer Happiness"

* The Principle of Least Surprise

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It's intrinsically complex, deal with it.

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

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

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

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

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

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

Still in use, still killing it.

The problem I find with Django is that it's a purely backend framework. The moment you want to use their highly outdated templating system it becomes evident it's from the 00s. It doesn't even handle assets bundling.

Laravel and Rails instead can be considered more "full stack" solutions, as both have really nice frontend stories too.

But Django is great if you want to build a backoffice with the Admin and django-rest-framework. That's how we used it back in the day anyways.

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

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

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

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

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

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

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

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

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

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

With that in mind, my advice would be:

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

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

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

For one, we had to rewrite the app 3 times because the library switched from Less, to 2 different css-in-js solutions across 3 different major versions.

Then we switched to server side rendering and suffered some weird glitches. Turns out, when using SSR, styles get rendered twice: once on the server and once in the browser. So you have to write a custom logic to remove the styles that are rendered on the server.

What I'm trying to say is that React was invented at Facebook to solve problems they were having but the industry was too quick to adopt it as a solution for their own problems. Facebook can afford to rewrite a piece of software 100 times because of their unlimited budget. They can also deal with all the bs that comes with frontend frameworks because of their ability to throw an unlimited amount of engineers at a problem.

Small company with 10 engineers? Just use something appropriate for problems you're trying to solve at your budget.