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

491–500 of 756 posts

Re: If not React, then what?

#491

Post by eastbound »

LegionMammal978 wrote: post #459
leptons wrote: post #405

Earlier quoted context omitted.

API requests at page-load are definitely going to lower the page speed score. No API requests should happen at all, ideally, and all script and CSS to render everything "above the fold" should be loaded in-line. Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. Only the bare-minimum script parsing that is required for the content "above the fold" sho…

> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. On the other extreme, completely deferring any loading of 'below-the-fold' content until it's visible can also have horrendous consequences, if that loading involves downloading any external resources. Not every visitor can just make further requests near-instantly, and it's those RTTs that really s…

I generate a report in our software and 70.000 cells work like a breeze (1000 rows, 70 columns). React just can’t handle adding an input to a cell.

It’s unacceptable. React touts its shadow-dom “because it’s much more efficient than updating the DOM directly”, well, that’s a big lie.

React is better than all predecessors, but it’s still the wrong abstraction.

Re: If not React, then what?

#492

Post by gls2ro »

johnfn wrote: post #486
gnulinux996 wrote: post #368

Earlier quoted context omitted.

> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Try opening facebook.com; click the messenger, (+1 second) Click one of your chat groups (~2 seconds) This is merely just to show something From what I have seen, its quite easy to have performance issues with React

That doesn't say much about React, though. Indeed, you can open the network panel and watch requests go by over the seconds that it takes to open, suggesting that the issue likely resides on the backend.

So the company that invented it does not know how to properly use it?

Or are you implying that React does not fit FB use case?

Re: If not React, then what?

#493

Post by pjerem »

agumonkey wrote: post #326
harrall wrote: post #297

I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…

To me it goes beyond the looks. Angular terminology and semantics were always very alien. React is no angel either, but it seems influenced by older, more tested concepts (FP and such). That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.

I’m going to be the devil’s advocate because I’m from the team "no SPA at all unless you have a real need like real time" but to me, Angular is the less worse when it comes to writing SPAs in teams.

Clumsy and hard to learn ? Sure. The code looking less cool than other frameworks ? Of course. Unbearably slow compiler ? Check.

But at least you got a full fledged, batteries included framework, with a powerful DI system and an established architecture to follow. Not the funniest framework but it works.

The only powerful thing but also big flaw with angular is that they deliberately expose a lot of the framework internals with a very neutral documentation that never explains that you shouldn’t touch this or this in most cases. It allows very nice and clean extensions of the framework but, oh my, if you inherit a codebase from a "smart guy" who knows the framework inside and out and "did better" than the boring angular architecture, then good luck.

I know this can happen in any codebase and I’ve seen it everywhere but Angular exposes so much things that you can make horrible things.

But in a team who have a boring CRM or SaaS front end it’s a pretty good framework to use. Except if you can do everything server side.

Re: If not React, then what?

#494

Post by gls2ro »

diob wrote: post #465
johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

Yeah, poor performance is possible in any system using any tech. Being able to diagnose it and fix it is what matters. I've never had a performance issue I couldn't fix in React.

I think the question that we are discussing here is:

What amount of performance issues you will not need to fix if you were not using React to begin with?

Re: If not React, then what?

#495

Post by root_axis »

FridgeSeal wrote: post #277
root_axis wrote: post #183

Earlier quoted context omitted.

I'm not sure how much experience you have with react, but it doesn't need to "support" links, they function exactly the same as with vanilla js, there's nothing about react that prevents their use. Using JavaScript for links is entirely a developer decision.

Sure is odd that a good number of react-and-friends websites can’t manage to support it all then. Just like how routing and history is “solved” but I encounter websites every other day that completely break my browser history.

> Sure is odd that a good number of react-and-friends websites can’t manage to support it all then.

I don't think that's true. More likely, you use react websites all the time and don't even think about it because the links work as you expect.

Re: If not React, then what?

#496

Post by hombre_fatal »

halflife wrote: post #484
hombre_fatal wrote: post #393

Earlier quoted context omitted.

