I still can't get to grips with the islands directory causing separation from my other components, it feels weird because both islands and components are components, I think Next.js' approach of having a use client string at the top of the interactive component makes much more sense because your component directory structure can mimic the app/pages directory layout.
Honestly it's the only thing keeping me from jumping over to Fresh.
There is a WAVE browser extension and some others, you can also use one of the screen readers yourself. I think that’s actually really helpful. I haven’t done that in a while but I remember when I did the screen reader functioned pretty differently than I thought it would
Yeah definitely. Someone sent me a pretty good article that recommended that you use a screen reader a little bit on your own stuff, one for making sure it's accessible, but two because it teaches you a different way to look at your design process.
IDK how much in depth time I'm planning to commit to this whole thing but I do think applying a screen reader is necessary if I'm going to claim my stuff works with it. I can't really see it being all that effective just to apply the right classes and hints to the existing page and hoping it all works out without testing it...
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.
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
Web Development
Top