[jwdunne]

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.

[emagdnim2100]

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

[jwdunne]

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!

[doctorOb]

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

[lsalvatore]

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.

[jwdunne]

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?

[lsalvatore]

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.

[ttty]

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

[jwdunne]

There are a number of assumptions here:

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.

[peterangular]

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

[seanwilson]

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.

[jwdunne]

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.

[adamqureshi]

Damn good stuff here. Can you build me a landing page to test a new business? :-)

[jwdunne]

Let’s talk, [e-mail] :)

[moneywoes]

Thoughts on Gatsby or Next.js for React landing pages?

[jwdunne]

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.