←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 5 comments | 02 Sep 25 06:57 UTC | HN request time: 0.856s | source
Show context
DanielHB ◴[02 Sep 25 08:59 UTC] 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 ◴[02 Sep 25 12:23 UTC] 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 #
1. AstroBen ◴[02 Sep 25 14:32 UTC] No.45103638[source]▶
It's weird how C# can elicit such an eugh response, and TypeScript gets so much love. They're.. made.. by.. the.. same.. people

I agree people really need to update their mental model of where dotnet is at. I worked with it on Linux and it's a great experience

replies(1): >>45104248 #
2. porridgeraisin ◴[02 Sep 25 15:22 UTC] No.45104248[source]▶
Probably because the standard way of writing C# is too OOP-ish (for lack of a better term). Typescript lets you write just usual functions handling mostly typed objects, which is about as much abstraction as most people want (except for 1-2 classes for stuff like `BTree`), and as much typing as most people want.
replies(2): >>45105476 #>>45107980 #
3. mrsmrtss ◴[02 Sep 25 16:38 UTC] No.45105476[source]▶
It's more likely they never tried C#, but have a very strong negative bias towards it nevertheless. C# can also be written very functional if you want, it's a multi-paradigm language like Typescript itself.
replies(1): >>45105986 #
4. porridgeraisin ◴[02 Sep 25 17:12 UTC] No.45105986{3}[source]▶
Of course it _can_ be. But that's not how major libraries are structured. Which defines how majority of business apps are structured. The way majority of folks use a language defines the language in its entirety, doesn't matter if theres a kitchen sink of alternative paradigms. You can't argue that C# isn't enterprisey in the majority case. In JS you can build on top of a whole, extremely popular library ecosystem purely using functions and options objects.
5. DanielHB ◴[02 Sep 25 19:36 UTC] No.45107980[source]▶
It is because C# uses nominal types (C-like) and typescript uses structural types (ocalm-like).

https://en.wikipedia.org/wiki/Nominal_type_system

https://en.wikipedia.org/wiki/Structural_type_system

Although nominal types doesn't necessarily mean OOP-ish (inheritance-heavy) it is a pre-requisite (for inheritance-heavy code).

The distinction between the two is not a black/white thing but (modern) typescript (and Flow as well) is heavily focused on structural typing while C# is heavily focused on nominal typing. In fact the whole composition vs inheritance discussion fundamentally is about making types that behave in a more structural manner.