Hacker News Reader

Comment by arnaudsm | Hacker News Reader

What's the advantage of using React for a landing page that could be a 10KB static HTML file ? (non-sarcastic question)

Extensibility. We may begin with simple hero image/call-to-action, but we might wind up with a sign up form with validation, a interactive map of office locations, maybe even fancy particles (who doesn't love particles!?[1]), etc.

The page load will be fast enough to dissuade no users, I can add server-side rendering & free code-splitting (e.g. Next.Js), etc. Seems like a good deal.

[1] https://vincentgarreau.com/particles.js/

So... premature optimization?

Premature optimization would be doing things in static HTML even though the rest of your code is in React because static HTML is "lighter" or "faster."

Also, Next.js does static HTML export out of the box if that's your preferred end target.

Over-engineering perhaps, but not premature optimization. You don't have to reach for that stuff until you need it.

As a side note, I do often advocate for somewhat over-engineering projects by starting with familiar frameworks. They strongly constrain the solution space yet give power to quickly meet inevitable feature creep. Strong KISS/YAGNI proponents might balk at that endorsement, but I've had far more trouble handling growing pains from adapting codebases that don't use frameworks than I have working in such over-engineered framework-based projects.

This is fascinating. If you ever feel like writing about your experiences adapting codebases, I'd read it in a heartbeat! :)

I would argue that if it's just for one or a few components, it's straight-forward to just drop in react parts there while leaving the rest of the page static. If the whole page should suddenly become dynamic, the work of migrating to react will probably be dwarfed by the work for actually building the new functionality.

So there is little reason to start out with react for a static page, unless one already knows they are soon going to extend it to something radically more dynamic.

> who doesn't love particles!?

I don’t. Please don’t waste my cycles and battery on pointless visual effects (unless you’re a vfx company).

Right - I get pretty angry when I watch activity on my CPU cores spike with opening a "pretty" website. If my CPU fan is revving because you're doing silly particle effects (usually sans WebGL) I'm not happy with your solution.

I'm seeing 714kb of data loaded over 924ms.

Not as small as possible, but I don't think this really qualifies as bloat.

Imo the benefits of using React boilerplate for a landing page would be: - Quick to set up / customize (faster than starting from scratch in vanilla js, anyway) - Flexible. Allows devs to quickly pivot the landing page into a "landing page + [whatever]" if needed

If pure speed to load is your endgoal, then go with a static page. However, I think a vast majority of users won't notice and/or care about the small difference in speed or "bloat".

I guess to flip the question, what's the benefit of using a static HTML file over React, other than a 10kb footprint?

Thanks for the answer, those are valid points!

I think most web developers forget that most visitors don't have fiber connections and high-end hardware like them. This page renders at 15 fps on my mom's laptop with an old Core I3.

I kept my old ThinkPad just to test my websites.

I'm seeing 714kb of data loaded over 924ms.

That's not the React stuff though. There's 82KB of JS from the React bundle (main.08bdff3a.chunk.js and 2.8a9031d8.chunk.js) on the demo site (plus 18kb that's loaded asynchronously for Google's analytics script). Everything else would be necessary even if it was static HTML and vanilla JS. Heck, the video-placeholder.jpg image is bigger than all the JS combined.

And it's not really been optimized at all. A whole stack of the React components could be lazy-loaded with Suspense to get the initial page weight down a bit more. If you didn't want to do that you could probably swap React for Preact and knock another 20KB off the JS bundle size.

> I guess to flip the question, what's the benefit of using a static HTML file over React, other than a 10kb footprint?

KISS

100% agree - bringing in a framework for a landing page is insane to me in regards to pushing dependencies where they don't belong.

In this conversation I have yet to see one solid argument for inclusion of React on a landing page outside of "it can help the developers pivot to landing page + something else". Sure I can sorta see this, but if you're an engineer who decides on major dependency inclusions based on what may happen you're over-engineering (ESPECIALLY in regards to a landing page).

700kb is bloated for a basic landing page.

Websites should be as small as possible (max 100Kb).

A static page outperforms React, especially if systems like Hugo or Jekyll are used to keep themes separated from content

> I'm seeing 714kb of data loaded over 924ms.

That's really bad!

According to DevTools it has around 80KB of JS and the rest is the design, mostly pngs of screenshots or whatever those graph looking things are. If you plan on using it for your own app, you'd probably set those to your own promo images, so it's really not such a big deal.

How so? Anything < 1 sec of load time on average is "good enough" for 90% of use cases.

The only way you could possibly quantify this is by collecting data on # of conversions between the "optimized static site" and this react boiler plate.

Spoiler: the time you waste collecting this data could be spent working on an MVP that this landing page is supporting ;)

