Remix.run Logo
entropichorse 7 hours ago

People who built a crappy website using React are just as likely to build a crappy website using Astro, HTML-first approach or any other technology

wmanley 6 hours ago | parent | next [-]

I disagree. An HTML website which uses links, forms, buttons and inputs will by default:

* Have working back/forward buttons * Have working progress indicator as provided by the browser * Show errors to the user - even if they are ugly * Be accessible to keyboard navigation

With SPAs these are all things the developer has to get right.

So often when using a SPA I'll click a button, you get a spinner and then nothing will happen. Is it still in progress? Don't know. Eventually I'll open developer console and trace the network requests to find the JSON HTTP request that returned "ERR_BAD_EMAIL" and fix what I've entered. With a normal form submission at least the user will see the error message and can press back and then fix it.

adjejmxbdjdn 6 hours ago | parent | prev | next [-]

True. Crappy developers will build crappy websites irrespective of the tech.

The article is clearly aimed at non crappy developers or developers who want to do better for their users.

And it provides an anecdotal experience where an HTML first option developed by a good developer was far superior to what a JS necessary option would have been, given the user base of this application.

someonebaggy 7 hours ago | parent | prev | next [-]

At least it'll be a fast and crappy website.

nicoburns 6 hours ago | parent | next [-]

It's definitely possible to make slow server-rendered website. Most of the slow client-side apps are slow because they're waiting on slow network requests.

(I still very much support fast, simple HTML websites. The good ones are a fantastic user experience)

trashb 6 hours ago | parent [-]

but the host (the company) will need to pay the price in the form of server equipment. Not the user as is the case with client side rendering. If server side rendering becomes slow it will affect all users regardless of their hardware or connection, prompting earlier response from management and devteams.

nicoburns 6 hours ago | parent [-]

The cost difference between client-side and server-side rendering is pretty non-existent these days.

cyanydeez 7 hours ago | parent | prev [-]

yeah, I love when shit loads immediately, so I'm not wasting seconds of my life just to see shit.

elxr 5 hours ago | parent | prev | next [-]

I agree. Server-rendered React can also send down 100% HTML apps.

But I 100% see where the author's coming from, considering the massive fragmentation of react codebases/patterns and decision paralysis of React development in general. I really doubt most React apps, even the more accessible ones, are testing their multi-page form wizards with JS completely turned off.

HTML-first does seem highly underutilized in the commercial web, and I learnt a lot from reading this (as a solidJS/react dev).

hyperhello 7 hours ago | parent | prev | next [-]

You can do a bad job with any tool but you cannot do a good job with any tool.

swiftcoder 6 hours ago | parent [-]

This is patently untrue, give a craftsman terrible tools, and they'll still produce a decent end result. That said, defaults matter, and astro is going to be significantly more friendly out-of-the-box to low-end clients

whstl 5 hours ago | parent [-]

> give a craftsman terrible tools, and they'll still produce a decent end result

This is an absurd statement. Just because something is a proverb, doesn't mean it's automatically true for all cases.

swiftcoder 3 hours ago | parent | next [-]

> Just because something is a proverb, doesn't mean it's automatically true for all cases.

A professional woodcarver armed with only a metal spoon will still make a nicer woodcarving than I can given a full wood shop. Similarly, if you only give me notepad.exe, I can still make a pretty nice website.

Does using the right tools make our lives easier? For sure. Using mildly-wrong tools (react, in this case) isn't going to hold us back very much though.

8note 2 hours ago | parent | prev [-]

i dont think thats a proverb though? the actual idiom is more like

> A poor workman blames his tools

which is towards the opposite meaning

manuhabitela 5 hours ago | parent | prev | next [-]

I find it's way easier to build crappy React apps than an HTML-first approach.

An "old school" Ruby on Rails/Symfony/Django app, with templates, usual get/post forms etc, frames you and pushes you in using the standards and relying on browser default behaviors.

In JS-heavy apps, it's as easy to code normal `button` elements as it is to code clickable `div` elements. But with the divs you just forget to handle keyboard nav, proper element roles, etc. It's easy to create fake links, not relying on `a` tags, using an internal JS router that doesn't expose URLs, doesn't handle middle click mouse, for no particular reasons.

In less JS-heavy contexts, the easiest way to do is to use proper HTML so you are less inclined to mess up.

Even on codebases that use a decent framework like Next.js that handles those for you on paper, it's often we see people not very aware of the benefits of using proper semantics and standard behaviors, and you easily end up with web apps with poor UX in the end.

malteg 6 hours ago | parent | prev | next [-]

true, but where can I find the smallest functional react website where react is needed...?

afavour 7 hours ago | parent | prev | next [-]

Not really, no. Astro requires you to opt a component in to client-side rendering, React (with its server components etc) require you to opt out. Defaults matter in scenarios like this and I'd bet the average developer of crappy websites would have a much faster site with Astro than React for that reason alone.

whstl 5 hours ago | parent [-]

Small correction: it's other frameworks that require you to opt-out, most notably Next.js. Although I've been seeing so many people confusing Next.js with React lately...

Astro itself works just fine with React, and it can still be HTML-only.

But you can also render React on the server yourself using renderToString, if you don't want a framework.

TSiege 6 hours ago | parent | prev | next [-]

with this logic, why discuss any technology?

bschmidt300 6 hours ago | parent | prev [-]

[dead]