This is what you're in for when you go for THE state-of-the-art "React stack". What you see in the screenshot below is the hellofresh.be website (it's the same as .com). It uses Next.js, React, emotion & styled-components (2 CSS-in-JS libraries). It uses 140MB of RAM for a single tab with some product cards and a slider, logs 70 console errors in production, and fails to load 3/4 times on Firefox.

On mobile, opening a meal card to view its recipe literally takes up to 10 seconds (and I have good connection and performant devices) and you can't choose the last meal card because a f*ing overlay hides the "add" button. And this is a global company with millions in revenue.

All this bugginess has already resulted in incorrect or missed deliveries and they're not doing anything about it. F* you Next.js & F* you HelloFresh IT management

Performance-wise that's the same experience you get when you disable adblock on any popular website after a decade of using adblockers.

@Alice yeah but here it's with adblock enabled..

@ostream I whine about it because I can't stand having to work on projects with these nightmare stacks and unfortunately that's most of 'em nowadays. But true, React is definitely not the only culprit (and I suspect even Firefox may be partly to blame).

Pricing-wise it's about 7€ per person, + delivery 7€. So the more meals for the more ppl you buy, the cheaper it becomes per person. Not cheap, but not too expensive either. The time I spend whining on it is definitely compensated by the convenience it brings in automating quality dinners at home :), but their website needs urgent perf optims

@webketje Firefox is fast and without it you would still have IE 6, firefox was the browser that broke the MS monopoly, Google only joined in once FF had proven it could be done.

And both next.js and react are good, but it sounds in this case they went over board and abused them :)

No library or even pure js survives bad design and bad structure.

The programmer of this website is simply bad.. You mustn't blame the tools.

@daniel-wu the programmer is the tool

@ostream These prices are for meals that will be for **2 people minimum** (yes you can't order them with only 1 person's worth of portions) and you get the recipe sheet with instructions.
And like @webketje said, it's cheaper the more meals you get or cheaper per person the more portions you get, and services like HelloFresh are about convenience (where you get all of the ingredients needed at the right portions with instructions delivered to you) and for some people, it exposes you to new meals.

@ostream It certainly isn't practical for single people especially as you have to order at least 3 meals to get them delivered (so 6+ meals per package).

It's pretty handy anyway.

Let's be real, react is antiquated and it should go the way of jQuery. We have much better, much faster (like almost twice as fast), feature complete frameworks now. Vue blows React out of the water in every single possible way, from DX to bundle size and speed. Solid or Inferno use extremely similar notation while being actually smart about what they build. It's just those retarded managers who need to do what everyone else is doing because otherwise their dicks will fall off so it takes a billion years for anything to change.

@ostream I don't know what you smoked or snorted but you seriously need to stop throwing your anger about tools you dislike alongside ad homs to strangers who didn't say anything aggregating to you.

I find it interesting that you even mentioned me in a comment that had nothing to do with what I said.
It's almost like you're trying to out-compete that Andrea Jung guy (or whatever the right spelling was) from a now-defunct social media dev group (which isn't a good look if you want any respect from others in the community).

And stop kidding yourself, you just stated opinions, not the truth. And it's hypocritical of you to talk about hating on tech when you did that yourself.

@ostream So you don't know the difference between shitting on a tool vs shitting on and insulting people who use said/another tool.

And as far as I'm concerned, React, Vue and Angular have their use; some projects are better written in one vs the others (especially depending on someone or their team's knowledge/experience in said tools and all the stuff that goes into picking the right tool for the job).

Are people still fighting over JS libraries?

I'm fighting for keeping it plain and boring. It can't be that React hooks, state-controlled inputs, CSS-in-JS, JSX, MDX, SSR, are the n°1 way to do sth in JS land. Devs coming from other languages using these gadgets mess up all the time. I've not been working with these tools since 2 years, I'm done with the vendor & stack lock-in & dependency issues with the frameworks that provide them.

The idea behind their abstractions is not bad, but their execution is leaky and they incur significant learning, setup, & maintenance costs and they always require you to "buy into the <framework/build-tool> way". Just give me a simple API like esbuild does, or a framework like mithril.js that you fully grasp after 10mins on their docs.

@msdsk react is not going to go away for a long time. Sure there might be more modern or better frameworks BUT for bigger projects stability and continuity is often much more important. Thats one of the reasons react is so popular.

Its been around for a long time, its easy to find developers that can work with it and it works.

Switching frameworks whenever a new and shiny one comes along is a good way to kill any project and dissing react excludes you from a big part of the market, more work and money for the rest of us ;)

@Voxera
Yeah, and that's why jQuery took ages to die despite it being long overdue. And "long term stability" usually means "long term tech debt".

@msdsk yes in a way, but for big projects, switching frameworkscan take months or years and for some, that would be the same as going out of business.

I was there when we transitioned from home grown to jquery and then from jquery to react and while we are looking at new frameworks, a switch would take 3-6 months if we dropped everything else and more if we try to do it in parallel. And that is after all devs have learned the new one good enough to actually be more productive than with react. All in all it would be more like 9-15 months, after which we would take another 6-12 to catch up to where we could have been if we did not switch.

And during that time, the next best might just change again ;)

React is just good enough to not make it worth it right now.

We will most likely use something else for new things, and somewhere along the line we probably will start transitioning the main application.

But forcing it is just not a good thing.

@ostream the ugly of React + JSX is having to write DOM properties instead of attrs in an HTML-like structure (htmlFor, className), having onChange attach to the input event, and feeling the cringe of writing _dangerouslySetInnerHtml.

I like string-based templating (not custom, but the twig/jinja/nunjucks trio + is nice to have it available in 3 languages). But if I switch it would be hyperscript (similar to early react without jsx) or template literals. I guess I just find HTML more tedious to write & look at when it is mingled with application logic.

@webketje I also found the custom properties strange and a hazel in the beginning but once the project grew that quickly became irrelevant since the logic code by far exceeded the template code and react was such an improvement in state management.

In my case we were building web applications, not web sites, so the actual html was less than 10% of the client side code.

I have not checked vue for a few years but I did try it and while it had some benefits, at least back then it lacked the editor support to help with the code structure, and that was a deal breaker in the kind of big applications we wrote.

We had upwards of a few thousand lines of own code in some pages (in library files of cause).

And react was just geared better for that scale.

Today vue might have better support but is it really good enough to justify a rewrite or should we wait for something that runs more on top of webassembly for even more speed?

That is the kind of questions I wrestle with :)

@ostream have at it 😄. The templating langs I mentioned are battle-tested & lightyears ahead of your custom string replacer. They have their use. They bring some overhead but not nearly as much as building virtual dom trees (talking only about templating, not state & events etc) and are not suitable for advanced SPA's, but they're good for scaffolding, server rendering and SSG.

Modern tech ... Compile css in js.... But but but ... Anyway