So far, the experience has been absolutely wonderful, particularly, given the context of myself as a developer in the whole process, which is,
1. I am a seasoned developer, mainly doing python stuff, back-end servers, desktop applications, data applications, etc. Very little exposure to front-end tech.
2. I keep myself updated with the concepts, patterns & architecture of front-end systems, because I am extremely into design and good UI.
3. I am at a stage where I can do basic web apps with Vue, React, Angular & vanilla HTML and JS.
With Angular Signals and concept of Stores, Services and Dependency Injection, I am able to handle data flow very easily, am able to add features to the app in a consistent manner, able to debug and trace errors with relative ease.
I have earlier read NextJS docs, Remix Docs and read tutorials about developing react apps using Vite. It has always been a confusing maze of stuff. Perhaps I am getting old (about to touch 40), but I have been programming for about 25 years now and I was able to carve out the architecture I want in an Angular app with ease.
Also, this app is going to be a production app, and is critical for my work, so its an impactful decision, which, thankfully, I have been happy and pleasantly surprised with.
It could be that I could have chosen React, and end up with the same thing, but, somehow, in the extensive tech stack selection process that I took up before committing to Angular (which involved testing out core mechanisms of the application in React, Vue & Angular), I felt very much at home with Angular way of things.
I was in the trenches pre-ES6 with JavaScript and JS/CSS since the year they came out, so of course I do love KISS-style bare-bones websites when that is the proper tool for the job. But certainly not for anything at scale. Angular, being a framework and not a library, is perfect for those purposes. I prefer that it IS opinionated (no "what router does this project use?"), and I also would not develop anything these days without TypeScript (even small sites).
To each their own.
I recall back in the day when Struts was everywhere, some of us figured out it was because Struts was a trap that took twice as many devs to get anything done, and that's why there are so many openings for it. Every time I look at React, I just wonder if it is the new Struts.
The old Angular apps I worked on (heck that was before AngularJS and Angular split) was pretty decent. Long argument lists were a big problem, sure, but the whole Service layer was one of the smartest features I've seen in a framework in a while. Second only to Routes. It saved us leaking a bunch of impedance mismatches across the entire codebase. It gave us some place to stash code while we asked the backend team to change their APIs.
The previous model was that you simply have code that runs on a server when a request comes in, sends a response to the client, and then the code in that response is run on the client. Instead, now we have a situation where some bits run on the server, some of them on the client, which call out to some bits on the server again, and all of this can happen either before or after the server started sending the response. And then on e.g. Vercel, you also have edge functions as an additional permutation.
Which is kinda neat, but also massively complicates the mental model.
This true to most software projects that are used more than one set of people. Joe Armstrong proposed a solution that we should opensource functions only and people could assemble everything else using these opensource functions. I start to think that he might be right and instead using "frameworks" we should use these set of functions instead.
The ammount of functionality is not the problem.
The problem is that the functionality is not a set of composable functions and classes. It's an inversion of control "framworky" blackbox, where behavior is hard to reason about.
I'm about to start building an e-commerce site (30-50k poster print designs, i.e. no inventory), and was leaning towards a Django backend (because I know it) and... some sort of SSR frontend. I'm not really a frontend guy, but taking this as an opportunity to learn it. This article obviously does not inspire confidence in me choosing Next.js - would someone have any suggestions/pros and cons of what to use?
I currently see the options for doing SSR as:
- Next.js: well-represented in AI training data (though recent versions had breaking changes? I'm not sure), but annoying to actually use (according to this article/general sentiment I've found online), and pushes you into Vercel? (I barely know what that means)
- SvelteKit: best DX and nice to use, but might be less present in AI training data?
- Django templates + HTMX: possibly limiting? Less maintainable once you get to a certain size? I'm not sure.
- Other options?
If you insist on rolling your own, Django + templates should be plenty. Lots of existing code for integrating Stripe or whatever. AI will be fine at it. You could potentially investigate medusajs or prestashop. Here's a list that could be fun to investigate: https://github.com/awesome-selfhosted/awesome-selfhosted?tab... but keyword is fun. You should build it in wordpress because that is a bombproof solution running like half the internet and will save you endless amount of time.
If you're doing this as an exercise to learn a new tool, leave the AI to the side as you're robbing yourself an opportunity to delve into docs and gain more domain knowledge. And absolutely do not touch nextjs with a 10 foot pole, it's an absurdly overwrought tool. The only people that should learn nextjs are people working at dev houses that churn out a shitload of full stack apps for clients that have the budget to shell out for vercel's hosting costs. And even then imo they should just be using django + react + vite + tanstack MAYBE.
HTMX is cool but I'm not sure the point, again if for fun why not, but I would ask yourself: you get your site up and running and you spend the next year scrambling around putting things in boxes and printing shipping labels, and then in 2026 Thanksgiving right before the holiday rush something breaks in your app and you want to fix it but HTMX/nextjs/whatever have gone through 2 breaking change upgrades and so have 4 different libraries they rely on and actually the most up to date version of two libraries you rely on are not interoperable right now because they depend on different node versions or some other bullshit, and now what do you do?
Just use wordpress.
- I used the product variations feature, 18 variations per product, and all of a sudden the "Duplicate" button took 15 seconds! I learned this is because each variation is it's own thing, so it was making 18 new things (still insane it took that long, on my beefy dev pc). I can't imagine 30-50k products * 18 variations * metadata stuff working fast in any way.
- In avoiding product variations, there's plugins for adding product fields, and plugins for pricing rules, but clicking around to do stuff, or maybe writing php that integrates with plugins that I'm clicking around in... it's not the way I want to spend my time developing. It especially integrates terribly with AI tools, which at this point are an important development tool for me.
- I don't want to have a 1-to-1 mapping between products and pages. This doesn't fit the WC model well (or Shopify for that matter).
Generally, I can imagine an experienced wordpress/PHP dev being able to overcome these issues, but if I'm learning something anyway, I'd personally rather learn a proper frontend framework (be it any of the options you mentioned). Leveraging AI tools also matters.
I appreciate your response! Gives me more confidence in maybe sticking to Django + templates. But from what I've seen, and also in discussions with other developers, I think wordpress is out for this project. Thanks again :)
> and so have 4 different libraries they rely on
HTMX has no dependencies. https://htmx.org/essays/vendoring/
> and actually the most up to date version of two libraries you rely on are not interoperable right now because they depend on different node versions
HTMX has no build step. https://htmx.org/essays/no-build-step/
Do what gets the actual job done: focus on the selling, not the tech of the shop. Grab a template and adjust it to fit your marketing.
Actual useful tech is integration with a printer/printshop. Or getting packaging labels automatically for orders. Or using AI to make new posters.
It lets you ship client islands to the client, which AFAIK is essentially partial hydration.
Katie Sylor-Miller named them when she was at Etsy and from memory they were React components in a PHP page to start
Use Context7 mcp to get Svelte 5 docs if the agent messes up something you know should work.
The new experimental remote functions solved a big pain point with sveltekit, so I no longer have any reasons not to recommend svelte and sveltekit to people.
Once you know what is actually going to be on your site, you can style the output with CSS and add the necessary interactivity with JS. Browser APIs have mostly standardized as compared to the bad old days. Using them directly instead of libraries or frameworks will keep your site lean and fast.
All of your CSS, HTML and browser API knowledge will continue to serve you for the years to come. In a few years, people will be arguing about a new magic framework.
Theres some things to learn but once you do its amazingly simple and powerful.
That said I havent tried Astro, Nuxt
So many things built in ready to go.
You want to use something full of abstractions to the point you have no idea how it actually worked.
You did this to save time.
Then when issues occur it's someone else's fault.
That said, let me pass in a flag to get my dev logs in prod. That's ultimately what the author wants.
I've encountered issues based on Nextjs in a few projects where the best approach was to eliminate it.
The outcome was nicer and higher development satisfaction.
If you dare to say that you had to get rid of Nextjs from a particular project, during a job interview, you're done!
Possible follow up questions:
- what led your team to want to remove it? - what was involved in removing it? - what did you replace it with? - what makes the new thing better than the old thing? - how did you evaluate that spending X days/weeks/months to remove it was worth the time that could have been spent on developing features?
I think all frameworks and tools have their time and place, and knowing when and how to use them is important.
If a company can't understand this then I wouldn't want to work for them.
For me, it isn't a framework I want to use in any production environment. Your system is too much depending on something you have no influence on. Like in your own code, it is good to decouple, don't make things depend too much on something, not in your own code, but also on external code like frameworks and libraries.
That is why I prefer to build things like I can (kind of) easy drop my dependencies, for what reason, and use something else, or build it in my own codebase. If some framework doesn't allow it, and you have to work it their way, and is the base of everything, that should be a big red flag.
Unfortunately incompetence of developers to see beyond has brought the web to the point that every React developer has dealt with Nextjs at some point.
What are the alternatives beyond Vite and Remix?
On more than one occasion I’ve seen someone refer to Vite as an alternative to Next.js. Isn’t Vite a bundler and Next and Remix frameworks? How is Vite an alternative to these?