181–190 of 395 posts
In Javascript SSR, if you need the same logic on the client and server, define an API module + interface. Make a different API bundle on the server that calls NodeJS functions, file reads, whatever, directly. Make an API bundle on the client that makes AJAX requests to your API endpoints. Now your Javascript can call the same `api.fetchWhatever()` method, and await the result, and it works on the client and server (i…
https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.
When fetching from the backend, the docs recommend returning snippets of html instead of JSON. Is it technically valid to return a snippet of HTML with a content type of “text/html”? There’s no standards saying you need !DOCTYPE or a head or body?
In this thread: people confusing server rendering (like your old PHP) with SSR (same Javascript codepath for client and server, i.e. Next.js) One is easy, the other is the definition of leaky and crappy abstraction. This article is about the latter technology.
> the other is the definition of leaky and crappy abstraction
Well that's just like, your opinion man.
How can a small site like HN possibly work when SSR is so complicated?
Ryan Carniato (@RyanCarniato) have a hackernews clone in every major framework with SSR support. Mostly made on streams as well!
See https://remix.run for a modern, sane, progressive approach to server-based rendering w/ as-needed hydration.
Remix has the exact same issue unfortunately: https://remix.run/docs/en/v1/guides/constraints
I was going to evangelize them at my current gig... thankful that I didn't go down that route and made my own prototypes. There are solutions (such as implementing your own caching layer) but ugh, why.
> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…
If that is the reason (I don't know) some element other than would be a much simpler solution.
I had a few ideas just now. It seemed the most fascinating to tie part of the query string to a div.
Then you have your usual
And your url example.com/?foo=demo.html
And from thereon shall only update that part of the url and that part of the document. If demo.html contains a or it is ignored if the target is a div. But something like with appropriate targets seems fine(?) Alternatively the querystring tie can be defined on the element. Older browsers when hitting will load example.com/?foo=second-demo.html
Earlier quoted context omitted.
My org just bought a professional bootstrap template. It takes 3 build tools and 1500 node packages just to build the SASS into a CSS bundle. It boggles my mind that this is normal in the front end world.
only 1500? you got lucky! gatsbyjs (React framework) has so many dependencies it breaks GitHub's dependency graph https://github.com/gatsbyjs/gatsby/network/dependencies
I already know I'm off my rocker (and my lawn with that phrasing) but I really wish the browser supported Python as a language instead of Javascript. I can pickle Python, send it to a client, and run it. Combine that with everything else Python 3 has brought to the table and I'd have a language that runs client side that I can depend on and that I love.
So, nothing is stoping us from tranpiling Python to new or old ecmascript.
But, I think you’ll see that it won’t solve much. You are just turning one turd into a lesser turd. The problem is fundamentally deeper. The browser and web server tech was not built for app development. That’s the bottom line.
Earlier quoted context omitted.
> Also, all forum software, which is SSR, despite being 20-30 years old, is usually faster than a SPA. Only because crap tons of hardware got thrown at the problem. I remember when forums were multi-seconds to load each page. It sucked. People complain about reddit a lot, but even on mobile, the reddit website is fast. It may be janky at times, but navigating between comments on stories is under a second, loading mor…
> I remember when forums were multi-seconds to load each page. It sucked. You mean when you had the same internet speed 10 years ago, right...?
I was at 5x that by 2010.
My internet speed didn't really improve from 2010 to 2021, (Comcastic!) then I got fiber. File downloads are faster (800mbit gets binary fast), web pages are about the same.
Servers have gotten faster, but ad tech had made crap slower.
SSR won't help solve ad tech garbage making pages janky.
Earlier quoted context omitted.
> Also, all forum software, which is SSR, despite being 20-30 years old, is usually faster than a SPA. Only because crap tons of hardware got thrown at the problem. I remember when forums were multi-seconds to load each page. It sucked. People complain about reddit a lot, but even on mobile, the reddit website is fast. It may be janky at times, but navigating between comments on stories is under a second, loading mor…
> People complain about reddit a lot, but even on mobile, the reddit website is fast. only on mobile is Reddit fast.
Yup, that was fast.
OK let me disable ad block.
Under 3 seconds to first render.
Comments appear in under 2 seconds.
Reddit performs very well. The new UI is legit faster. There is a bit of stupid here and there with it, and if you aren't logged in the experience is horrible, but speed is, IMHO, not one of the site's problems.