How do you write a singleton service that can feed state back into the component that calls it when that state changes? For example, `api.fetchInfo()` would want to feed Loading | Success(T) | Error(E) back into the React component call-site when they change. EventEmitters come to mind but aren't without their own issues like subscription leaks. And you have to track component arguments in order to know when to call…

In class components you just could await the result and perform a set state, and that would be it. Easy as pie. But now in function components when everything is called all the time without your control you have to use escape hatches like use effect just to work around react.

Hooks let you wrap all sorts of logic (and other hooks) and return values that rerender the callsite component when changed. Just keep adding on to my hook example and you get more and more code that you need to repeat in every class component that uses it.

Of course, the class component solution to this was to use an HOC, but that had its own issues like complex data flow and wrapper hell.

Hooks solve problems of composition without Yet Another Wrapper and they give clearer data flow, better ref forwarding, etc.

It's easy to see complicated useEffect spam and blame hooks but frankly that wasn't any better when it was happening at different layers of HOCs.

Re: If not React, then what?

#497

Post by root_axis »

cyberax wrote: post #196
root_axis wrote: post #183

Earlier quoted context omitted.

I'm not sure how much experience you have with react, but it doesn't need to "support" links, they function exactly the same as with vanilla js, there's nothing about react that prevents their use. Using JavaScript for links is entirely a developer decision.

I'm familiar with React. And no, links in React often don't work without extra attention. It's way too easy to put some state information into the context and then have your pages depend on it. For example, you have a page with a filter that is implemented via a simple state, and then a list of widgets that pass the filter. The widgets have a click handler that opens the widget details. Now you right click on it. If…

> And no, links in React often don't work without extra attention

Links work fine, out of the box, react treats them the same way vanilla js does. JavaScript onClick events aren't links, and that's true whether you're using react or vanilla js.

> It's way too easy to put some state information into the context and then have your pages depend on it.

What do you mean it's too easy? If someone makes poor engineering choices because that's the "easy" thing to do, that's their fault, the tool didn't make them do that.

> Now you right click on it. If you're lucky, it opens the widget details in a separate tab. However, the filter information is lost.

This is true of JavaScript in general, it has nothing to do with react. In order for links to work, the server has to render pages that correspond to the link, whether that means encoding state in the url or pulling it from a session, this is required whether you're using react or literally anything else.

Re: If not React, then what?

#498

Post by indulona »

It's the JavaScript, stupid. The world needs to move on already from this horrible thing into which we've invested gazillions of development hours and unfathomable amount of money. It's a non-deterministic crap that should have been replaced so freaking long time ago that we're now paying the price for being lazy and sticking with a bad thing instead of moving forward.

Re: If not React, then what?

#499

Post by TeaVMFan »

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://frequal.com/Flavour/book.html ) and a Java SwingSet-like app with live demos and source code called Tea Sampler ( https://frequal.com/tea-sampler/ ).

Re: If not React, then what?

#500

Post by pjerem »

agumonkey wrote: post #374
cies wrote: post #349

Earlier quoted context omitted.

React does very little. You still need other libs to go with it before you can compare the set of them to Angular.

I stopped following the angular world long ago, how much is included in it ? (on my way to read their docs but I'm still open to a short summary :)

Routing, form handling, dependency injection, testing, services, http requests processing, localization etc etc …

In fact the "write a component" part is the center of React but only one of the features of Angular. In my experience, the big advantage of Angular is that you rarely need anything else and so it’s totally possible and reasonable to write a full fledged application without any other dependency than Angular itself. In $prev_job, we had nothing else in package.json than angular, some internal libs and the internal design system (which were exposed as angular providers) and some wysiwyg editor like quill.

It’s far from the funniest framework, but for writing boring things in team setting, it’s actually pretty good.

In fact having worked on the oldest AngularJS framework, it’s very interesting how it made a full 180 from "magic everywhere" to a boring "enterprise" framework.

I would never make a side project in angular because it can be pretty boilerplatey but in a team of 3 or more devs in a multi months dev project that I’ll have to maintain for years, that’d be my choice.

Except if I can reasonably do it without an SPA beforehand but that’s a totally inaudible proposition in corporate world anyway.

Post reply on HN