Hacker News Reader

Comment by young_unixer | Hacker News Reader

I have a very good idea of how the web used to work 10 years ago.

But when I try to learn Modern Javascript frameworks, the tutorials rarely do a good job of explaining that they won't teach me how to create a normal, traditional website, or if it's even possible to create a normal website with the framework. They simply assume that the modern way is the standard way.

I want a modern alternative to PHP, but the JS community doesn't make it easy to learn JavaScript.

At least I know how things used to work. Imagine a newbie that never developed a normal website and now thinks React/client-side rendering is how the web is supposed to work. They won't even be able to understand the tradeoffs being made for them.

I want a modern language and framework that still makes sane decisions, and when it does weird things (e.g. client side rendering being the default) at least tells you upfront that it's making those decisions, and their implications.

View on HN

> Imagine a newbie that never developed a normal website and now thinks React/client-side rendering is how the web is supposed to work.

I had the luck of learning the web "the old way" at the university. First HTML, then CSS, then PHP where we cobbled together a small website (our end projet was a recipe website where you could create an account and post recipes, so there was database usage too). All of this was made in WAMP/XAMP. We had a course on JavaScript the next year but I honestly didn't understand anything. Some time after though, when I started working again on the web, having an understanding of HTML, CSS and what you had to do by yourself made me understand fundamental web technologies on a deeper level than most of my peers that started with the MERN/MEAN/MEVN stack. I'm sure they'll be more attractive to employers though.

> modern alternative to PHP

Try...well, PHP. It's pretty modern now and a lot better than it used to be.

I'm not a PHP guy but I do have a few sites running on it and it's nice to go back to my roots.

There's nothing particularly weird about client-side rendering (at least, it's no weirder than server-side rendering was in the era when most pages were static data).

It could, of course, be considered "weird" if one's mental model is that patching together document description declarations on-the-fly on a server to later be re-interpreted and rendered on the client is "normal."

I can't imagine a more suitable recommendation than ASP.NET 5.

Server-side Node.js still exists and, if you like, can be quite similar to good old PHP. A "Hello World" app in Express.js is pretty barebones and easy to get started with, and there are probably lots of comparable alternatives. I've always found Express.js to have a big community with lots of guides and info, although I admittedly haven't had the experience of coming to it as a newcomer to programming or the web.

This is something I'll never understand: Isn't the only selling point of JS that it runs on every web browser? Why would anyone want to use it (or, in 2021, PHP) on the server side, where you can use any language you want?

Hah, I've been saying the same thing for years. It bothered me even more so because I was a Perl programmer and everyone kept saying how messy Perl code is. But they want JS on the backend?!

Server side blazor is actually architecturally elegant, and the implementation is quite good though not perfect.

The result is about 25% of the complexity of an equivalent react for the same app in practise for 90% of systems (ie excluding monty haul what if but usually practically irrelevant edge cases).

> Imagine a newbie that never developed a normal website and now thinks React/client-side rendering is how the web is supposed to work.

Actually you don't need to imagine it, you can observe this in the wild today, very commonly.

Reply on news.ycombinator.com