0xblinq

One thing is framework hopping, which one can decide to do or not do.

The problem here is that even staying within the same framework it feels like you're changing it every 6 months. Look at Next (pages vs app router) or Remix (now react-router).

There's literally zero stability and you need to rewrite everything constantly.

The worst part, as it happens at my job, is when you have people newer to the industry that think that if you're not on the latest and coolest then "everything is shit" and they live in this mindset where everything has to be rewritten constantly or otherwise they cannot be happy at work. Fuck your users, your product and everything else. Latest cool trend is the only thing that matters to them.

Inertia.js

Yeah, and we switched from all these meta frameworks that change their mind and get rewritten every Tuesday into using real full stack batteries included frameworks and then use React through Inertia.js.

Best of both worlds, and a stable and proven foundation to build on top of.

I don’t trust any of these meta frameworks anymore.

This is such a mess.

These guys love to create chaos. We used to “joke” with the fact they change the way to do routing in each RR release, now they change the entire framework with each release.

We moved to Inertia.js. All our problems with meta frameworks are gone.

We use it at work with a Rails backend, and we are about to start a new project with an Adonis.js backend.

Give it a try. It’s the best way to use React, by far.

Same. Using it at work (although with React/Rails) and it works great. Best of both worlds with minimal drawbacks.

> this is why (HN cough) multi-cloud/dedi k3s

As long as you don't factor in the cost of the effort to make that work as seamless as it sounds.

I think remix is a lot better. But the problem is that the team behind it (same as react router) have spent the last 10 years changing their mind every Tuesday and rewriting everything and breaking every API, it’s a cat and mouse game of chasing their latest idea all the time.

Btw, remix itself is deprecated. There you go.

What would I use? For sure I’d go with a MUCH saner and stable approach: inertia.js as the glue between React and a real full stack batteries included framework such as Adonis, Laravel or Rails.

Using Next.js for self hosting is a really bad idea in my opinion (and experience). Despite of what they say (for obvious marketing reasons) their framework is optimized and developed to run on their platform later.

One of the problems people don’t seem to realize, is that when you use it on your own server you are still “paying” for the trade offs they made. Like you will run into artificial limitations that should not be there at all, except because those limitations only help keeping the door open so that you can move into their platform. If they removed those limitations then moving into their platform would be a lot more difficult and obviously they don’t want that.

Do you want proof of that?

https://github.com/vercel/next.js/discussions/46722

Check that whole conversation. It’s now closed with some bullshit because they don’t like people realizing this.

So… if you are using Vercel, then great. Next is your best option for their platform. But using Next outside of vercel is a terrible idea. There are far better options for that.

Laravel

I used to work with Django 10 years ago, and I loved it.

I totally agree it looks totally outdated nowadays and I wouldn't pick it over the other alternatives. It's incredibly how bad it looks if you're going to need anything else than an API.

Because it's not about the language. It's about the ecosystem, the tools, the libraries and the frameworks. There's no world where your barebones hyper performant Go/Rust/etc and its minimalistic routing library you might want to call a "web framework" can match Rails/Laravel/django/etc productivity wise.

You can't be seriously saying using "Go" (a low level systems language) will be as productive as using Rails (a very high level framework intended for CRUD applications). Despite how much you might hate Rails, that's like saying you'll build a blog faster with C++ than with WordPress.

> That's what NextJS and SvelteKit help with, and that's what Rails revolutionized back in 2006.

Are you seriously comparing "being able to execute code on the backend" with Rails? Or Django? Or Laravel?

There's no way in this world Next/Remix/etc are helping in any way to write code on the backend. Where's the support for database access? migrations? ORM? queues? scheduled jobs? validations? translations? authentication? authorization?

The only thing Next.js is helping with is pushing people towards Vercel's platform, that's it.

You're comparing a systems oriented barebone low level programming language to a very (maybe the most) high level framework on top of a very (maybe the most) high level language.

I'm not a fan of Go, but that's not the thing to blame here. Using Go for a "CRUD" application is a terrible decision from the get go.

Using Rust for a CRUD application is a terrible choice. Of course it won't work.

It's like using Rails to write a database or a DNS server. You're just trying to use the wrong tool for the job.

That conversation in Next's GitHub repository makes it super clear why using Next on your own servers is a terrible technical decision, and many people there seem to not realise yet about the real reasons for things to be like this.

Going through that discussion, people seem perplexed and confused as to why they wouldn't allow such a simple change so that people can run their middlewares on a standard Node runtime when running it on their own servers.

Despite of all the excuses given there, I'm very surprised most people can't read between the lines and don't realize the real reasons they're not doing this: It's conflict of interests. They want to promote it as a tool you can run everywhere, but they also want you to deploy it to their platform (obviously...).

If they allow you to run your middlewares on a standard node runtime (which their platform doesn't support because middleware runs on "the edge" or whatever) that means that your application will never be able to be deployed to Vercel's platform.

That means that your application that you're running now on your own servers is having to deal with artificial limitations with the only purpose that the path is clear for when the time comes for you to deploy to Vercel's platform.

So, if you're using Next and have no plans to ever ship to Vercel's platform, you're picking the wrong tool, and having to deal with workarounds and limitations that should not be there at all.

I needed to mention this because, once again, somebody is rooting for Next at work and that won't happen on my watch, given we're not Vercel customers. If we were, it'd be a different story.

While running your middlewares on Node seems like a normal thing to do, they'll never allow it unless they support it first on Vercel.

This is just an example among many.

By far the most sane way to use React/Vue.

We've been using v1 at work (with a Rails backend) and it's fantastic.

You get the best of both worlds, and little or none of the drawbacks.

Or an adult movie

I’m from Europa. I can confirm there’s life here. Not sure for how long though.

3 years from now they'll have invented their own AWS. NIH syndrome in full swing.

No, I think he meant the one taking the nap.

Exactly!. Why use a library when you can write everything from scratch yourself. That for sure won't have any bugs or security issues and will be super easy to pick up by the next dev.

I also follow this approach with my operating system. I'm tired of vulnerabilities so I'm writing my own.

This is still loading all strings for the current language, right?

(Don’t tell me about having the option to manually do separate bundles like “common”, “admin”, etc… that’s just more madness)

You’re still not getting what inertia is and keep asking dumb questions that make no sense. Please, check inertia docs. It has nothing to do with sveltekit/next/nuxt.

Translations are a pain in the "SPA world".

Having to load every single string from your entire application is something I don't like at all. I wish at some point we have a solution where we can just create a bundle per language so we can get code splitting, etc and just ship what's necessary for your locale.

For the Inertia project I work on at my job, we just use a "frontend" translation solution and keep the Rails translations system just for the backend.

It looks to me like you didn't even check what Inertia is?

It basically gives you access to the entirety of features provided by Rails, Laravel, etc without having to write an API, create a separate codebase or deployment. You don't get any of that with SvelteKit. This is apples vs oranges.

At work we replaced a super messy hotwire/stimulus frontend with Inertia+React and we're super happy about it, no issues at all.

The project is a lot easier to maintain and Inertia just does what it says it does.

Lots of ideas here for SciFi movies.

I also like the idea of everything being a simulation (like in Matrix) but managed/set up by an alien civilization and just experimenting or having fun with us, or us actually just being their avatars… and we are them!!! Alright, time to go to bed.

It’s like two orders of magnitude easier to setup and use.