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

241–250 of 319 posts

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

#241

Post by piranha »

Demiurge wrote: post #158

> It supports only modern browsers (not IE or Opera Mini) but drops that 88kb monster. Whenever I read this, I usually take it the author is being serious. However, how long does it actually take to load a 88kb library these days, is it really 'monstrous'? If this was the authors top performance drain based on profiling, I commend their technical abilities.

Well, the reason why I started writing my own library is because I couldn't get all functionality I needed from Intercooler. Why it does not depend on jQuery? Because I wanted no dependencies. :-)

And a "monster" is sarcasm referring to that React bundle I described before.

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

#242

Post by recursivedoubts »

nightski wrote: post #235
mattmanser wrote: post #185

Earlier quoted context omitted.

If you don't need a rest API, all it does is make everything far more complicated, i.e. every page now has two end-points, one for the html, one for the data. It's trivial in most web frameworks to have an endpoint respond in two ways, one with all the html including head, menus, footers, etc. if you hit it with a GET, the other just the snippet if you hit it with an Ajax request. A REST API is basically a massive ov…

Fair points. A couple of notes though - intercooler needs two endpoints as well. One for the page, and another for any dynamic HTML. I mean I switched from jQuery to knockoutjs to react all on one application and the API served all those transitions well. So I'm speaking from personal experience here. But that is anecdotal and maybe it's not typical.

One pattern that I have used with some success is to reuse end points and use metadata that comes up with intercooler or htmx requests to determine the structure of the output.

For example, if I have search functionality at

/search

and I'm implementing the active search pattern shown here:

https://htmx.org/examples/active-search/

I'll re-use the /search url for the partial search results and check the HX-Request header to determine if I want to render the entire search UI or just the search results.

If you use hx-push-url as well, you can get a search dialog that acts like an active search for the user, but also retains copy-and-paste-able URLs

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

#243

Post by oreoftw »

nawgz wrote: post #237
tomc1985 wrote: post #209

Earlier quoted context omitted.

> 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. Huh? Something like Rails lets you iterate on server-side stuff extremely quickly. There is a lot of functionality you can implement that doesn't need JS at all

Never developed in Rails - does it handle: * composable templates * reusable JS snippets * hot reloading in your browser And additionally, given that the topic is "building web applications", I can't really understand how you think you can build interactivity without JS. Are you proposing form-based updates or is your understanding of "application" different than GP and mine?

Yes.

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

#244

Post by nawgz »

oreoftw wrote: post #243
nawgz wrote: post #237

Earlier quoted context omitted.

Never developed in Rails - does it handle: * composable templates * reusable JS snippets * hot reloading in your browser And additionally, given that the topic is "building web applications", I can't really understand how you think you can build interactivity without JS. Are you proposing form-based updates or is your understanding of "application" different than GP and mine?

Yes.

Can you link me some docs? I would love to see how the modern tools I learned at my outset compare to the classics.

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

#245

Post by piranha »

Shorel wrote: post #194

If anything should be learned from this article is this: "We need to look at it from two sides: if it’s good for developers and if it’s good for users." It is a pity this change in thinking required the pressure from Google Pare Rank, but now I see it as something very positive. Always remember: code is written once, and executed thousands or even millions of times. No optimization is worse than "premature optimizati…

Honestly, I now think that the main reason was different. I was fed up by my Macbook Pro's butterfly keyboard and started working on Macbook Air '15 again at the end of 2019. And in three months I was increasing annoyed by our site loading time.

And then it hit me. MBA is not the slowest laptop out there. It is much worse for a large part of our users.

This is where I started thinking we should jump off the hype ship. :-)

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

#246

Post by kilburn »

nawgz wrote: post #240
kilburn wrote: post #225

Earlier quoted context omitted.

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…

>Flexbox won't work because you don't have a fixed height Are you saying the issue is that flexbox will force everything to have the same height? I am relatively sure that `flex: 0 0 fit-content;` on the children and `flex-wrap: wrap; flex-direction: column;` on the parent will do what you want

> Are you saying the issue is that flexbox will force everything to have the same height?

No, I'm saying that you will not get columns unless you specify a fixed height for the container. Since you don't know the total height you want for the container, this is not a valid solution.

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

#247

Post by crooked-v »

krzepah wrote: post #143
ricardobeat wrote: post #124

Earlier quoted context omitted.

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

Why on earth would you specify your styling in your JS ?

Being able to dynamically supply theming is a big one. For example:

    const Header = styled('header')`
       font-family: ${({ theme }) => theme.fonts.header};
       color: ${({ theme }) => theme.colors.primary};
       backgroundColor: ${({ theme }) => theme.colors.primaryBackground};
    `
...where the theme object can be swapped out on the fly for different sections of a web app.

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

#248

Post by nawgz »

kilburn wrote: post #246
nawgz wrote: post #240

Earlier quoted context omitted.

>Flexbox won't work because you don't have a fixed height Are you saying the issue is that flexbox will force everything to have the same height? I am relatively sure that `flex: 0 0 fit-content;` on the children and `flex-wrap: wrap; flex-direction: column;` on the parent will do what you want

> Are you saying the issue is that flexbox will force everything to have the same height? No, I'm saying that you will not get columns unless you specify a fixed height for the container. Since you don't know the total height you want for the container, this is not a valid solution.

Ah yeah, I see your point. Fair enough.

However, if you're already using wrapper divs, it seems to me like you do some math on your boxes after the initial render to balance them. Either that or you literally just group them into 3 groups and accept whatever artifacts (read: column height mismatches).

Either way, there is a CSS-only solution of sorts. Render the parent with 0 height, iterate over the children groups to find your max column height (remember - you already do this grouping with your wrapper divs), set your component height to your max of the 3 groups with 200ms transition, and you have a sweet CSS-only animated solution

Might not be worth it - in my approximation it's not - but I guess that could depend on your domain.

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

#249

Post by dreamcompiler »

I've been doing Ajax practically since Day 1, and in the olden days when I was young and stupid I actually sent DIV IDs back to the server, which the server would then reply with -- in XML -- to tell the client which DIV to replace.

Then I realized Javascript could do lexical closures which meant the client could keep track of the targets, which also meant the server no longer had to care about things servers shouldn't care about.

The next realization was that DIV IDs are global variables and thus in most cases a bad idea, so now my event handlers automatically search upward (and sometimes sibling-wise) from 'this' for DIVs matching classes or other selectors, to keep the scope local.

This TwinSpark library seems like the next iteration of all the good ideas, plus even more flexibility and proper separation of concerns, without JQuery or other dependencies.

Bravo!

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

#250

Post by 9HZZRfNlpR »

kilburn wrote: post #225
davidwparker wrote: post #216

Earlier quoted context omitted.

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…

What about 'order' attribute?

https://developer.mozilla.org/en-US/docs/Web/CSS/order

Also if css can't do it why go you need react when you can do it in few lines of css? Not not difficult to rearrange elements based on viewport size.

Post reply on HN