Your focus on things being "modern", which is no indicator of value except for hipsters and recruiters, made you forget about the third conclusion with which you might come away from setting up a monolith application:

3. Wow, this actually works. I am so productive and i can actually get my work done quickly, the same way as hundreds of thousands other normal developers out there. And then i can have a free time and mind free of stressing over what's cool or not

It's about what you value. If it is your time and happinnes, if you mainly want to just build stuff to solve real world problems, then choosing good old monolith application will get you there safe and fast in 90% of situations.

If you value to be hip and cool, then Deno, hydrating whatever, edge servers and sorely lacking areas of modern web development will 100% get you there.

My thoughts weren't really meant to be a condemnation of monolithic web app frameworks, just a summary of my conclusions after using them for years.

The reasons I have for justifying use of React, JSX, GraphQL, etc. have nothing to do with being "hip and cool" and everything to do with happiness and productivity. Using modern tools is both more enjoyable and more productive in my experience, as someone who used Ruby-on-Rails with templated pages for four years.

“Modern” also means the solution may benefit from reflection on past solutions.

The accounting software I use, written in 2004, evolved over the decades starting from 1980s software. It all works (hence, I’m using it now), but comparing the user experience and source code of various features developed at various times reveals a lot about what “modern” means.

Here’s a few things:

Standardisation: Modern software tends to use proven designs, such as SQL over a bespoke query language.

Performance: The strictness of ABIs and APIs makes it difficult to restructure for the sake of optimisation without introducing undesirable breaking changes. Old codebases may be essentially “frozen” and stuck on old versions of libraries. Fresh software can use the latest versions of libraries, with their new APIs & ABIs and whatever optimisations come along.

Fundamental coding improvements: Old languages don’t have ergonomic, performant closures (see lambda functions in Python). New languages do (see arrow functions in ES6). Replace “closures” with any core language feature, like null coalescing, match statements, object & array destructing (or even better: pattern matching assignment), or hygienic macros. (Let’s not discuss async/await as that doesn’t lie in the “unquestionably better” column.)

Better error messages & debugging: Over time, we collectively as developers have figured out what helps and what hinders when trying to track down troubles.

——

I also build stuff that solves real world problems. I once used Python and Django for everything. Now, I’ve moved to Node.js, TypeScript, React, and generally that ecosystem. It works far better than Python+Django. My development speed is blazingly fast in comparison, and the results stand up — they’re shippable.

Once I was familiar with Python & Django, they got the job done.

Now, I’m familiar with TypeScript & Node, they get the job done better.

Familiarity is that invisible force that, in its absence, prevents us from distinguishing things that don’t work from things that do work but are just different from what we know.

> I am so productive and i can actually get my work done quickly, **the same way as hundreds of thousands other normal developers out there.**

i seek out new technologies because i want to be _more_ productive than the average engineer. i don't believe there are hundreds of thousands of developers who are more productive than someone who makes an effort to learn stuff like deno, vite, unjs, fauna, etc. as soon as possible

There is no need to manually set up your own Node.js SSR framework for React. Next.js exists, and is quite mature at this point. Next.js is quite fun. Highly recommend it.

The novel thing, for this, in my mind, is the edge hosting.

But just like all other frameworks, the cost isn't just getting it started, it's learning the framework, learning the ecosystem, and slowly building up your knowledge of the edge cases when you start moving past it's limits.

Next.js puts you squarely back in monolith server-side territory in that regard, it's just a different flavor. Of course it has it's upsides if you're doing a purely React application. But you've now got all the complexity of a server-side monolith and a frontend framework, with the added bonus complexity of components that have to switch between client and server-side contexts, then state management and hydration across that boundary as well.

Now people are going to say "Ha, idiot, you just simply..." but that's just part of the learning, so you're in no better place with Next.js/SSR in general unless you want to build an interactive application. This isn't against Next.js by the way, I did enjoy it when I needed it, it's just that there's no avoiding some of the inherent domain problems regardless of which framework you pick.

I wonder if this is why a keep reverting to PHP , most stuff I can build without frameworks or just the odd library because I know how.

Everytime I give myself some free project experiments (have a local PI for tinkering) I always feel it’s unnecessarily complicated or feeling that hill I have to climb, at which point I can dream the solution in PHP frontend JS/HTML.

I've passed over that learning hump, put some projects into production with React, NextJS, and Vue, and I still think PHP + native JS/HTML is the more pragmatic tooling choice. It's more simple, robust and easy to debug. I've been experiencing some other backend frameworks too, specifically Node and Ruby stacks, and the PHP ecosystem and language is ahead by a country mile.

