[keyle]

Until React can cross compile in Rust and spawn a browser instance in WASM with a graphql interface, I will keep making sarcastic jokes about React. /s

I started as a front-end dev, focused on that in the 2000s as this was where the work was interesting...

Now I go by back-end dev, because I just can't deal with the front-end "industry" anymore.

All the best, though.

[postalrat]

If you think the front-end is a mess just wait to till you see the layers upon layers of complexity people are using the manage back-end services.

[qudat]

Totally agree. All of these arguments claiming the FE is too complex need a reality check with the real monster: https://landscape.cncf.io/

[0xpgm]

Most of these are optional, one can stay with a very simple stack similar the LAMP stack i.e. a web server, a database and a backend language on Linux for small to mid-sized apps. And pick something simple for CI/CD.

Of course if you are into enterprise or 'web scale', things can get a bit more complicated, but it's how complicated you make it to be.

[MrJohz]

And of course, much the same thing is true for the frontend as well. Most of the time, the worst takes off frontend excess or backend complexity are being told by people who aren't working in field, and just looking in from outside.

Rendering everything on the server and adding a bit of Javascript along the way works - it had its flaws, but so does everything else, you just need to figure out which flaws make sense for you to deal with. For a little extra complexity, use Vite as a bundler, and add a framework - Vue is pretty simple to get started with - and you're almost immediately away. You even get some stuff like Typescript for free at this point.

And like you say, you can make things more complicated with various other tools, but if you need that, you probably know you need that, and you know what it's doing and why it's necessary complexity.

[zelphirkalt]

As soon as you add TS to the mix, you have to deal with TS compiler not being able to output run-ready JS (or has that changed by now?), because of JS issues with modules and you need a "bundler", yet another accidental complexity, and one that is often a nightmare to configure. Then some drive-by person will want you to minify all the things and you add another unnecessary complexity.

TS is great mostly. But it definitely comes at a cost.

[MrJohz]

I think the situation with TS has improved, but yes, I only really use it with a bundler where that isn't an issue - in this case, Vite. But typically Vite does most of the things you'll need out of the box, and I find I rarely need to think about it, so it's the sort of complexity I'm mostly happy to take on.

[throwaway290]

Don't forget that you don't need any bundlers and frameworks if you just want some reactivity, React is very minimal and works in pure JS, just alias createElement to something like el() and off you go

[MrJohz]

I'm not quite sure I'd go as far as calling React minimal, but yeah, there are definitely fairly light options here. Mithril is pretty classic as a "bare minimum framework" option. Vue can be used without any bundling/compilation steps as well, although I think that's less supported these days. I also quite like SolidJS - again, they encourage you to use the compiler, but you can also just use it with template literal strings and it should work just fine.

[herewulf]

I had a problem and got TypeScript for free. Now I solve my many problems with "any" problems.

[keyle]

Oh my.

[krowek]

Would you mind giving one or two examples?

[synergy20]

the SSR first trend for SPAs finally pushed me away from React(along with Vue,etc). I'm an embedded developer, I can not run node.js on the target, even MVC on the server(i.e. target board) in C or Lua could be too heavy, so SPA with restful was the best option, now all SPAs are turning into SSR-first and making things even more complex, I can no longer justify the time spending chasing the modern frontend any more, I need alternatives.

I'm trying nim for SPA at the moment, also thinking about some C based restful approach(civetweb, ulfius)

https://forum.nim-lang.org/t/2926

[robertoandred]

Or you could keep using react the way you always were

[jasongi]

Why would you ditch react because you don’t need SSR? You can still use vanilla React without SSR and serve it statically. It’s not as if you’re forced to use nextjs if you want to use React.

[synergy20]

React used to be fine when next.js was a separate effort, now Vercel hijacked the project, and making things even more complex by mixing SSR and CSR, there is a learning cost associated when things and concepts getting larger unnecessarily.

[text0404]

how has vercel/ssr highjacked react?

at work, our backend is c++ and we use react without nextjs or any ssr. if we don't need it, we don't use it.

[synergy20]

the newest react is now _strongly_ recommending you start a new react project using next.js, vercel hired many of the react developers for its SSR oriented business, etc.

[text0404]

ok, that makes sense (i also don't like the official recommendation to use next).

[winter_blue]

Even a Raspberry Pi Zero that costs $5 retail[0] should be good enough[2] to run modern Linux + a node process running Next.js with SSR.

Why do embedded developers pick really resource-constrained chips, when decently powerful chips that can run Linux have become so cheap?

[1] probably even cheaper if purchasing B2B, in bulk

[2] i.e. should have enough CPU (1 GB) and RAM (512 MB)

[DanielHB]

I work with a frontend app that talks with microcontrollers that have 2mb of ram, they don't run linux and can't even support an HTTP stack. We actually use UDP to send messages to them (through a thin native layer in our app)

I don't remember the exact numbers as I don't work with the manufacturing side but the budget for our microcontrollers was <0.5 USD per microcontroller

> Why do embedded developers pick really resource-constrained chips, when decently powerful chips that can run Linux have become so cheap?

1) Often you have multiple microcontrollers per device

2) It just follows a general trend with industrial manufacturing of always trying to find ways to cut costs. It is not just microcontrollers, after a product is finished, v2 will always strive to cut costs and be cheaper. Components costs grow linearly with production volume. If you sell a million of devices with a 5 USD chip that is 5 million dollars that could have been spent on R&D (maybe like 5 devs working on it full time for a year)

3) Sometimes the microcontrollers are dedicated for security/safety, those you don't want to run linux on because it makes them harder to QA and certify (non determinism doesn't play well with safety). You want them small, lean and as simple/dumb as possible

4) Sourcing problems, advanced chips are harder to source in higher quantities, especially lately. Crappy microcontrollers can be bought like buying legos at the lego store

5) Size, reliability and heat constraints. Bigger chips are harder to integrate into a custom board, require more power and could generate enough heat to cause problems. Integrating a Raspberry CM requires a custom connector with like 50 wires or so and wiring it can be really annoying/error-prone

One of our systems had a Raspberry CM3 before, it was the first thing on the chopping block for the v2. Apparently it was the most expensive single electronic component of the whole system.

[matthews2]

> Why do embedded developers pick really resource-constrained chips, when decently powerful chips that can run Linux have become so cheap?

There are other things to consider, like power consumption, size, reliability, IO... It's a totally different class of hardware.

[rk06]

But vue is SPA only. And Has No Direct relation to SSR framework

[synergy20]

true, the only one remains sane so far, but I'm unsure how long that will last, I lost confidence in frontend as far as keeping-getting-unnecessarily-more-complex is concerned

[work_hard93]

Sometimes I too find getting things out of hand. I have been working as a frontend dev for the last 5 years now , tbh sometimes there are pointless discussions over the app architecture

for 90% of the cases it is simple React SPA app + REST APIs , thats it and then people try to put SSR there and what not which tbh is not required even from a business pov.

It takes the joy out of things.

Although i hear folks say the same about backend , but honestly i have not done backend so cant comment about that,

planning to move though

[paulddraper]

> can cross compile in Rust

what does that mean

[culi]

No one knows what it means, but it's provocative

[alluro2]

It gets the people going!

[m0llusk]

Selling is all about having and sharing a vision.

[keyle]

Well it's simple. Imagine a cross runner, then give him a 180K yearly package. He'd only have to bridge the distance between React and rustc, which is clearly 4 (s/ea/us/t|c)^42.