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

91–100 of 319 posts

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

#91

Post by arexxbifs »

piranha wrote: post #47
tnova wrote: post #37

Earlier quoted context omitted.

So youb are saying that React makes it easier to do bad things than good things? Would you mind extending on that?

I tried to do that in the article. But the thing is that when you're writing a little piece of code React makes it dead easy to make hover in your code. There a lot of little things like that. You start out with good intentions, but after 4 years of different people certain parts of codebase start looking really weird even with code review. You just can't catch every little detail. And this is why tools should make i…

> after 4 years of different people certain parts of codebase start looking really weird

That's pretty much how software development works though. It's what happens when people with varying skill levels, schools of thought, preferences and approaches to problem solving all work in the same code base. Heck, it'll probably happen even if it's your own pet project: four years is a long time in something as fast-moving as web development, especially when you factor in things like market-driven priorities (E.G. adding new features vs. fixing old "good enough" crap kicking about).

I honestly doubt there's a single software project in history that doesn't have shady corners after a couple of years, no matter how excellent their frameworks, conventions and developers are and how draconian their review process is.

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

#92

Post by yowlingcat »

piranha wrote: post #36
swyx wrote: post #12

> we’ve discovered that React also leads to some questionable practices. Like hovers in JS (rather than in CSS), drop-down menus in JS, not rendering hidden (under a hover) text (Google won’t be happy), weird complex logic (since it’s possible!), etc. You can have a React app without those problems, but apparently, you have to have better self-control than we had (nobody’s perfect!). idk if this is fair. OP was using…

> additionally, I highly doubt that the author has replicated this functionality by using his new turbolinky framework. Which functionality? > a bunch of UI requirements So your point is that you don't really know, but let's blame them for trying, or what?

> So your point is that you don't really know, but let's blame them for trying, or what?

I think GP's post is that _you_ don't really know the landscape which was why you reinvented the wheel, which I tend to agree with. You even agree with this unless you're being rhetorical here, no?

> Which functionality?

Let's take a look at every feature we see on the next.js page (https://nextjs.org/):

Zero Config Automatic compilation and bundling. Optimized for production from the start.

Hybrid: SSG and SSR Pre-render pages at build time (SSG) or request time (SSR) in a single project.

Incremental Static Generation Add and update statically pre-rendered pages incrementally after build time.

TypeScript Support Automatic TypeScript configuration and compilation.

Fast Refresh Fast, reliable live-editing experience, as proven at Facebook scale.

File-system Routing Every component in the pages directory becomes a route.

API Routes Optionally create API endpoints to provide backend functionality.

Built-in CSS Support Create component-level styles with CSS modules. Built-in Sass support.

Code-splitting and Bundling Optimized bundle splitting algorithm created by the Google Chrome team.

Now, do you want some or any of these things? How long do you think it will take to incorporate them into your new tool which you just rolled from scratch?

I guess at this point I'll add in some opinionated views here. At a certain point along your software engineer journey towards becoming a senior engineer, you are supposed to understand that undifferentiated heavy lifting and implementation is a bad strategic move in terms of technical strategy. If I am your CTO and you are telling me that you want to write your own Intercooler-esque library and move all of our core frontend checkout code away from React (an ecosystem with conventions that much of the rest of the world uses) and towards a proprietary solution I am going to ask you for a good reason. That is to say, I am unlikely to be persuaded by "I didn't spend enough time deeply researching how the rest of the ecosystem's users handle these issues" and I am likely to gently remind you that we will likely get more mileage out of investments that make our user experience better rather than scratching the itch to write a new framework.

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

#93

Post by bryanrasmussen »

richthegeek wrote: post #68
brainless wrote: post #23

Earlier quoted context omitted.

I have been with React for 4 years now. Link state can be driven through React if you are testing some state or URL (active URL). But hover should never be React driven. I can not fathom why anyone would do that.

The first legit reason I can think of is if you have a particularly complex UI with fixed/absolute/sticky positioning and you need tooltips. In this case, CSS gets in the way and you need to render the tooltip through a tooltip and so need to set the position using JS on hover.

Like in https://ant.design/components/tooltip/? However, hover used.

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

#94

Post by andrewingram »

Etheryte wrote: post #21
capableweb wrote: post #10

> we’ve discovered that React also leads to some questionable practices. Like hovers in JS (rather than in CSS), drop-down menus in JS, not rendering hidden (under a hover) text (Google won’t be happy), weird complex logic (since it’s possible!), etc. This is some strange reasoning that I have yet to seen myself. If you can do the hovers states/drop down menus in CSS, why not do them in CSS, even if you're using Reac…

