Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

681–690 of 756 posts

Re: If not React, then what?

#681

Post by Izkata »

ksec wrote: post #545
afavour wrote: post #228

Earlier quoted context omitted.

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…

>it’s all prioritisation of developer experience over user experience. And I have been saying this for well over a decade. Hopefully it catches on. I have always asked for example of sites done in React where I couldn't tell it is done in React or other JS Front End. The "at worst, hundreds of milliseconds" is precisely why Web Apps never felt as good as native apps. And if we collectively cant make web apps good, wh…

> why does liking a tweet re-render the entire screen?

They're probably using Redux, which has been the go-to for state management in React for nearly a decade. I've always been averse to it because it's implemented using contexts and triggers those full re-renders - it was designed during the class-based components era and relied on people actually implementing shouldComponentUpdate(), which isn't really a thing with modern function-based components.

If they were using modern hook-based state management like Zustand or Valtio, full rerenders wouldn't happen.

Re: If not React, then what?

#682

Post by leptons »

peutetre wrote: post #617
leptons wrote: post #534

Earlier quoted context omitted.

Yes, let's save the electrons so we can mine bitcoin with them. /s oh, oh, wait - I have an idea! Let's just write everything in 8-bit assembly language, that will let us really optimize and save all the electrons for bitcoin mining! /s You really are barking up the wrong tree. Going after Javascript as if it's the reason the planet is doomed, or even makes any difference at all in the grand scheme of things, is just…

Some people just have no ambition.

I stopped using semicolons in my code to support your cause. Think of all the power it will save by not switching on a few pixels! We'll save the world! /s

Re: If not React, then what?

#683

Post by quantadev »

baobabKoodaa wrote: post #680
quantadev wrote: post #678

Earlier quoted context omitted.

Every highly experienced developer knows the importance of type-safety. The existence of large numbers of experienced Python developers in the world doesn't disprove that, because it's a statement about their knowledge, not their actions. Python developers simply tolerate the lack of type-safety only because it's a trade-off to get other things the language has to offer. I agree there are trade-off decisions being ma…

This is what you said earlier: > For any large project you need type-safe languages. 99% of experience developers (10+ years of experience) will agree with this opinion. Clearly, more than 1% of experienced developers choose Python, despite it not being a type-safe language.

Yep, great developers know they "need" type-safety, but we don't always have it. Even my own app has a Python Microservice in the docker stack where 100% of my LLM/AI code is contained, simply because I wanted all the latest and greatest AI tooling (especially LangChain). I opted for Python over Java for that microservice, but used various tools to achieve build-time type-safety.

Re: If not React, then what?

#684

Post by hasanhaja »

johnfn wrote: post #327
hasanhaja wrote: post #268

Earlier quoted context omitted.

I urge you to read Alex's Reckoning series. > performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I think outside of the privilege bubble where a significant percentage of the world is in, these concerns are measured in the tens of seconds. > it doesn’t create issues visible to my users What do your users look like? What kind of devices are they on? Is it mostly mobil…

> I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section. I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more. > The TLDR is there isn't a one-size-fits-all. That's what I mean - the author gives no prescription. Saying there is no one-size-fits-…

> That's what I mean - the author gives no prescription.

Are you expecting a prescription? If so, what could that look like? Specific technologies? When specific technologies are appropriate?

> Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF.

I don't quite understand this. A bakeoff is meant to give you space to figure out what technologies are appropriate for the service you're building for your users and taking into consideration what your developers like. It's a collection of proof-of-concepts so it's a quick and lean way to get data on what's more likely to succeed for you. I can accept that the technology doesn't make a product, so focusing PMF is important, but you also don't want to pick something complex that you can't afford to manage as you scale.

The worst thing I see happening is you reach PMF and need to continuing scaling, but you hit a high complexity wall that you can't move past till you manage it. All that unnecessary complexity you took on and didn't invest your already limited resources is now tech debt that's oppressing your forward momentum. Bakeoffs can steer you towards the simplest tool you need to deliver your product so that it can stay out of your way so you can focus on iterating and developing your product.

> The rest of us will use React, which is roughly 80% as good as the optimal solution.

How are you measuring this? A lot of the evidence for using a technology and running with it without managing the complexity turns out badly (see The Reckoning series by Alex). And React is a high complexity tool that requires a lot of continued management investment.

The thing that appeals to me about doing bakeoffs to find the simplest thing for my product is not that it'll be the most optimal; it'll be the cheapest to maintain. The less complexity you have, the less you have to invest in managing it.

> I just don't think many of us are Google or Facebook.

I agree. That's why I think it's best to pick the simplest tools we can afford to manage so we can get on with building our products. Facebook or Bluesky or Airbnb can afford to build their products many times from scratch and they can pay to maintain whatever complexity they take on.

Re: If not React, then what?

#685

Post by hmeh »

eawgewag wrote: post #679
hmeh wrote: post #660

Earlier quoted context omitted.

To be fair, 4 years ago I would have too. The cracks started to show with Phoenix LiveView and turbo and I took a leap of faith on the alternative I describe in my other comments. I haven’t looked back. I’m not sure I would rely on obviousness. Things are only obvious to the late majority after the innovators and early adopters have moved on. The thing to pay attention to is when people who have extensive experience…

I can't speak for other people; I can only speak for myself. I was an early adopter of React (around 0.12) and wasn't particularly interested in, or technical enough, to understand the "cool" things. I wasn't swayed by "hot reloading" or "virtual dom diffing" -- I didn't have a build setup that could hot reload, and I also did not even understand what the virtual dom was. But when I looked at its code samples, React…

Right on. I definitely resonate with the first two. The third is somewhat arguable for me, but I've historically appreciated it and probably did much more when React first came to my attention.

