←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 3 comments | | HN request time: 0s | source
Show context
DanielHB ◴[] No.45100608[source]
When I first saw Next.js I was immediatelly reminded of Meteor.js. I did invest a bit in learning into it and did some personal projects. But quickly realized it was both over-abstracted and inflexible which made it really hard to get it past prototypes.

But these solutions keep coming up because they bring one thing: Self-contained / "batteries included". Just the other day there was a thread in hackernews about Laravel vs Symphony and it was the same thing: shit breaks once complexity comes in.

If you compare those solutions with the old model that made NodeJS / React SPA get so popular, so fast: Buffet-style tooling/libraries. You basically build your own swiss army knife out of spare parts. Since all the spare parts are self-contained they have to target really low abstraction levels (like React as a component library, HTTP+Express as a backend router, Postgres as DB).

This approach has many disadvantages but it really keeps things flexible and avoids tower-of-babel style over-engineering. As in a lot of layers stacked on top of each other. Not that the complexity goes away, but instead you have a lot of layers sibling to each other and it is more doable to replace one layer with another if things aren't working well.

It is understandable why "batteries included" is so popular, it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other. It definitely needs people with more experience to set up everything.

replies(6): >>45101058 #>>45101273 #>>45102172 #>>45102256 #>>45103481 #>>45103833 #
martinald ◴[] No.45102172[source]
Thing is I'm spoilt by asp.net, which has so much bad 'stigma' in the (esp startup) dev community but it is _extremely_ well designed.

You get a very batteries included approach(es) but you can always punch out of it and override it. I've never got into a situation where I'm feeling like I'm fighting the framework.

I also really like both Blazor Server and Blazor Webasm which allows you to write the frontend in C# too. Blazor server is great for internal admin panel style apps, and blazor webasm is good for saas apps, and for everything else plain old server sider rendering works great.

I'd really recommend anyone who is annoyed with their web framework to give it a go. It's extremely cross platform now (the huge drawback until about a decade ago was it was very hard to run on Linux, which isn't the case at all now - in fact, it's the opposite, harder to run on Windows), very fast and very easy to use. It takes a while to figure out the mental model of the design in your head but once it comes together you can quickly figure out how to override everything when you hit limitations (which tbh, is pretty rare compared to every other framework).

replies(2): >>45103638 #>>45105812 #
terandle ◴[] No.45105812[source]
Blazor is not good at anything. Please stick with JS for the frontend .NET devs. You'll thank me later.
replies(1): >>45109285 #
1. hirvi74 ◴[] No.45109285[source]
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.

replies(1): >>45111438 #
2. terandle ◴[] No.45111438[source]
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.

replies(1): >>45138667 #
3. martinald ◴[] No.45138667[source]
50mb payloads are very extreme. There's definitely a few MB of hurt for WASM - but nextjs is just the same, plus it doesn't have the excuse of having to download the entire CLR!

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.