91–100 of 395 posts
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.
Earlier quoted context omitted.
I have colleagues using Laravel, and there's nothing muddy-ball about their apps at all. Their code is tidy, modern, readable, and clearly maintainable. In terms of practical effect, frameworks influence developers more than languages do.
The idea of using a "framework" in a language that gets completely reloaded on every new request doesn't make sense - at least I thought a framework was something that wrapped your own code and presented an event loop, etc. You'd want a "library" if you just wanted to improve on the original low quality PHP database connectors and such. But PHP developers always did seem to have inappropriate jealousy over unrelated…
Earlier quoted context omitted.
I'm not sure what about two bundles causes a huge level of complexity. Granted, I use Next.js, it does all of this out of the box. SSR is fast, it's provably faster than client side rendering for first load. You can optionally do client side hydration, so the time to meaningful content is fast from SSR, and subsequent page loads are done SPA style (if you want). It's never a fair comparison, but Stackoverflow is enti…
> 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…
You mean when you had the same internet speed 10 years ago, right...?
See https://remix.run for a modern, sane, progressive approach to server-based rendering w/ as-needed hydration.
How can a small site like HN possibly work when SSR is so complicated?
It's confusing I know.
How can a small site like HN possibly work when SSR is so complicated?
Earlier quoted context omitted.
I have colleagues using Laravel, and there's nothing muddy-ball about their apps at all. Their code is tidy, modern, readable, and clearly maintainable. In terms of practical effect, frameworks influence developers more than languages do.
When people say they use "PHP" for webdev I recall BBOMs of flat files and raw SQL. Historically speaking, "PHP" does not necessarily imply "PHP+Laravel" or any other sane framework. OTOH if someone says they use "Python" for webdev I assume Flask/Django/etc.
The common mistake teams make getting started with server-side rendering for React is thinking that your entire backend has to be contained in a single JavaScript bundle. Instead, use any language you want to set up your APIs and business logic. Then set up a fully independent pool of servers running Node.js whose only job is SSR. This setup skips over every problem the author mentions.
If your API server is separate from your Frontend server, you don't just make maintaining it more reasonable (the "server colored functions" are now a strict subset of the "client colored functions"). You also get operational flexibility: run the Frontend server in an edge function system [1], while running the API server alongside your DBMS. Isn't that what edge functions are for?
One is easy, the other is the definition of leaky and crappy abstraction. This article is about the latter technology.
Earlier quoted context omitted.
I have colleagues using Laravel, and there's nothing muddy-ball about their apps at all. Their code is tidy, modern, readable, and clearly maintainable. In terms of practical effect, frameworks influence developers more than languages do.
This was my PHP experience with CodeIgniter 15 years ago. Nothing new under the sun.