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.

▲

martinald 5 days ago | parent | next [-]

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).

▲

AstroBen 5 days ago | parent | next [-]

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

▲

porridgeraisin 5 days ago | parent [-]

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.

▲

DanielHB 5 days ago | parent | next [-]

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.

▲

mrsmrtss 5 days ago | parent | prev [-]

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.

	▲	porridgeraisin 5 days ago \| parent [-]
		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.

▲

terandle 5 days ago | parent | prev [-]

Blazor is not good at anything. Please stick with JS for the frontend .NET devs. You'll thank me later.

▲

hirvi74 5 days ago | parent [-]

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.

▲

terandle 5 days ago | parent [-]

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.

	▲	martinald 2 days ago \| parent [-]
		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.

▲

noisy_boy 5 days ago | parent | prev | next [-]

> 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).

I have done a few Angular apps and the experience/setup quoted above is basically foreign to me. I know that it is a framework and not a library but it is a very well designed framework (atleast Angular 2 onwards; I used Angular v20 for my latest component). Basically most of the commonly needed stuff is included in the framework (I just added NGXLogger for logging) and the abstractions are pretty nice and fairly similar to a backend service (services wrap libraries and components rely on services). RxJS can be a bit of a learning curve but once you are comfortable with the basics, it can take you quite far. Atleast I rarely had to fight with the framework for typical SPAs. Also, the documentation along with tutorials is great - I learned using the tour of heroes application[0] but seems angular.dev[1] is the new home for v20 docs.

[0]: https://v17.angular.io/tutorial/tour-of-heroes

[1]: https://angular.dev/

▲

myflash13 5 days ago | parent | prev | next [-]

Nah, Laravel is proof that over engineered abstraction can sometimes be done right. Laravel works beautifully in production and I have never regretted using it.

	▲	skydhash 5 days ago \| parent [-]
		I don't think Laravel is over engineered. It seems more like a bag of libraries for building web applications held together by a thin framework layer. Even if there's a lot of reflections being used, it's a very readable codebase and very semantically tied to the web apps domain.

▲

panny 5 days ago | parent | prev | next [-]

>both over-abstracted and inflexible which made it really hard

This seems to be built into the culture of companies which have those ridiculous whiteboard leetcode interviews. You find people who can produce very clever complex solutions in their sleeep, and then they do that. Interviews aren't selecting for people whose strength is simplicity and clarity instead. So you get a lot of tight loop optimizers and they tight loop optimize everything... not just the tight loops. But if your product is a library/framework being consumed by mere mortals, you probably want something simple if you want to succeed in the long run. The super car's performance is meaningless to you if you can't drive stick.

	▲	DanielHB 5 days ago \| parent [-]
		Yeah, clever code is the bane of my existence. Only my own code is allowed to be clever!

▲

bapak 5 days ago | parent | prev | next [-]

> it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other

This is my job. We're a small team and my job is to keep things up to date. Insanely time consuming. Packages with hard dependencies and packages that stopped being supported 5 years ago.

▲

DanielHB 5 days ago | parent [-]

Yep, been there. It is a lot better these days for React SPAs but it is still a pain.

Fact is the only way around this in the frontend without a monolitic "batteries-included" all-encompassing all-knowing all-mighty framework is through standardization which can only be pushed by the browsers. Like if browsers themselves decided how bundlers should work and not have them be extensible.

And this tooling-hell is not only a browser frontend problem only either, it is also quite common in game development. Where you also have these monstrosities like Unreal Engine that "includes batteries" but makes it really hard to troubleshoot problems because it is so massively big and complex. A game engine is basically a bundler too that combines assets and code into a runnable system to be run on top of a platform.

▲

wild_egg 5 days ago | parent [-]

Advances in the browser standards are slowly removing the need for most client side JS altogether so standardizing on some concept of bundlers would be a step backwards.

Vast majority of web dev projects have zero need for an SPA framework these days and all this pain is self inflicted for little benefit.

Those tools do have good use cases still but the chances that your project is one of them I'd shrinking all the time.

Browser standards have come a long way in filling the holes that caused react to be written in the first place.

▲

DanielHB 5 days ago | parent [-]

I don't think we will ever be able to get away from bundlers because there is no way to solve the waterfall request problem of using modules (one module imports requires another module). Maybe some kind of standard manifest spec that tells the browser which parts of the code to load upfront and which parts of the code to lazy-load, but to generate that manifest in an efficient manner you would need at least part of what the bundlers do today.

Minifying is also somewhat of a hurdle, I guess it could be done at the CDN level on-the-fly+cache, but that is also its own nest of complexity.

SPA frameworks have a place, if anything I think they will become more prevalent, but I can foresee WASM opening the door for non-JS language stacks. However they will need bundlers as well and some languages are just not built around giving ways to minimize binary size and lazy-load code. Just try to compile some C++ to wasm, you end up with 10+mb .wasm files.

	▲	wild_egg 5 days ago \| parent [-]
		> Advances in the browser standards are slowly removing the need for most client side JS altogether I probably wasn't clear enough when I said this. If you're talking about waterfall requests in module loading, you've missed what I said and are likely sending orders of magnitude more JS to clients than you need to. It's really worthwhile looking at all the new features in browsers over the last 5-10 years and asking yourself if you really can't do what you need just with vanilla HTML and CSS at this point. You can always sprinkle in a bit of JS to fill in some gaps if needed. My team usually has a 2-300 line JS file in each project. No bundlers or modules ever required at that scale.

▲

AstroBen 5 days ago | parent | prev [-]

> It definitely needs people with more experience to set up everything

I mean it's not just the experience - it's the upfront time cost and then ongoing maintenance.. and for what? It's really easy to underestimate how much effort this will be

Having done both I genuinely think Rails is a 10x productivity boost over stitching your own mishmash of libraries together in Node

The only lack of flexibility you run into is if you really disagree with the fundamentals of the framework. If you hate the ActiveRecord pattern for example you need to stay away

"shit breaks once complexity comes in" is a skill issue