191–200 of 395 posts
Call me old fashioned, but PHP still gets the job done better than just about anything else.
And usually leads to a BBOM architecture
Earlier quoted context omitted.
I take it you haven't taken a look at backend lately. Vagrant? Or Docker? Composer? Maybe Drush. Will this plugin break? Is it even still actively maintained? Which database? Are we still on the NoSQL fad? Maria, or postgres or mysql? And does my production host support my language version, and oh god another php vulnerability
I have done nothing but backend for a decade. Docker's been around for the past 6 years and still going strong. Database? Postgres, always. You have to bend it so far until it breaks it's not even funny. If you need something else, you'll now. Backend lang? Python. Framework? Django. Need data munging? NumPy/SciPy/Pandas/PySpark. Need a really high speed component? C will do, Rust if you feel fancy. OS? Ubuntu, or De…
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…
It's pretty hard to compare some random free PHPBB running on a underspec'd host to companies with billions in revenue to support their platform. Honestly, reddit and HN are so simplistic, there's not much added by JavaScript doing any rendering. Reddit in particular is horrific. Their API is slow, and their JS bogs down on anything that isn't a super-fast desktop. Server pages would be able to handle most of what th…
I'm on a $1000 4 year old laptop. Initial render on home page is under 3 seconds. Comments load in under 2 seconds,
Hacker News is faster, but Reddit is the next best thing.
This is all w/o ad block, new reddit UI enabled.
With uBlock Origin enabled, it is marginally faster.
> It's pretty hard to compare some random free PHPBB running on a underspec'd host to companies with billions in revenue to support their platform.
My comparison was random free PHPBB to random free BBS hosted on dial up in the 90s. Up until the late 201xs, random free 90s BBS performed better.
Earlier quoted context omitted.
> documentation sites, blog-like sites Sites like those can often be fully static sites. Process the docs or the blog posts into HTML. Nothing is generated at runtime. Of course you can cheat a tiny bit, like putting the date in the footer, or cheat a lot. Life's a lot simpler if you don't cheat at all.
I had a website which I was rendering statically using Jekyll. Overtime I had millions of pages, rendering was getting too time consuming and was taking up far too much of space. I then moved on to PHP. Worked like a charm with $15/mo server on Google cloud. Excellent search performance as well.
You could imagine a distributed build system for this that would build it really fast for competitive price on any ci/lambda/batch system.
The fact we barely hear anyone talk about this is the strange twist of history the parent made.
Earlier quoted context omitted.
So adtech is ruining the web. Everything makes sense now.
Adtech represents the ruthless financialization of human attention, so it's not just ruining the web, it's ruining society.
There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of co…
After many years, front end programmers forgot how to build their own hooks and came to rely on automated views. Then they began to forget how to parse models and build controllers. Why not shuffle all that off to the back end anyway?
One nice thing about rolling your own front and back ends is that you can determine when or if each individual subcomponent needs to update its visual state. Often this is very useful in managing the actual server load, but it requires understanding who needs this data immediately and who can load it lazily long after a page loads, or the other data updates server-side, not to mention whether it also has to become readable across a distributed or federated data structure.
So after all the modern conveniences, server side rendering impoverishes both front and back end coders in the name of curing a problem with data transfer and efficiency that is far less of a problem than that of overly tight bindings between front end states and back end data storage.
Anyone can write a tightly bound backend model/view/control.. it's a fun project. It's a horrible architecture.
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.
SPA+SSR has never been easier, and my experience (as of this year) is that its as easy as static websites. Even easier in some cases with making the CSS easier while all the bundles and optimizers to make builds are hidden.
I think people need to rethink how they design their websites and complete concept of a viable business.
I get the sentiment of the absurdity off web development but its successfully been abstracted away if you keep your app and idea simple. If you’re still doing gigantic web 2.0 apps with hundreds of views, microservices everywhere and API calls going every which way, thats the problem. The stack for those is ridiculous and not even necessary anymore. You can drive [hundreds of] millions of revenue without any of that these days, without even a user account flow or state management, the market is trying to tell you something.