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