This is not a good use case for react. At all. A landing page should do one thing and one thing well: drive an action. The less distracting interactivity the better. The only thing you want interactive are your CTAs. The overhead of using React, even if using a static site generator, isn’t worth it. Not when you can whip up a simple HTML/CSS page in less time that’s far far easier to build and deploy. Because the faster you get it out, better. The less time between TTFB and full interaction, the better. Otherwise you’re wasting time and ad spend.
And don’t get me wrong, I like React. And the projects have used it on have impressed clients beyond what we could achieve with just using backend HTML templates. But for a landing page that you’re driving paid traffic to? Not a good use case at all.
For what it’s worth - there’s definitely no speed up, for me at least, to ship a pure handwritten HTML + CSS page vs the same page using create-next-app. The latter makes it trivially easy to add new functionality, etc; the former guarantees I have to start over. I also get a bunch of stuff - TypeScript, code splitting, minification, etc - for free, literally no work. It’s nice.
Using Next with Preact instead of React makes the total gzipped JS bundle around 20kb. Takes no time to set up.
If you’ll only ever build one website, sure, use basic tools. If you can amortize the cost of learning the toolchain across many projects, use better tools! (I’m not saying that’s only React by any means.)
Why would I need TypeScript, code splitting and new functionality on a single page with one purpose: to sell?
I’m all for extensible solutions when required but React does not buy me much for the overhead on a landing page that I drive paid traffic too.
Now if a client had marketing team that needed to spin out a new landing page along with an ad on demand without code, I’d use React to build a landing page builder. The server would generate a static page and I’d have something cache that (and purged on modification of that page or a release). That’s perfect use case for React.
But a single page that I’m driving paid traffic to for a new business? Not in react. If I needed two, I have no shame, I’d copy and paste. Then at 3 I’d consider static site generation - on the basis that the build produces static assets only. Perhaps if the campaigns do their job, I can invest in tools that empower my marketing guys to build landing pages for their campaigns.
The fact is I don’t need the interactivity of React on a landing page. I don’t need more functionality on a landing page than CTAs, sales copy and social proof. If I’m putting anything more than that on a landing page, I’m failing. If the landing page is not 100% focused on what I want, which is usually sales or the entry to a funnel, it’s failing.
Now if the product you’re selling, as I said below, IS highly interactive and user friendliness is a selling point, I can see React being of use for live on-page demos of features. Because that’s what you’re selling!
A number of years ago, I was conducting an interview for a front end developer position. I started with a mostly algorithmic question hoping to gauge the candidate's comfortability with javascript. It was something like “use a for loop and manipulate an array”. They froze up and asked: “can I use jQuery?”. At that point jQuery was at peak ubiquity. Here we had someone reaching for it when the DOM wasn’t even on the table.
I think we’re at that point with React today. It’s become the de-facto way to make a web page, oftentimes for the better. People use it on their complex sites so even for a simple landing page, it’s often the most comfortable tool to work with, despite the fact that it’s adding unnecessary complexity. Fortunately for the user, most of that complexity can be absorbed at build time using server side rendering (the client doesn’t even need to have react if the site is truly static).
It doesn’t matter that you have now moved your HTML into a transpiled javascript syntax that spits out a chain of javascript function calls which generates a javascript object that is then fed into a javascript library that builds an internalized DOM representation and, finally, translates _that_ into an HTML string (which, btw, is happening on a javascript powered server). The browser sees the same HTML + CSS that it might have seen if you had just served them a hand written HTML file over Apache.
For some devs, KISS might actually yield an incredibly complex blob of javascript ecosystem goodies, that is at the same time simpler to setup and get started with than remembering how to structure an HTML file ;)
Maybe that's a more productive way for you to work. For those who aren't HTML/CSS purists, we have Gatsby and absolutely no reason not to use React and all its productivity benefits in any and every web project we want, including landing pages. I'm ranking SEO pages and driving paid traffic just fine.
Again, another React enthusiast assuming I’m a purist. I’m sorry my comment made you froth at the mouth. I’m not a HTML/CSS purist. I made a point of saying that.
What ever works for you but until you can prove that it “works just fine” by showing your organic traffic and cost per click, you’re not convincing anybody. Otherwise, what’s the point in your comment?
The point of my comment is to tell you that you're wrong by saying React is not appropriate for a landing page. Gatsby (a static site generator) provides equal or better performance than regular HTML/CSS. You apparently have only heard of Gatsby.
Even though I built my site in React, the end result is minified HTML and CSS. So out of the box using Gatsby and React, I have a faster site than you because I have minification. Of course you can also set up minification. Of course this has nothing to do with React. It has everything to do with what organizations like Gatsby are doing, which is just part of the React ecosystem.
You're scaring people away from adopting the React ecosystem. I'm writing a comment because I need to provide a counter argument for future readers of this thread, not to convince you to use React.
I started blogging on my Gatsby site in January for my business. I get a 98 on PageSpeed and rank for all sorts of keywords. Here's my organic traffic: https://share.getcloudapp.com/RBuv7bWw I'm doing this by myself and I'm happy with results. The idea of switching to writing pure HTML/CSS as some sort of benefit would be completely idiotic to me.
I can develop faster in react than static html... Once you need a/b testing you're screwed with the static HTML. You got to start adding more logic in your spaghetti Js and then you can't even reuse html. Boom, looks like a mess now
1. I’m using that much JS
2. Said JS is spaghetti
3. My split testing tool needs integrating with my ‘spaghetti JS’
4. I’m creating enough landing pages the overhead of duplicate HTML/CSS is high
In reality, if I’m starting out quick:
1. I’ll use little JS because it isn’t necessary
2. The JS I do write isn’t large enough to become spaghetti
3. I’ll duplicate it twice and rethink if and only if I need yet another similar LP
4. Use an off the shelf split testing tool because they work and I need to move quickly
The faster I can get traffic to my landing page, the sooner I learn. On a new business, I’m starting from nothing. So HTML/CSS it is.
The most problematic assumption you’ve made is that if it’s not React, it’s spaghetti. I see this line of thinking trotted out by many React enthusiasts. And maybe for sufficiently complex frontend projects, there’s truth. But you know what also eliminates JS spaghetti? Not using JS unless it’s necessary. It’s possible and desirable to use as little JS as possible.
For example, if I want to generate leads, I need at least one but maybe all of these CTAs:
1. A form
2. A phone number / call button
That’s it. Where is the need for JS here?
Now if you told me your landing page included a full interactive demo of certain features of a SaaS product, which sounds cool and worth testing, I’d entertain using React. But that’s assuming all landing pages I ever need to create are for SaaS sign ups. Even for a SaaS, that assumes the conversion is a SaaS sign up. Right off the bat, a SaaS might (and probably should) want to:
1. Increase mailing list sign ups
2. Generate leads for higher priced plans (or all plans if you need to talk to sales)
3. Offer a free resource and retarget
Where’s the JS here? In both cases, it’s a form or a button at most.
As I said in my original comment, I’m not one of those that discounts SPAs. It’s useful and I’ve had great results. But if I’m outsourcing an LP, and the proposal outlines React as a solution, I’m gonna pass. Wrong tool for the job.
> The most problematic assumption you’ve made is that if it’s not React, it’s spaghetti.
This is the biggest problem I keep seeing in the conversation... Tons of people assuming that vanilla JS has to be crap code. In reality, I've worked on MANY well-documented codebases with large JS cores that are custom. Yes some are gross, but some are very simple and easy-to-follow even when I'm 100% unfamiliar with the codebase.
Honestly I get it - having an opinionated framework is awesome when you're working in large teams of varying skill... but if this is aimed at "startups" like it touts I have zero tolerance for increased complexity because "ECMA without React is 'spaghetti'" or "this will handle the feature creep better" - both are a faulty basis for inclusion of a major/opinionated dependency.
For a typical landing page, you're not going to have a lot of JavaScript code anyway, and each chunk will only be doing a small thing (e.g. analytics, submitting a form) so there's not much scope for spaghetti logic. On a similar note, I'd rather code in TypeScript over regular JavaScript but for a typical landing page it's not worth complicating the build process by adding TypeScript.
This is exactly what I was trying to say in a fraction of the words :)
I prefer TypeScript. And I enjoy using it with React. But I cannot justify the overhead of the build process and, if react is included in the artefacts, the asset overhead.
The main assumption is that I have lots of landing pages. But I’m commenting on a landing page template, which I can only use on new landing pages. And in that event, I don’t have loads of LPs, I have one, the one I’m building.
I’ve not used those to give an opinion on their outputs. But if you can use React in way you produce a minimal, static build of an LP, that’s okay. My main argument is that a sales LP doesn’t need the interactivity React was built to provide.
And if I’m driving paid traffic to an LP, every part of it has to justify itself. Because, otherwise, not only will my conversion rate suffer, Google will charge more per click for a lesser quality landing page.
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.
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.
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.
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.
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?
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.
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.
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).
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.
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.
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.
Thank you for open-sourcing this and sharing it here. I'm sure a lot of people would find this useful.
That said, I wouldn't recommend for people looking for readymade landing pages to use React (or any other such framework) UNLESS they're already familiar with it. Otherwise, it would be a waste of their time -- setting up the development environment and then deploying it.
For such a case, it'd be better off writing some HTML and CSS by hand (maybe with some help from Bootstrap or any other such framework), push it to some git repo and throw it at Netlify. It's easy and free.
Now, this is obviously just my opinion. So, please don't feel obliged by it in any way. However, I'd be glad if someone just told why I might be mistaken; and how React would make for a great choice for this kind of projects?
If you want to use React, use something like Nextjs or Gatsby to compile it into a static HTML website.
Gatsby doesn't compile to a static HTML website. It compiles to a static site. There's a subtle difference. The pages are rendered on the server and served as static assets, but the entire React routing and content loading is still there. When a visitor loads a page it renders and then gets turned from plain HTML back in to a React again. When you navigate from one page to the next all the content for further pages is preloaded. You are not loading a full HTML page for each link you click on (which is exactly what makes it feel so lovely and fast - everything is being preloaded behind the scenes).
I've built API powered React sites with almost no consideration for SEO that Google has indexed without issue. My experience has been that as long as the API requests for content are quick Google is happy to wait and index correctly as expected. YMMV obviously.
Single-page apps (SPAs) using client-side rendering (CSR) like React do get indexed by Google, it's just not instant. Depending on how long it takes for the content to load, the Googlebot might not be able to figure out the correct on-page SEO.
If SEO is a critical requirement, I'd recommend either server-side rendering (SSR) through a framework like Next.js or completely static sites through whatever framework you prefer (Next.js, Gatsby, 11ty, Hugo, Jekyll, etc, etc).
The site looks great but you should have used a static site generator (like GatsbyJS) or at least a server-side rendering framework (like Next.js[1]) rather than create-react-app.
There is no need for this kind of website to be generated client-side.
[1] The latest version of Next.js does static site generation. Which is trully fantastic: you get all the power of React but the site is served as HTML. The generated site can even be accessible with JavaScript disabled!
As others have pointed out, you could use a static html page, vanilla js, etc, but ignoring this, I see value for future learning. Sure, there are alternatives, but it looks like the industry wants React skills. I've never used React, and I'm pretty new to web design, so this makes me interested in learning. It's a small project, one which I could modify and study.
This is how I got into making my own website. I came across BMFW [0], and studied the CSS file. I styled my plain html, adapted their CSS, and then kept going, finding inspiration from other sites and projects along the way. Almost 4 years later, my site [1] is a lot better, though still not perfect or finished.
I plan to download this React template, and use it as a learning opportunity. I'm definitely more interested in learning Vue or another hipster ass framework, but at this point I've done zero learning. Gotta start somewhere.
On a 30mb fibre connection, I'm seeing 4 seconds TTFP (Caching disabled in Edge)
I love react as much as the next person but for a static site that doesn't present me a Map/Game/Shopping interface I would personally have clicked away before 4 seconds.
While maybe slightly curt, I do echo this statement. Nothing on the demo page displays anything you couldn't do with a static page. Using tools devs are familiar with can often be good, but here it's hard to see the benefit.
eh, not necessarily, you could claim using a popular framework has it's benefits. It's easier to transition it to a full app whenever the time comes. The author could've chosen something less hip?, sure, but again React is widely used and it has proven to be useful in many app scenarios.
Why not? It's the most popular UI framework. The second you start building a SAAS product on top of those pages, you're not going to want to be in vanilla land.
Because you want your landing page to load instantly and React or any other JS-generated site just can't compete in loading speed with a static HTML page.
Uhm, probably not the best idea to mix your saas application, with your business website. I would definitely not recommend that.
And i will also echo the other comments, saying that this is definitely overkill. If you're doing a single landing page, jsut go with static html/css. If you need some content management, then either go with a fully fledged CMS or do the hipster thing and compile into static site.
Because you need a bit of CSS knowledge and to know how intersection observers have to be configured and then everything works with few lines of JS and CSS ... it's lightweight and SEO friendly and not bloated as if you use REACT.
And don’t get me wrong, I like React. And the projects have used it on have impressed clients beyond what we could achieve with just using backend HTML templates. But for a landing page that you’re driving paid traffic to? Not a good use case at all.