591–600 of 602 posts
Earlier quoted context omitted.
Why're trying to move off next? What makes the opportunity cost worth it?
Looking for full control over where the frontend is hosted. Sure, I can run Next.js elsewhere, but I could also run React Router elsewhere and have a much better overall experience in the process.
Earlier quoted context omitted.
I don't really know anything about self-hosting Next apps - but if you're deploying to k8s, it's not really that difficult or far-fetched to run an otel collector sidecar for your applications. It's already common to run some kind of prometheus scraper or other service to collect logs/metrics from your services but instead of having to have different collection methods for APM vs logs vs traces you can have it all ag…
Just by bringing up k8s you are making their point. It should be dead simple to do logging without having to set up hardly anything. I shouldn't even need to know what a sidecar container is.
If you wanted "dead simple" text-based logging in a situation where a service is deployed in multiple places you'd end up writing a lot of fluff to get the same log correlation abilities that most OTEL drivers provide (if you can even ship your logs off the compute to begin with)
Which again comes back to the "maybe the framework isn't for you" if you're building an application that's a monolith deployed on a single VPC somewhere. But situations where you're working on something distributed or replicated, OTEL is pretty simple to use compared to past vendor-specific alternatives
Earlier quoted context omitted.
Looking for full control over where the frontend is hosted. Sure, I can run Next.js elsewhere, but I could also run React Router elsewhere and have a much better overall experience in the process.
Hm could you explain further? Why is React Router going to lead to a better experience?
I have customers, but no tech problems.
Earlier quoted context omitted.
What issues have you encountered? As old school as it may be, I can accomplish basically everything my users need with just vanilla JS and .fetch() requests. I've been playing with Blazor, and it's been great so far. However, like everything, I know it's not perfect.
Performance of WASM issues. Rendering performance of large data grids is not good. Also the first load time is also terrible 50mb+ payloads. Blazor server uses websockets and is just a whole other bag of hurt. You'll have to deal with disconnects even if you can stomache the increased cloud costs.
You can (and I have) definitely rendered huge data grids efficiently with Blazor.
The biggest drawback with wasm is no proper multithreading support which has been delayed for years.
On blazor server; I totally agree, it's a pain. But for 'intranet' style apps which are used internally it's by far the most productive development environment I've used for web. I wouldn't use it for anything that wasn't a total MVP for public use but it's pretty great for internal apps like admin panels.
Recently started developing a client side web app using Angular v 20. The app is quite complex, with about 40 components many of them nested, about 7 to 8 "pages", data dashboards, multiple forms, continuously updating data from server, etc. There substantial amount of data flow in the application. So far, the experience has been absolutely wonderful, particularly, given the context of myself as a developer in the wh…
Meanwhile, I've been looking for a while and if they want a full stack or a FE developer it's always, always React. Rarely if ever Angular, occasionally Vue or Svelte, and never Phoenix. I recall back in the day when Struts was everywhere, some of us figured out it was because Struts was a trap that took twice as many devs to get anything done, and that's why there are so many openings for it. Every time I look at Re…
Next js is magic just like laravel, it's nice when you expect magic and not nice when you like to understand what's going on.
Laravel is easy to learn and use and get started with. No compiler. No javascript on the back-end. Eloquent is a good ORM. There's not much magic, no async/await. Or course you should not use Livewire. It's really terrible!
Through a customer I've come into contact with InertiaJS. React with Laravel made my work so much simpler. Routing through Laravel was easier for me. The data sharing from Laravel to the frontend is painless. I also like the server side, PHP works better for me than a Javascript server. I've had some weird bugs with nodemon, pm2 and other server tools.
I also recommend inertia. It really doesn't do much, which is very refreshing coming from Nextjs. It's simple tooling for backend for frontend-style APIs, taking care of basic routing, fetching of data, and submitting forms. While inertia was invented for Laravel, I'd argue that it works even better with Adonisjs. Because Adonisjs is TypeScript you can infer the types coming from the backend.
Adonis + Inertia works wonderfully well. It's the best of both worlds. And the simplicity of this architecture is something to admire. It's very easy to know what's going on at every point: It's just requests, responses, middlewares and routes/views. Simple and easy, while still super powerful.
Don't waste your time.
They're all almost the same (crap), but the real issue is the instability of all of them. They change every week, they're constantly pushed sideways by the VCs or other interests behind them (or the constant mind change of their devs, i.e. React Router.. I mean Remix... I mean framework mode... I mean now we nap and then invent our own frontend framework but keep the old name, just to add a bit more to the confusion and keep everyone entertained).
They're overengineered, complex, and promote the little shiny "look how fast this counter updates in a type safe way" while they totally break down when you have to do real world serious stuff like authentication (ehh...go and use this SaaS..), authorization (ehh..what's that? just put an "if"), translations (who speaks other than english?..no need for that), background jobs or anything else a real world application needs. They're focused on the shiny "typesafe call server function" and everything else is just let on you to figure out, and good luck with the library you pick, because next week it's going to be a different one and you'll be out of fashion!
Many years ago I started using Inertia [1]. I'm confident to say it's the right, simple, most effective way to use React/Vue/Svelte. It's a super simple "protocol" with very thin adapters implementations that glue together your favorite frontend lib (react, vue, etc) with your favorite full stack backend framework (laravel, rails, django, adonis).
I've used it for client projects with both, Rails, Laravel and Adonis. I have no complaints about it. It works super well, follows a simple to understand model and you literally get the best of both worlds: a powerful frontend, and a powerful backend. It keeps things simple and stable using rock solid battle proven production ready building blocks with great documentation and community support.
I'm just done with all these other "meta frameworks". They're all marketing and hype and everyone is swallowing it and then ending up cornered with a terrible solution and a lots of problems they didn't account for and have no official or recommended solution to get out of it.
That won't happen if you use plain React/Vue. That won't happen if you use plain Laravel/Rails/Django/Adonis. Inertia just glues plain X + plain Y. No lock in. No possibility of being "stuck" in a situation where "I can't do X because...."... you can.. and you can in a very nice and clean framework-supported way.
It's a fantastic undervalued idea, and we're not paying enough attention to it (yet).
Don't fall for the marketing and the hype. Look for the simple and pragmatic solutions, they're there. They work. They're just not as hyped, so I'm hyping it up a bit for you in this post. Apparently that's what everything needs: Marketing.
Earlier quoted context omitted.
Many of the abstractions and nextjs tools do things that my OS does better, cleaner and more predictable too. I suppose the overly complicated ENV/.env loading hierarchy is (partly) needed because Windows doesn't (didn't?) have ENV vars. Same for inotify, port detection, thread management: *nix does it well, consistent ish. But when you want an interface or feature that works on both *nix and windows, in the same way…
Windows has had envvars since before Linux existed. It also has FindFirstChangeNotification (or ReadDirectoryChangesW if you hate yourself) since before inotify existed, etc. Windows has pretty much everything you can dream of (although sometimes in the form of complete abominations), it's just that the people employed by Vercel don't give a shit about using native APIs well, and will map everything towards a UNIX-is…
Or, if you insist, that Unix is inconsistent with how windows does it.
Which is what those wrappers and abstractions do: they expose a single api to e.g. detect file changes that works with inotify, readdirectorychanges, etc.