Isn't it much easier to know you're going to use React (or Svelte or Vue or anything else) and just start there? Starting a build in HTML-first only to bolt on a JS framework after the fact seems like a lot of wasted effort.
The whole point of this essay is to encourage developers to avoid heavy frameworks like React, Vue, etc and use "lightweight" tools, including vanilla JS and native HTML features, instead.
I once built a project-tailored combobox using Alpine.js - this is about where it breaks down.
It worked, it was a lot of fun to write because it went really fast, even with some bells and whistles. Whole thing was my escape hatch when datalist attribute didn't work. It also worked well.
Alpine JS feels like a simpler version of Vue 2 without a build step and without any of the complex or confusing stuff (and of course with a focus on HTML not rendered by JS).
But when I saw what this turned into as a BE colleague copied it to the next form, making some adjustments... oh my, I prefer external and reusable JS (or a JS-first approach to templating, like React) any day.
Still, Alpine is really awesome for minimal interactions and simple JS.
When working outside React, it's hard not to miss it for the simplicity of doing everyday stuff inline in the HTML.
Alpine is primarily designed to be reused via server templating. You use a single template per component to do the in-HTML side, using the server template's facilities to handle variations as necessary. Then you can factor out complex common behaviors into Javascript using Alpine.data.
It definitely does have a maximum size of project it's suitable for. In particular, it's thoroughly individual-component-based; changing anything outside the component requires tacking on non-native hacks, and doing a full interactive app with it would be a painful exercise. But for adding simple interactivity to a primarily server-rendered web page, I've found it to be quite useful.
Should have mentioned that I made a generic Blade component from it (it was a Laravel project)
Copying still happened, take that as you will - in this case that was the problem :) Might be my implementation was not generic enough, but tbh the colleague was not especially proficient at JS.
We had a productive conversation about this, but this particular project ultimately was lost by my former employer.
The reason was not this autocomplete component though :)
Sure, I'm just talking about that middle ground where you're trying to go with this approach and find that you now need a bunch of JS framework features.
are you trolling? 10 people in this thread have already explained that the point is to avoid using a heavy framework, yet you keep insisting that one is necessary.
I think the GP is referring to when people misunderstand the scope of their project, start without a framework, and the complexity reaches a point where the framework would actually help.
I'm not sure what that looks like, because if it gets complex enough it's a sign I need to refactor, imo.
It might be easier to staff for. But developing a React frontend takes way more time than just server rendering HTML and layering in JS for the vast majority of use cases.
I'm speaking from experience on a pretty wide variety of commercial web projects. Been building websites for twenty years. Frankly, it's not even a close competition. What I've found is that a lot of teams don't even track their time, so it's likely many developers don't realize how large the React penalty is. I would encourage devs to spike on both approaches and do a thorough accounting of their time.
