[WandaVision]

Unpopular biased opinion.

Frontend development is mostly done by people who are into visual things and less into logic.

Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance.

This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing.

After some time frontend developers will find some new framework with a better landing page and move on to that.

And the cycle repeats.

[tcldr]

> Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance.

Yes. Backend engineering is completely immune to hype and increased complexity.

laughs into a cloud of micro services

But, more seriously, both front and backend architecture has increased in complexity. I think it’s more than condescending to say it’s because front end engineers base their decisions solely on website aesthetics.

A lot has to do with the fact that for a long time JavaScript has been the only game in town, and engineers have had to work hard within the constraints to afford the same programmer ergonomics available within other environments. This has led to a proliferation of tooling and frameworks which are a nightmare to manage.

No one is picking webpack because ‘it make pretty’.

[WandaVision]

Micro service makes perfect sense in a company with large number of teams. Ofcourse it would be stupid to use microservices if you are a small company with a handful number of devs.

[BartjeD]

In my opinion the complexity is caused by the amount and the combination of technical choices, design choices, and process pipeline choices.

... Long story short is that a web app is cross-platform (browser) program and that very quickly gets quite complicated requirements. Of which security, dependency management and frameworks are a big part. Because you need to know about them, and how they work etc..

Long story / ramble:

A simple static website can be as simple as a bit of HTML with CSS.

But when you introduce workflows and users it isn't long before security comes around the corner. And that introduces a lot of complexity, which frameworks and packages help with. (Don't roll your own)

So the security packages comes with typescript. Which makes you adopt typescript and adds a bit of complexity over JS. (But also typesafety! I'm a fan FYI)

And then you want the website work as a progressive web app, so you need a service worker. More complicated.

You then might want to add some sort of isolation of CSS, or use Sass or some other framework. To help with code re-use and avoid breaking things as the app gets larger. Also more complicated.

Then your PO says you need to have async workflows and let the user know when something starts and is done, with push messages. So you need a background worker and push messages.

And we're not even talking about the technical issues, like not all browsers supporting certain API's or certain styles. Or updates to package X breaking package Y, needing a package patch.

Not to mention keeping up with the evolving syntax and language capabilities. HTML, Javascript, Typescript, CSS, SASS etc... They all keep changing and evolving.

[karaterobot]

> Unlike backend engineering, where people working are primarily choosing technology based on logic/merit.

Sometimes I wish I could do the crying-while-laughing emoji on HN.

Backend devs have biases and get tricked into making the wrong choices just like everyone else.

[bobkazamakis]

"obviously the problem your solving doesn't exist, but if it did exist it would because front end requires someone without a complete lack of aesthetics"

[tjansen]

Hmm... in the early days of HTML+CSS, there were a lot of visual people in the field. Some of them wrote some JavaScript, but stopped when things got too complex. These days they are doing UX design or create designs in Figma, and don't really touch code anymore.

[adql]

Many of people that did only frontend (HTML+CSS+JS) also moved to full stack, with usually dreadful results.

From manager POV it's great, they don't need to manage 2 teams and can move people from frontend to backend as needed. and then you end with chmod 777 like in old bad PHP days. But hey we put that in container now!

[lagrange77]

What garbage frameworks are you referring to for example?

The popular ones i know involve a fair amount of logic and real SWE, aiming to free the visual guys from implementing their own garbage code.

[oliwarner]

You're discounting interface work. User experience, etc.

That isn't just making things pretty, but finding the best ways to display data, get input, etc.

[lopkeny12ko]

This reads like a critique written by someone who has never actually worked on frontend. The choice of framework has no bearing on how visually appealing the site looks. It would be silly to posit that a company would, for example, choose to build their site on React primarily because there are a lot of visually appealing websites out there that happen to be built with React.

[chrisco255]

There is a significant chunk of backend devs who subconsciously and consciously avoid the complexity of front end dev and at the same time, snark about the alleged simplicity of it.

[ls15]

Ok, but why aren't companies then firing all frontend developers and instead let backend developers build logic frontends with vanilla HTML/JS/CSS?

[arbitrage]

Because you can't do that with vanilla HTML/JS/CS.

[Cupprum]

Of course you can, but it would be hell when it comes to state management.

[throwaway81523]

In that world we used to handle all the state on the server side.

[fsociety]

> Unlike backend engineering …

Ha you could not be more wrong. Front end is all about velocity and trying to not end up with a ball of mud at the end of the year. State management is where a lot of the complexity and logic exist.

Whereas within backend, our current state of affairs is “oh, need some new functionality? Let us spin up microservice #214 for that one thing”.

This is changing, and across all area’s experienced engineers can avoid these problems, but the thought of front end developers coding with their hearts instead of their minds is a funny one.

[someforget]

IMO a lot businesses could/should be in the business of providing the API and leaving the UX to end users.

Especially dev/ops facing services where I want simple quick answers, not memorization of mouse motion, and click habits.

Services like DataDog, as an example, are inherently dev tools but their frontend is designed to distract and make you feel lost.

If a retro is needed, that’s when the pretty charts and graphs are useful.