If you have front-end and back-end separate, you're doing web development wrong.

marcosdumay 5 days ago | parent | next [-]

Can we post a single phrase as a HN article? This is one of the main problems with web development nowadays, nobody gets this right... to the point that it's popular to criticize a company trying to hire a single person for both holes as "cheapening out".

Also, this is a really obvious thing. It's unbelievable how the main way people organize is the other way around.

▲

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

But what if it isn't just a basic website? Most sites I've worked on required things like content management, or auditing stuff, a bunch database stuff, SAML single sign on etc.

Most languages end up being better at some parts of the stack, like Java for overcomplicated enterprise BS backends. It seems bad to "fight" that trend.

	▲	koakuma-chan 5 days ago \| parent [-]
		A full stack framework like Next.js is, at the end of the day, still a server running on Node.js, so there is nothing that prevents you from doing anything that you could be doing with a regular express.js server. Is there anything that prevents you from implementing content management, auditing stuff, or database stuff in your Next.js project? Nothing comes to my mind.

▲

phito 5 days ago | parent | prev [-]

Totally agree. I've been using blazor server + Claude for project and it just removes all the stupid complexity of having react + a rest API.

▲

koakuma-chan 5 days ago | parent [-]

I know right? You can share types, you don't need to glue API, etc etc. Why don't people realize that.

▲

int_19h 5 days ago | parent [-]

People do realize that, which is why such frameworks have first appeared decades ago. It's just that you can't fully paper over the network gap and pretend that it doesn't exist; eventually, the abstraction leaks.

▲

koakuma-chan 5 days ago | parent [-]

Have they? I assume you are talking about PHP, which is not that kind of framework, because you would still have to write JavaScript. It lacks type safety too.

▲

int_19h 5 days ago | parent [-]

I'm talking about stuff like GWT from 2006.

▲

koakuma-chan 5 days ago | parent [-]

Wow, I had no idea that existed. It looks like it is a Java library that abstracts over the web, and generates JavaScript under the hood? I never touched GWT, but it does sound like there would be issues if you wanted to do something that's not supported by the framework. But still, I don't think this is the same as modern full stack frameworks.

	▲	int_19h 5 days ago \| parent [-]
		If I remember correctly, it was the first whatever-to-JS transpiler. But it opened the floodgates and "do everything in one language, bridge the gap transparently" has been tried several times since then. And even before that, actually! Before web apps were even a thing, we had DCOM and CORBA and some other similar but less-known frameworks that tried to make OOP in general network-transparent. It worked in principle - you could have distributed object graphs in pretty much arbitrary configurations, going back and forth as needed to capture the semantics. It failed in practice because every time you have a network gap you get a slew of potential issues that just don't exist without it (simply put, your connection and/or the other party may suddenly go away). FWIW I'm not saying that single-language specifically is a bad idea. It's specifically the notion that you can treat a distributed app as a monolithic thing without clearly marked internal boundaries where the network gap is, that fails in real world. But if you expose the gap then you still need to deal with impedance mismatch - e.g. nice your object oriented API no longer works because the object graph can't span the gap, so you need a more procedural (read: REST-style) API with serialization etc. So, this is the point where you basically want a language designed from grounds up with message passing in mind. Blazor, but for something like Erlang or Elixir, perhaps?