The question is; sub 1sec for who? A lot of people aren’t going to be loading that page over the same quality of network connection as your average hacker news reader. Many’s the time I’ve cursed web developers when I’ve been on a train trying to book a restaurant or some other simple task that doesn’t need animation or images or video.

Problem with that approach is that 1 second on his connection is not necessarily equal to 1s on mine or your connection. So we'd need to see the expected traffic and then discuss "the average time" that makes sense, the speed for the target group.

Please don't take this as argument, but do you have any studies/sources that support anything <1 sec of load time being "good enough" for 90% of use cases?

Maybe I'm naive, 90% seems like an extremely high estimation to me.

It's an over-generalization and I'll throw my own anecdata in here from ecommerce: I've seen MAJOR improvements with conversions when I can get something from a 1s load-time down to <250ms. I don't have any published studies out there on this but you can definitely find TONS of data on faster load increasing customer interaction/conversions.

Specifically, it's an interface-to-interface thing as much as a first load experience... if a customer can browse my stores with near-instant loading of product pages (or maybe even pre-loaded) they are more likely to look at more products. If they're more likely to look at more products, they're more likely to buy, etc etc. Sure 750ms doesn't SEEM like much, but what about someone who's shopping for a formal dress? They may be looking at 20+ unique SKUs within a shopping experience so take 20 * 750ms and there ya go.

We don't control things like network conditions, etc. and even in 2020 we must be respectful to the end client in regards to transmitted data to run an experience.

I know I didn't link to any studies here so it's all moot, but I'm just sharing my in-industry experience with optimization to illustrate that lots of people don't settle for "90% of the time <1s is good enough".

I probably should have just said "a majority", but Google has a good resource on page load studies[1].

"DoubleClick by Google found 53% of mobile site visits were abandoned if a page took longer than 3 seconds to load."

Maybe my logic is wrong, but considering 3 seconds is the "tipping point" for more abandonments than not, anything under 1 second is "good enough" imo.

Again, I don't have data for this, but I would suspect that the difference between 100ms and 900ms won't impact business metrics in any meaningful way. Or at least enough to warrant the "react is overkill" argument.

Is react more than necessary? sure. Does it matter? I don't believe so. Whatever gets your landing page/product in front of people faster (from a development and time to ship POV, not just page loading) is what matters.

The bigger point is that particularly on HN, a lot of comments love to point out how "react is overkill", but it's mostly just a knee-jerk reaction. It seems that lately anytime anything to do with React is posted here, it's immediately met with "why react?" comments. In some cases they're warranted, but for the most part its just boring conversation that cares more about being pedantic than helping out. Particularly for this example, this is just one option that someone might want to utilize. It should be up to the user to weigh the pros and cons of picking this template. I don't see why the entire conversation should be dominated by "static sites are better" rhetoric.

[1] https://developers.google.com/web/fundamentals/performance/w...

"I guess to flip the question, what's the benefit of using a static HTML file over React, other than a 10kb footprint? "

I can view it on my 11 years old N900 which is still my smartphone in daily use.

Every line of code represents an opportunity for a defect. In the case of a landing page, that could crater your conversion rate.

You reduce that risk by using more static HTML.

Remind me why there's this native mobile app fad.

I can learn react and I can apply everywhere. Reuse my react components with styles. No global css class flying around. After a few pages static html becomes a pain to maintain.

Plus I don't like static html. If I setup webpack (you want different files, proper es6, imports...) You can easily add react.

No need to shift your thinking between static html and react.

Much easier to have 100 websites just with react. Can share components, hooks...

End of the day, faster Dev time, consistent projects, more enjoyable experience, reusable components. I trade that for a few Ms of speed.

Templating isn't a React-only feature, there are other frameworks that give you that.

Using React for a static landing page is like using a flamethrower to light a birthday candle.

True, but you know for sure that candle is lit. ;)

On the React topic: jsx within classes does make it nice to build components, but again you’re right that others provide the same experience.

I would say that if all you're serving is a landing page, with the appropriate namespacing all you really need is SASS or even css. How many things could you possibly be sticking on a landing page that is supposed to be short and to the point?

I suppose someone would eventually choose to do more with the site and wants to use React at that point, that might make it a better fit.

Otherwise, I also don't think it is quite the end times that they used react at all anyway.

I enjoy the discussion but every page that gets posted on HN gets this sort of armchair systems architect discussion that seems to be a bit over the top IMO.

You can use server-rendered React. You get the benefit of having components without the cost of downloading React on the frontend (unless you have something interactive). This is what NextJS does.

First off, thank you for building and sharing with the community. I have built a few landing pages with React and always end up regretting because you always need a React developer to maintain. I think best to build the landing pages (about, homepage, faq, etc) in something a non tech person can use like Wordpress or at least Hugo (markdown). You don’t need to bring in a React developer when you want to add a new marketing section to the homepage.

Reply on news.ycombinator.com