Show HN: Open – Free React landing page template
github.com
github.com
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.
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.
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.
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.
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.
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.)
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!
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?
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 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 ;)
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.
I kept my old ThinkPad just to test my websites.
That's really bad!
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 ;)
Maybe I'm naive, 90% seems like an extremely high estimation to me.
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".
"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...
KISS
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).
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.
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 can view it on my 11 years old N900 which is still my smartphone in daily use.
You reduce that risk by using more static HTML.
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.
Also, Next.js does static HTML export out of the box if that's your preferred end target.
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.
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.
I don’t. Please don’t waste my cycles and battery on pointless visual effects (unless you’re a vfx company).
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.
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.
Using React for a static landing page is like using a flamethrower to light a birthday candle.
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.
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?
Again, OP, thank you for sharing this with us!
Google bot runs JavaScript these days. I'm sure proper SEO is possible in the worlds most popular UI framework.
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).
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).
And Google has started to index SPAs[2] as well even though it's not instant like others have mentioned.
[1] https://reactjs.org/docs/react-dom-server.html#rendertostati...
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!
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.
You couldn't pay me enough money to post a "Controversial Opinions" section to a site that also links to my current resume on the same page.
It's best to keep this stuff separate from your professional life.
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.
hn: you did it wrong
Seriously, there are plenty of bootstrap templates that don't need react, quit complaining, nerds
These corporate sites are really the ones that should just be old fashioned HTML + CSS if possible.
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.