Talking of bundle sizes, this isn't inherent to the React point being made here but it's arguably too easy to blow up what you're serving. A common example I like to reference is Moment[1] — unpacked size is 4MB, most of which is different locales. If you _don't_ want to bundle all of those with your project, you have to do extra work, instead of making locales opt-in. Perhaps slightly less used, but a more prominent…

At my last job I always tried to be quite strict about adding additional dependencies, if something was over 10kb it had to be very strongly justified.

Our designers wanted to add some SVG animations, they started off with Lottie (https://bundlephobia.com/result?p=lottie-web@5.7.2) because they could export directly from After Effects, but I said no chance because of its file size. Briefly considered Greensock (https://bundlephobia.com/result?p=gsap@3.5.0), but it was also too big for the kind of animations we were looking it.

I'll need to double check what we ended up with, but it didn't have any library code, so each animation was just a self-contained bundle of SVG and CSS animation code, and fairly small.

Edit: I asked around and SVGator (https://www.svgator.com/) is what we ended up using.

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

#95

Post by dsego »

Jestar342 wrote: post #39
hombre_fatal wrote: post #15

Earlier quoted context omitted.

That first quote (using JS when CSS would be faster and simpler) does remind me of being a beginner and always arriving at jQuery's animate() for all my needs. That said, animation is hard, and React doesn't insulate you from that, so it takes some thought. In fact, being a layer of abstraction, it requires even more understanding of animation. Fading a component in is easy with regular CSS transitions. But fading a…

RE: jQuery.animate() - that was around before CSS animations were. Animations were not in the CSS spec until v3 which only saw widespread support this side of 2010. Before then you could only do animations with Javascript, and frankly jQuery's `animate()` was a god-send.

On top of that, js animations are still better for controlling timing and events or for a more realistic natural motion (springs instead of timed easing).

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

#96

Post by dsego »

madeofpalk wrote: post #77
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 cannot see how react encourages you to forget :hover in CSS.

If a mouseover should trigger an an action that causes the component to redraw, those the hover state persist?

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

#97

Post by juicypt »

piranha wrote: post #50
piranha wrote: post #29

Earlier quoted context omitted.

Oh yeah, binary assets. Yeah, it is certainly binary assets. We just embed node.js in there. /s

> consider that the readers don't have the same background and context as you, and we all discuss based on those. Okay, so how about not inventing outrageous ideas on the spot and just consider what is written? It's equally as hard to unload what's been boiling in your brain for last half a year. I'm reading comments and trying to decide where to expand my post, of course, but this "binary" thing just got me laughing…

Actually webpack has the url-loader which allows embedding binary data as base64 data URLs in your CSS bundle. If used judiciously it can even be a good thing too.

EDIT: I mentioned webpack since the thread is about react, but you can do the same thing manually by putting the base64-encoded data in a data URL on a CSS file.

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

#98

Post by dsego »

llimos wrote: post #17

For sites that are content-heavy I've started wondering if it makes sense to have the content server-side rendered the old-fashioned way, and use multiple React roots for the parts of the page that need to be interactive. You can still use Redux etc. for managing app state globally (though not React context), and you get most of the gains of load time, and of using React where you need it. It seems everyone uses but…

Yes, a hybrid. Routing and initial rendering handled by a server-side MVC framework, like Laravel. And on each page you can have one or more micro SPA-s with a lightweight JS framework like Mithril or Preact. You can even send the initial payload as JSON in a special JS global variable inside a script tag.

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

#99

Post by piranha »

arexxbifs wrote: post #91
piranha wrote: post #47

Earlier quoted context omitted.

I tried to do that in the article. But the thing is that when you're writing a little piece of code React makes it dead easy to make hover in your code. There a lot of little things like that. You start out with good intentions, but after 4 years of different people certain parts of codebase start looking really weird even with code review. You just can't catch every little detail. And this is why tools should make i…

> after 4 years of different people certain parts of codebase start looking really weird That's pretty much how software development works though. It's what happens when people with varying skill levels, schools of thought, preferences and approaches to problem solving all work in the same code base. Heck, it'll probably happen even if it's your own pet project: four years is a long time in something as fast-moving a…

That is true, but the effect various "quirks" have on result are very very different.

I did not decide to switch from React with a light heart, it was a long and painful decision. But it seems to me that React's path of least resistance leads to a slow bundle, and you're going to fight an uphill battle.

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

#100

Post by christkv »

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 also just bit the bullet and paid for syncfusion to use on our frontend to avoid reinventing the wheel for a lot of the functionality we need.

Post reply on HN