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

221–230 of 319 posts

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

#221

Post by softawre »

_fat_santa wrote: post #133
christkv wrote: post #100

Earlier quoted context omitted.

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 f…

You're paying for the support you need when your developer can't fit requirement X into the component, or when they run into a bug, or whatever other reason.

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

#222

Post by toastal »

corytheboyd wrote: post #204
tom_walters wrote: post #60

Earlier quoted context omitted.

Pretty much. It's similar to discovering the power of salt and pepper in cooking. When you first use it everything tastes better. But the next step is not to increase the amounts you use in every dish, it's to explore the much wider world of cooking with herbs/spices/etc. If your mindset is persistently "this framework/tool will solve all our problems" you're always going to have a bad time. Understanding the pros/co…

I’d just like to expand on this, as I think it’s a great comparison! Carefully picking tools is important, but also, don’t adopt more tools than you need to. One common example I have seen is pulling in a CSS-in-JS library to do something that SASS can easily do... when SASS is already incorporated into the build process. SASS offers a fairly complex set of features if you care to learn about them, and the module sys…

If you need something much less complex than Sass, but has a similar syntax to Sass (not SCSS), PostCSS + SugarSS has been nice for me. I really prefer indented syntax, and ever since CSS variables became readily available on my project support requirements, there's not been much reason to reach for Sass. A lot of people seem to point to the color functions, but I don't think a lot of people noticed Sass and Less don't do color mixing/darkening properly (they don't square the gamma before doing operations) so I wouldn't advise using these built-ins anyhow.

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

#224

Post by recursivedoubts »

bharani_m wrote: post #214
recursivedoubts wrote: post #114

The initial motivation for intercooler.js (which the author forked) was performance. I was working on a large bulk table update and building the table dynamically in javascript. The performance was terrible (this was back in 2012, no idea what it would be like today). I realized that I could just deliver and slam HTML into the DOM and that the browser engine, written in C, was very fast at rendering it. That turned i…

This is really interesting. Thanks for all the effort you've put into this project. I had one quick question - how easy/difficult would it be to integrate another JS library with intercooler or htmlx. For example, let's say a table is fetched dynamically via htmlx, how would we go about integrating a library that does client-side table sorting/filtering?

It's not perfect, but not awful either. Basically you have to catch the content and initialize it with the library using a hook:

htmx.onLoad(function(content){myJSLib.init(content)})

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

#225

Post by kilburn »

davidwparker wrote: post #216
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…

If you're truly having issues with CSS and rendering different sizes, I'd recommend taking the time to really learn CSS inside and out. I find it incredibly simple nowadays to do both Mobile/Desktop (+Tablet) with CSS and media queries. I may have agreed with you in the past, but not so much anymore.

There are still some things that are impossible to achieve with CSS alone, even if you have the luxury of only needing to work with evergreen browsers (remember we are speaking of content-heavy sites here, which are the most prone to still have to support older browsers).

Example: I have a stack of boxes of varying heights. On mobile they are fine as is (one below the other). On tablet I want them in two columns but displayed in column order without gaps. On desktops I want three columns. This is dynamic data, so the number of items and their heights will vary, but my CMS allows the user to mark at which box(es) new columns should start:

  mobile  tablet  desktop
  a       a  c'   a  b* d*
  b*      b  d       c
  c'
  d*
' indicates this element starts a new column for tablets (two-column layout)

* indicates the element starts a new column for desktops (three-column layout)

Can you achieve this with HTML/CSS alone? How?

- CSS columns won't work because Safari doesn't support break-brefore in a columns context.

- Flexbox won't work because you don't have a defined height for the container (so you can't use flex-direction: column + flex-wrap).

- CSS grid won't work because you'll get a grid (i.e.: gaps between elements when the boxes have varying heights).

- Ye-olde-floats won't work because you'll get weird gaps too when the sizes change.

- You cannot wrap the elements in column-divs because you can't do it for both tablet and desktop simultaneously.

Also, you need to be very confident in all of the above to know that is is not possible, instead of getting sucked into trying, getting to an "almost there" point and then realizing it doesn't work under X condition.

In contrast, with React you can just generate 1/2/3 wrapper divs depending on whether the current width is mobile/tablet/desktop and call it a day. It takes you all of 5 minutes to do so and the margin for surprises is 0.

Edit: reworded why flex won't work to address nawgz's comment.

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

#226

Post by debaserab2 »

ricardobeat wrote: post #61
kungato wrote: post #46

Earlier quoted context omitted.

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

> return the full html every time The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting. Note that with an SPA you need to send templates (in the js bundle) + data (json api) to the client, which by definition will be at least as large as static HTML for the same content : HTML is nothing more than the template and content already baked in. In practice the J…

> which by definition will be at least as large as static HTML for the same content

Not really by definition - tables rendered on the server side are a good example of a payload that can easily be larger than template + dataset.

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

#228

Post by bromuro »

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…

You don’t need even build always a SPA with React. For interactive widgets, Resct works better to me than jQuery.
Post reply on HN