[protonimitate]

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?

[arnaudsm]

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.

[onion2k]

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.

[BiteCode_dev]

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

KISS

[peterangular]

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).

[mister_hn]

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

[icholy]

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

That's really bad!

[ivanhoe]

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.

[protonimitate]

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 ;)

[tomgp]

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.

[ivanhoe]

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.

[drusepth]

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.

[peterangular]

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".

[protonimitate]

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...

[john61]

"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.

[mead5432]

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.

[GoblinSlayer]

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