I think if you want to pick a pragmatic toolkit to work with long term and kick the churn to the curb, PHP is a great choice for web applications and will continue to be for a long time thanks to it's diaspora.

PHP (or, in my case these days, Deno serving templates, typically nunjucks) that have https://htmx.org/ in them for interactivity gets you productive, quickly, for a lot of the tasks I need to do.

That said, React makes building even more interactive, complicated things simple, and is easy to hire for, so thats what we use at work.

I do think the world is still ripe for a PHP-like language. The template-style webserver-aware way of doing things, with modern features. Maybe one day.

Definitely my biggest concern working with nextjs so far is that the line between when something is will execute server side and when it will execute client side is a bit blurry until you test them. It's manageable but requires some trial and error IME.

That was problematic for me when I was testing it out. Can’t access the window object without excessive workarounds that I couldn’t make work with my project. I ended up reusing existing react components and move it to all browser rendered react and even that experience has me leaning toward moving it to Vue or dropping the framework altogether and grinding everything out in css again. That said, I did enjoy using styled components. I found that pattern pleasant to reason around.

Is it Node’s Rails or Django? That’s roughly what we want to encourage. It’s been a long time coming.

Channeling my inner Cicero, Fuck Rust.

Yep, I've been using Next.js for several years and it's mostly great. One thing that I found is that Next.js still suffers from configuration fatigue, this was especially true before the team moved from Webpack to SWC. I'm glad to see that the team is moving more in the direction of "configured by default", but you still inevitably need to fiddle with the dials if you want to use things outside of the documented tool integrations.

ASP.NET Core is pretty minimal in ceremony nowadays. You can easily do single file web development.

https://github.com/dodyg/practical-aspnetcore/blob/net6.0/pr...

> Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages,

Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.

> monstrosities

why do you have to sprinkle that snark + negativity in there? it implies a toxic role of "you are superior" and "people who use JavaScript to serve static blog content" are inferior.

why can't we all just get along? especially in this tight-knit programming community that is supposed to be full of love and collaboration. in today's modern day of inclusion and emphasis on mental health, you're spreading hate towards people who use JavaScript to serve static blog content and talking down to them. not every 2022 of you, in my opinion.

let's work to get rid of the culture where you imply somebody else's code project doesn't meet your standards, and that since they wrote it, they are dumber than you for making poor design decisions in your opinion.

> especially in this tight-knit programming community that is supposed to be full of love and collaboration

You must be new here.

While I don't like as well the tone of previous poster, I think that any field should have a healthy dose of "elitism" and "competition" and the previous user is right.

Why do you think the previous poster is right? I personally think they are being sort of silly.

Don’t get me wrong, I absolutely think you should consider your tools, but I recently had to get a screw out of a bookcase. It was stuck in free air and was just going round and round, so I ended up using a hammer to push it in the right direction. This is far from the only time I’ve used my hammer for something it wasn’t intended for, and it got some new scratches on the side, but at the end of the day, the screw got out.

Which is important to remember here on HN, because this isn’t really a “programming community”, it is (or was perhaps) a platform for investors to sneak peak on interesting opportunities masked as social media for hackers. And the ”monstrosity” was launched after all, which is the most important aspect of any product.

Aside from that, I think it’s reasonable to assume that a lot of smaller and personal websites are used as learning experiences. So naturally a lot of them are going to be build “suboptimal” because the reason the tool was chosen was the tool itself.

Should have used some pliers...

> full of love and collaboration

Why do you have to sprinkle that positivity in there? It implies a toxic role of “I am naive”.

Ah, I’m just jerking your chain. For the most part I agree with you. Calling the way other people do things a “monstrosity” really is uncalled for.

Having to support these "monstrosities" i cant see it as toxic but merely a way of life..

>"tight-knit programming community that is supposed to be full of love and collaboration."

Now you owe me a coffee and a monitor.

>People are already building JavaScript monstrosities to serve entirely static blog content.

I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users.

I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. Couldn't even grasp the concept. I think for better or worse this is where we are headed.

Since forcing the industry to realize the possibility of server-side rendering at gunpoint is oppressive and impractical I suppose that there is some sense in which we need "accept that's how websites are built now," but there's certainly no problem with speaking about the benefits of server-side rendering and drawbacks of JS-ification.

> 2-3mb of JS download (that will be cached aggressively)