And yes, I ended up falling for React for these reasons and more. When we moved to Rails server rendering, I even experimented with rendering React components from the Rails server. It worked, but the rube-goldberg contraption wasn't worth it.

Instead, we opted for helpers and view partials. The limited behavior we needed on the client would be in a separate Stimulus controller. The helper would typically reference it. Then, the declaration in the view would look more or less like a React component invocation, albeit with a totally different syntax.

There may very well be room for improvement here, but it certainly works "well enough". As I've mentioned, the main thing that is different now is that we can render updates to views on the server. This allows us to have "The ability to express view as a pure function of state" on the server and not have to be concerned about everything else that comes with owning and operating a React implementation.

I think React really helped move things forward and I don't regret my time using it. I may even use it again if I worked on an application where it was warranted.

I wish I could spend time with every commenter on here showing them our code, working with them on it, and helping them see the way that we do it so that my words don't just sound crazy or anathema. Unfortunately, that just doesn't work out in practice. I appreciate the discussion all the same.

Re: If not React, then what?

#686

Post by hasanhaja »

TeaVMFan wrote: post #499

If Java is your cup of tea, you might want to try Flavour. I did and now it's the only frontend framework I use. https://flavour.sourceforge.io/ It lets you write your frontend and backend code in the same language, even sharing models and validation logic so refactorings work full stack. You get strong typing and a rich SPA framework that includes routing, templates, and easy server calls. There's a book ( https://f…

How do you think it compares to Vaadin?

Re: If not React, then what?

#687

Post by eawgewag »

hmeh wrote: post #685
eawgewag wrote: post #679

Earlier quoted context omitted.

I can't speak for other people; I can only speak for myself. I was an early adopter of React (around 0.12) and wasn't particularly interested in, or technical enough, to understand the "cool" things. I wasn't swayed by "hot reloading" or "virtual dom diffing" -- I didn't have a build setup that could hot reload, and I also did not even understand what the virtual dom was. But when I looked at its code samples, React…

Right on. I definitely resonate with the first two. The third is somewhat arguable for me, but I've historically appreciated it and probably did much more when React first came to my attention. And yes, I ended up falling for React for these reasons and more. When we moved to Rails server rendering, I even experimented with rendering React components from the Rails server. It worked, but the rube-goldberg contraption…

I'm definitely a fan of LiveView and Turbo. I think they present reasonable choices for applications that are more complicated than a static site and less complicated than a full application. I would like to see their interop story with React improve, however, since I think a lot of impetus towards React comes from the fact that the core business product, which has high application/interactivity requirements, is (understandably) in React, so the cost of build is significantly lower staying within the ecosystem.

This is actually something I think a lot about, because in my company I am the TL of all the setting pages. We don't have high interactivity requirements, and it's reasonable to explore a different path. But the core product is in React, and there's basically no justification to rebuild it in something else just to build out settings pages.

Re: If not React, then what?

#688

Post by hmeh »

eawgewag wrote: post #687
hmeh wrote: post #685

Earlier quoted context omitted.

Right on. I definitely resonate with the first two. The third is somewhat arguable for me, but I've historically appreciated it and probably did much more when React first came to my attention. And yes, I ended up falling for React for these reasons and more. When we moved to Rails server rendering, I even experimented with rendering React components from the Rails server. It worked, but the rube-goldberg contraption…

I'm definitely a fan of LiveView and Turbo. I think they present reasonable choices for applications that are more complicated than a static site and less complicated than a full application. I would like to see their interop story with React improve, however, since I think a lot of impetus towards React comes from the fact that the core business product, which has high application/interactivity requirements, is (und…

Indeed. I think an important concern is what constitutes a "full application". I think that's where the community (I've even seen this at my own agency) has lost the plot a bit.

> I am the TL of all the setting pages

Ok, now I'm intrigued. If you're interested, I'd love to hear more about this. As someone who has (aside from a 2 year stint at Microsoft) only worked on relatively small teams (15 max) I'd love to hear more about what it's like to work on a team that's responsible for the settings pages. If you're interested, I'd be happy to connect for a chat. I just added my contact info to my profile here. If not, no worries! Cheers.

Re: If not React, then what?

#689

Post by quantadev »

baobabKoodaa wrote: post #665
quantadev wrote: post #469

Earlier quoted context omitted.

I originally typed "seasoned developer" and then I edited it to say decades. Neither one of us has perfect definition of "seasoned developer" in terms of precise years, and it doesn't even matter. But there are some things that are obvious to any seasoned developer and the value of type-safety is one of them. It's not my opinion. Is a fact. And yes if you say you have 10+ yrs and you don't prefer type-safe languages,…

> And yes if you say you have 10+ yrs and you don't prefer type-safe languages, then yes I indeed do not even believe you. You don't believe what exactly? Don't believe I have 10+ yrs of experience? You can see that my GitHub account has activity from the past 10 years, so... you don't believe I prefer dynamic typed languages like Python? You think I actually prefer static typing and I'm lying about that? Like what?…

Sorry, I'm just not buying any of that.

Re: If not React, then what?

#690

Post by t-writescode »

pier25 wrote: post #630
t-writescode wrote: post #140

Earlier quoted context omitted.

What I read from what you said is “Chevy trucks are good? Oh yeah, if trucks are good, why does the post office use non-Chevy, non-truck, fleet cars?” Please help me understand where I misunderstand

"Trucks are bad for X" "No, trucks are good for X" "Look at this use case (Amazon) with tons of objective data that shows that trucks are bad for X"

"Look at this use case (Amazon) with tons of objective data that shows that trucks [do not fit Amazon's use case for X]"
Post reply on HN