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