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

A tale of webpage speed, or throwing away React

solovyov.net

Post reply on HN
Print view View original

131–140 of 319 posts

Re: A tale of webpage speed, or throwing away React

#131

Post by [deleted] »

aphextron wrote: post #126
kilburn wrote: post #111

Most people here are criticizing the author for doing some dumb things. I concur, but still think they have a good point. First, keep in mind that the author's use case is a content-heavy app with sprinkles of interactivity. This is very important because it sets the "webpage speed" goalpost to a concrete place: they want good lighthouse/first load times and good SEO. I've fallen into the same pit before. I've used C…

It's just apples and oranges. Web pages should never even consider using React. Maybe a bit of vanilla JS/jQuery here and there for whatever interactivity you need, and then server side rendering for the content. Building web applications on the other hand, has been revolutionized by the use of React. I would never seriously consider any other UI rendering library right now because of the sheer volume of support and…

[deleted]

Re: A tale of webpage speed, or throwing away React

#132

Post by tluyben2 »

kungato wrote: post #46
hliyan wrote: post #28

When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight. javascript fatigue: longing for a hypertext already in hand What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You wil…

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

I have not seen a good case of this. Can you point out one? Managing state on the server is trivial; sessions and database and that is it. How does handling on the client work? Well it works if you double up on the server; it is a crime when there is some SPA that manages state client side; something goes wrong and it is stuck, press reload, state gone; login page. It is annoying to me as dev, it is creating serious anger for people who do not understand this. They press f5 and are logged out. Wtf. Or their shopping cart is now empty. So if you want to fix that you have to handle state on the client and then sync with the server; how is that better than just having it on the server? I am a backend dev but I see more and more of my frontend colleagues move stuff to the server: it is just easier to reason about imho.

Sending over generated pieces of html that update divs I find a quite nice compromise: not the complexity while having updates without refresh. Intercooler sounds like that.

Re: A tale of webpage speed, or throwing away React

#133

Post by _fat_santa »

christkv wrote: post #100
tom_walters wrote: post #11

