Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
0xblinq
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
10 ms
·
91.
▲
by
0xblinq
2y ago
Except you can't "just use react". Especially if you have more than one page, or you need to do SSR.
92.
▲
by
0xblinq
2y ago
Inertia. It's just a thin layer of glue between your frontend (React, Vue, etc) and a real batteries included fullstack framework such as Laravel/Rails/Adonis.
93.
▲
by
0xblinq
2y ago
Confusion. Make sure you add some of it, otherwise things might be too easy and we might lose our jobs.
94.
▲
by
0xblinq
2y ago
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 rea
95.
▲
by
0xblinq
2y ago
Inertia.js
96.
▲
by
0xblinq
2y ago
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 an
97.
▲
by
0xblinq
2y ago
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.
98.
▲
by
0xblinq
2y ago
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.
99.
▲
by
0xblinq
2y ago
Same. Using it at work (although with React/Rails) and it works great. Best of both worlds with minimal drawbacks.
100.
▲
by
0xblinq
2y ago
> 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.
101.
▲
by
0xblinq
2y ago
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 ch
102.
▲
by
0xblinq
2y ago
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 peop
103.
▲
by
0xblinq
2y ago
Laravel
104.
▲
by
0xblinq
2y ago
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
105.
▲
by
0xblinq
2y ago
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
106.
▲
by
0xblinq
2y ago
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 lik
107.
▲
by
0xblinq
2y ago
> 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
108.
▲
by
0xblinq
2y ago
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
109.
▲
by
0xblinq
2y ago
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.
110.
▲
by
0xblinq
2y ago
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. Go
111.
▲
by
0xblinq
2y ago
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.
112.
▲
by
0xblinq
2y ago
Or an adult movie
113.
▲
by
0xblinq
2y ago
I’m from Europa. I can confirm there’s life here. Not sure for how long though.
114.
▲
by
0xblinq
2y ago
3 years from now they'll have invented their own AWS. NIH syndrome in full swing.
115.
▲
by
0xblinq
2y ago
No, I think he meant the one taking the nap.
116.
▲
by
0xblinq
2y ago
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 syst
117.
▲
by
0xblinq
2y ago
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)
118.
▲
by
0xblinq
2y ago
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.
119.
▲
by
0xblinq
2y ago
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 langu
120.
▲
by
0xblinq
2y ago
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'
More ›