From the whole blog post, the thing that caught my eye was the side remark regarding SPAs vs MPAs. It was one of those things that people don't tend to think about it but once someone touches on the subject, the problem become obvious. It seems that modern javascript frameworks focus on SPAs and try to shoehorn the concept everywhere, even when it clearly does not fit. Things reached a point where rewriting browser history to get that SPA to look like a MPA is now a basic feature of multiple pages, and it rarely works well.
Perhaps it's too extreme to claim that MPAs are the future, but indeed there are a ton of webapps that are SPAs piling on complexity just to masquerade as MPAs.
as always, the answer is it depends. I've worked on B2B websites where you can't even see the real pricing until you sign in so it is impossible for that application to add a guest checkout. it really depends on your requirements.
This seems more like a business analytics kind of question than a programming question. But I'd imagine you'll get less sales without a guest checkout option than with if that answers your question.
You might manage to mitigate that a bit by letting folks fill their cart and start the checkout process and only require them to sign in at the last minute after they're already pretty invested in checking out.
For a static site, I would personally choose Astro or SvelteKit—both of those are highly optimized for static sites. In my opinion the syntax of these frameworks feels closer to plain HTML/CSS/JS than React and will naturally teach you more about the fundamentals as you go.
If you’re just starting out, the most important thing is to really make sure you learn your JavaScript Web APIs and other HTML and CSS fundamentals as you go. The better you know these, the better your websites will be regardless of which framework or tools you choose. These fundamental skills will have the highest reward for you in the long term.
Also, if memory serves, plain old HTML4 allowed you to load partial html files within a main page and they'd render as expected, which completely beats the reasoning behind the "why use web components" on the piece (reusability, maintainability)
More important than learning a framework is to learn how things work beneath the frameworks. Try doing a project without frameworks. Who knows. You might even like it.
I'm glad this style of frontend coding (where you use a prebuilt JS library that handles common interactions through simple configuration, rather than writing custom JS) is coming back into fashion. It was common 15-20 years ago, and as web apps became heavier and heavier, I started to think it was a good idea again.
I’m always kinda surprised when I see htmx. What’s the perks? I already have my stack, why should I change? I looked into it recently and it looked really unappealing
Bun is designed as a drop-in replacement for Node.js. It natively implements hundreds of Node.js and Web APIs, including fs, path, Buffer and more.
The goal of Bun is to run most of the world's server-side JavaScript and provide tools to improve performance, reduce complexity, and multiply developer productivity.
If it can replace node and pnpm at the same time then this sounds quite good actually.
While Vite currently works with Bun, it has not been heavily optimized, nor has Vite been adapted to use Bun's bundler, module resolver, or transpiler.
So it can also do tooling like vite but it primarily aims to replace node as a better and faster js runtime since they're rewritten most js api in zig and c++ from what it shows on their github. I'll give it a try sometime and see if it's really all that fast and easy as it claims.
Web Development
Newest