271–280 of 533 posts
Earlier quoted context omitted.
But on the flip side, you can program the backend in anything you like, instead of being bound to javascript.
JS/TS is fine. Why switch back and forth between languages and frameworks and data models and…
I truly wonder what people do when they want JS full stack both frontend an backend especially with a DB involved. ORM situation looks pretty fragmented or you write pure sql. And then you still have to decide on the backend. Going raw with express? Next.js, well known, but with a questionable agenda (, Remix, Astro, TanStack, and so on. It's a mess, because you always have to recalibrate and re-evaluate what to use.…
Yep. The ORM situation in JS is not great. There’s no one go-to, and it seems like the question often prompts a patronizing response about how ORMs aren't really necessary. Kysely is really great, but it’s not an ORM. My take: the JS ecosystem tends to avoid abstraction for whatever reason. Example: they don’t believe that their web framework should transparently validate that the form submission has the correct shap…
Someone will steal the good ideas eventually. And everyone will act like it’s the first time this idea has ever come up. I’ve seen it happen a few times now, and each time it makes me feel ancient.
Earlier quoted context omitted.
You can accomplish the "don't have to reload the page to see my changes" with htmx and it's still "server-side rendering" (or mostly server-side rendering). Legendarily, the fastest website on the internet uses partial page caching to achieve its speed
What do you like about HTMX? I coming from a world of plain JS usage -- no SPAs or the like. I just felt like HTMX was just a more complicated way to write what could be simple .fetch() requests.
You write:
Send
Send
async function handleSubmit(event) {
event.preventDefault();
// the form submit stuff
const form = event.target.form;
const formData = new FormData(form);
const submitter = event.target;
if (submitter && submitter.name) {
formData.append(submitter.name, submitter.value);
}
// hx-put
const response = await fetch('/foo', {
method: 'PUT',
body: formData,
});
/ hx-swap
if (response.ok) {
const html = await response.text();
// hx-target
const target = document.getElementById('moo');
const temp = document.createElement('div');
temp.innerHTML = html;
target.replaceWith(temp.firstElementChild);
}
}
Earlier quoted context omitted.
I still have some ptsd from payment gateway integrations via iframes about 6-7 years ago. If you thought SPAs are bad by themselves for history tracking imagine those banking iframes randomly adding more entries via inside navigation/redirection that you have to track manually.
A lot can be said for just putting a "back" button a page. I still do it occasionally for this very reason. Then again, my user base for the apps I write are the most non-technical folks imaginable, so many of them have no concept of a browser back button to begin with. I am not being hyperbolic either.
We used NextJS on a couple of projects where I work and are already phasing them out. The reasons are manifold, but a few key factors: * difficult auth story. next-auth is limited in a few ways that drove us to use iron-session, such as not being able to use a dynamic identity provider domain (we have some gov clients who require us to use a special domain). This required us to basically own the whole openid flow, wh…
What did you move to? We've been using NextJS as a frontend with somehelpful server-side/api handling, but the backend is done in Django. We are basically just using ReactJS with the convenience of NextJS (like file based routing)
I can't speak to the technical aspects here (I'm only familiar with nextjs not rails, so it's unclear to me how much of the article is just a reflection of the author's own comfortability with rails or a reflection of a more technically suitable architecture). But I do find it really weird that a company which apparently has multiple software engineers is worried about infrastructure costs amounting to less than $1k…
Earlier quoted context omitted.
> As a user, the typical SPA offers a worse experience. Your typical SPA has loads of pointless roundtrips. SSR has no excess roundtrips by definition, but there's probably ways to build a 'SPA' experience that avoids these too. (E.g. the "HTML swap" approach others mentioned ITT tends to work quite well for that.) The high compute overhead of typical 'vDOM diffing' approaches is also an issue of course, but at least…
> Your typical SPA has loads of pointless roundtrips This is an implementation choice/issue, not an SPA characteristic. > there's probably ways to build a 'SPA' experience that avoids these too PWAs/service workers with properly configured caching strategies can offer a better experience than SSR (again, when implemented properly). > The high compute overhead... I prefer to do state management/reconciliation on the c…
Earlier quoted context omitted.
My biggest annoyance with SPAs is that they usually break forward/back/history in various subtle (or not so subtle) ways. Yes, I know that this can be made to work properly, in principle. The problem is that it requires effort that most web devs are apparently unwilling to spend. So in practice things are just broken.
An additional one for me is stale state. I can leave most webpages open for days, except SPAs. Especially on mobile.
Earlier quoted context omitted.
JS/TS is fine. Why switch back and forth between languages and frameworks and data models and…
What is 0.1 + 0.2 in JavaScript. I'll give you a hint, it's not 0.3. Is that fine?
I'm thankful that I don't work on projects that have SEO needs. SSG (for JS frameworks specifically) feels too unstable for me. I get the value, I understand why people need to do it, but it just makes everything more complicated. Also, I'm not sure if you can have an offline site with SSG? They might be compatible but I'm not sure. I know some SSG is essentially "SPA with the first page rendered already" so maybe th…