This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article. React is a great choice for certain use-cases, but when low-quality developers are allowed to pick it up and apply it to everything you end up in a mess. The same thing happens with literally any tool. If you want speedy initial interaction times and manageable codebases, (and requireme…

React has been god sent for us as we slowly modernise an application that is a mess of server rendered html and hacked together frontend code. Slowly we are rewriting individual pieces as embedded React components (no SPA here) and moving to a proper API layer that the components talk to. The separation of concern has made it a loot easier to increase code coverage and ensure a controlled rollout of new features. We…

Honest question. As someone whose only worked with open source tech in React such as Bootstrap, Semantic UI, Material UI, etc, what is the advantage of a paid UI framework like this?

Maybe stability? Besides Semantic UI I found that other frameworks are nowhere near as mature. I guess if you're a big company its a small price to pay but it also seems like you're paying a grand + per month for something with tons of free alternatives.

Re: A tale of webpage speed, or throwing away React

#134

Post by dceddia »

ricardobeat wrote: post #124
madeofpalk wrote: post #77

Earlier quoted context omitted.

I cannot see how react encourages you to forget :hover in CSS.

You can argue it is not React's fault as usual, but this is how: setState('active')} /> const styles = StyleSheet.create({ active: { backgroundColor: 'purple' } }) progressing into: setState('active')} onHover={() => setState('hover')} /> const styles = StyleSheet.create({ active: { backgroundColor: 'purple' } hover: { backgroundColor: 'blue' } }) which is frictionless and 'clean', vs the alternative: const styles =…

The thing is, React works with plain CSS too. I think a lot of newcomers see that JSX looks like React-flavored HTML and naturally assume that React will have its own flavor of CSS, but it doesn’t. There are libraries for CSS-in-JS of course, third party ones. But implementing :hover on a button in React can be done just the same as in plain old HTML - with a bit of CSS in a .css file. Or for active/inactive states, you can use template strings to set a dynamic className, and target that className in the .css file.

Re: A tale of webpage speed, or throwing away React

#135

Post by smichel17 »

smichel17 wrote: post #81
ricardobeat wrote: post #58

Earlier quoted context omitted.

> Seems to be blaming something on a library that the library has no care about in the first place Libraries and frameworks establish idioms, which encourage or discourage certain patterns. In my experience React / JSX definitely encourage complexity and abstraction by making display and logic so intertwined, especially with hooks. > And holy guacamoly, how do you end up with this? Libraries upon libraries, one tiny…

I can second this. I'm working on two projects, one paid and one volunteer. One is using vanilla css/html (requirement to work without js) and the other is using react. Doesn't matter which is which. To set the context for the following statement, I've discovered that I prefer developing the nojs site. This mainly comes down to all the things that the browser does for me, but I have to handle manually in React, but i…

The first reason is what ricardobeat mentioned — with JSX, I'm writing my display "html-ish" code at the same time as the business logic. If I'm managing the state of, say, a form, and I want the submit button to be disabled when (condition), the obvious solution is to add `disabled={condition}`, rather than a conditional className or attribute to then match on in css. When I'm doing everything in one file, switching to a different file feels out of place and breaks me out of my normal flow.

This is also why I tend to think in terms of utility classes. When I'm writing JSX, I'm also visualizing how the final page will look (or actually looking at it, side-by-side). So, it's natural to be thinking about the actual styles I want to apply, not classes that hold several related styles. Sometimes I'm almost tempted to write inline styles, but thankfully the syntax is awkward enough to dissuade me.

The second reason has to do with how the html part of JSX is structured. When writing css for plain html, it's easy enough to see how the page is structured and go through it writing css classes for each block (or applying existing classes). Then you refactor as you notice common patterns and to put different style in the right places (oops, that margin should have been padding on the parent element…), like with any code. But with React, js is often changing bits and pieces of the dom itself, so it can be hard to look at and see the structure in the same way. Thus, it's easier just to apply the styles in the same place as everything else. (In React's defense here, I think if I were doing a similar amount of dom mutation using vanilla js, jquery, etc, it would be even harder to write css for it… but on the other hand, vanilla js doesn't encourage me to do nearly as much of it in the first place.)

Re: A tale of webpage speed, or throwing away React

#136

Post by [deleted] »

davidtranjs wrote: post #18

All of your issues like dropdown and hover in JS can be solved by CSS, why did you choose to implement them in JS? About complex logic, it is everywhere. I once worked at an big ecommerce company and the server-side catalog page was more then 2000 lines, nobody want to touch that page. But it would be easier with React since we can break it down to smaller components. Your 2.5MB minified bundle is actually too big.

[deleted]

Re: A tale of webpage speed, or throwing away React

#137

Post by nthj »

jack_riminton wrote: post #123
nthj wrote: post #104

Earlier quoted context omitted.

If you’re going for speed of development, it’s hard to beat server side rendering in Rails. The creator built Rails for speed of development and happy engineers. It’s also very opinionated (convention over configuration) which helps me just build out features rapidly without making thousands of pointless decisions. I am not opposed to React for like, a calendar application, or a particularly complex part of a web app…

The happy engineer concept is a much neglected one imo. Rails devs who’ve mastered a lightweight js framework like Stimulus and perhaps a webhook utility like ActionCable are immensely more productive than a team of very separate front and back end devs. Basecamp take this a level further whereby each dev is quite heavily involved in the design process, and their designers can also code in Rails. With Hey I think the…

Oh I agree, I lost a lot of nuance with my trite 1-sentence summary. Shiny is mostly good judgement, good taste, careful organization and a lot of sweat resulting in well-crafted CSS.

Especially in the past few years, as browsers have implemented a lot of animations and scaling in CSS which offloads to the GPU. You don’t want JavaScript/CPU doing that math anymore.

Component-based JavaScript frameworks “force” us to organize our CSS in the same way outlawing cars in favor of bikes bikes ensures everyone follows the speed limit.

Re: A tale of webpage speed, or throwing away React

#138

Post by gvjddbnvdrbv »

aphextron wrote: post #126
kilburn wrote: post #111

Most people here are criticizing the author for doing some dumb things. I concur, but still think they have a good point. First, keep in mind that the author's use case is a content-heavy app with sprinkles of interactivity. This is very important because it sets the "webpage speed" goalpost to a concrete place: they want good lighthouse/first load times and good SEO. I've fallen into the same pit before. I've used C…

It's just apples and oranges. Web pages should never even consider using React. Maybe a bit of vanilla JS/jQuery here and there for whatever interactivity you need, and then server side rendering for the content. Building web applications on the other hand, has been revolutionized by the use of React. I would never seriously consider any other UI rendering library right now because of the sheer volume of support and…

> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend.

This depends on project size. If a single team is working fullstack then using server side templates gives seriously faster product development iteration. Once you get to more than 5-10 devs and you want separate frontend and backend teams then it slows down.

Re: A tale of webpage speed, or throwing away React

#139

Post by nthj »

_benj wrote: post #121
nthj wrote: post #104

Earlier quoted context omitted.

If you’re going for speed of development, it’s hard to beat server side rendering in Rails. The creator built Rails for speed of development and happy engineers. It’s also very opinionated (convention over configuration) which helps me just build out features rapidly without making thousands of pointless decisions. I am not opposed to React for like, a calendar application, or a particularly complex part of a web app…

I agree with you, even thought I might personally prefer Elixir/Phoenix :-) In my particular case thought I've been opting for Golang given that my web app needs to perform a little more that CRUD. And in regards to the CRUD part I've been heavily relying on PostgreSQL functions, thus instead the pain of a ORM I just have simple raw sql `SELECT * FROM api.get_user_data(?,?);` I'm not saying that is not possible to to…

Sounds like you and I have similar approaches, and I just have more CRUD to manage in my case. For e.g. payment processing endpoints, I use Golang. Managing 3rd party SDKs is nicer in Golang, imo.

I also heavily rely on Postgres views, which ActiveRecord just sees as read-only tables, so my Rails code can still call `user.api_data_entries` without any ORM wrangling.

Re: A tale of webpage speed, or throwing away React

#140

Post by thrownaway954 »

ForHackernews wrote: post #2

Is this approach similar to Rails Turbolinks?[0] [0] https://github.com/turbolinks/turbolinks

not really. turbolinks replaces the entire body when you click a link, there is now way to replace just a portion of the page.

pjax would be a better OG similarity: https://github.com/defunkt/jquery-pjax

Post reply on HN