It's a giant problem on mobile. Connection quality varies and the larger the payload the greater the probability that it just doesn't all load. Caching? Mobile Safari will just reload the entire damn page periodically if you swap apps -- I don't think it caches in the same way that desktop browsers do.

A couple versions ago mobile browsers started clearing cache when you leave the application to help save battery life if I remember correctly. Very annoying because now I am unable to open a bunch of tabs in Safari for HN threads before I go off grid.

This sounds made up.

Whether the reason is true, the behavior seems more or less consistent with my experience. Mobile Safari caching seems forgetful on surprisingly short horizons (especially when low power mode is on). Mobile Firefox seems better but sucks down battery life on the order that Google / Apple Maps in active navigation do.

If you have a reason to believe the reality is different, though, happy to hear about more details beyond "this sounds made up."

> I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too.

I don't think we should simply accept that's how things are done now.

> I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy.

A web developer like the one you mention that can't even conceive of server side rendering makes them a bad web developer. That lack of core understanding means they have no idea how a web browser works and only view the world through JavaScript. They have no concept of progressive enhancement.

So this means they'll likely spend the next five years poorly implementing features a web browser already has. They're going to make websites, er "apps", that won't work properly in micro browsers. Hyperlinks won't work or will be flakey enough to might as well not work. And best of all their stuff won't work on entry level devices that are extremely popular.

> But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users.

You say this but it's not the common case. A lot of people have shitty devices because they're cheap. Whether they're entry level phones or shitty bullpen office systems people everywhere are stuck with them.

No matter how fast Chrome might execute some JITed inner loop is immaterial when the next line adds the DOM's billionth div pretending to be a button.

Thanks to cargo culting CI/CD there's little guarantee some app is going to reference the same JavaScript file on different days so the cached version will be tossed and yet another copy of Doom will be downloaded.

There are plenty of uses for JacaScript and cool web technologies. There's also lots of places where JavaScript is indispensable and enables awesome things. But requiring 3MB of JavaScript to read a static blog post is just poor craftsmanship. It's not even interesting as a project because you've signed the reader up to execute some unsolicited code to do who knows what. If you love JavaScript, render all your markdown with it on your device and just send me the static output. Don't make me download Doom and the markdown just to turn it into a few paragraphs of text I can't actually read. Web developers should respect their audience enough not to make them spend unnecessary resources to use their stuff.

I would like to see web apps move in the direction of server-side rendered static pages on initial load, and then progressively hydrate the app with data from the back-end on demand.

Rails does this surprisingly well using Stimulus with web sockets to mediate the exchange of events and data between the client and server layers.

Similar strategies are used in Phoenix Live View apps.

Load static markup and data -> request more data if you need -> send events and data to the server -> respond with the new state to display if different than the client’s version.

At the risk of sounding rude, what you're describing has been the status quo for data-heavy SPA scenarios for a couple years. NextJS, NuxtJS, Angular Universal, Gatsby, they all allow you to preload data into a server side render and then let the client side JS take over on demand.

Have you actually had a look at Rails 7 with Turbo? It's nothing like what you're describing with NextJS etc. in that it aims to keep Javascript to an absolute minimum.

Yes, they’re sending HTML chunks over the wire. It’s the same end result though, except you’re still not exempted from learning JS.

It puts rendering back on the server where it belongs. The JS is minimal.

I’ve seen garbage and exemplary sites produced with both methods. Rendering HTML with data hydrated server side and assembling it with a library client side vs rendering JSON and generating the HTML client side is a weird religious stance to take.

Some of the jamstack frameworks like Gatsby do this. They turn into SPAs after the first page of pre-rendered HTML is served.

These sites aren't fast though... As soon as your computer isn't the newest or your internet connection isn't the fastest, or you simply have other things happening in the background, these JS-heavy sites slow down to a crawl where more reasonable things would render instantly. They also make it easier to hide nefarious code and often break accessibility and customizability the user agent is supposed to provide.

Look at the bright side... more $$$ for your efforts.

Perhaps, but if your goal is to turn a pile of markdown/aciidoc/rst files into a blog, there are better and more purpose built tools for that. i.e. Jekyll, Hugo, Gatsby, 11ty.

> Setting up a monolith application means using something like Ruby-on-Rails, Django, Spring, ASP.net, or rolling your own with a Node.js backend serving a SSR front-end, or hydrating React views.

https://github.com/cheatcode/joystick

You can use a service worker proxy to cache and serve files to an application, which keeps things both fast and also with raw uncompiled html and JS file.