Ask HN: What do you believe is the future of web frameworks? | Hacker News Reader

Ask HN: What do you believe is the future of web frameworks?

5 pointskindofajsdev8 comments

I’ve been a dev for a few years so definitely not as experienced as some of you.

I switched companies sometime ago. The first place was a rails shop and I loved rails. But then I switched to a shop that uses hasura + netlify and I just can’t see a reason why to never use this pair for CRUD apps.

I imagine we will see more frameworks based around east deployment of serverless functions and edge compute for backend tasks. I think the frontend side is being to mature and react/others are here to stay for a long while. But I’d like to hear thoughts from more experienced people.

View on HN

The next wave of web frameworks is going to be all about keeping stuff at home. No more lambdas, no more serverless, no more CDNs, no more vendoring. It's all a cycle.

Monolithic apps. No frameworks, no package managers. Everything is provided by the house.

Monolithic apps. Monolithic frameworks. Libraries via package managers. Almost everything is provided by the house, but now we rely on a bunch of dependencies.

Microservices. Different frameworks for each part (frontend, backend, databases). We still keep stuff on our domain. No serverless yet, but we start to keep stuff out of the house. Dependencies on CDNs.

Microservices. Serverless, lambdas. We start to put everything on the hands of others.

Here. We go back to point 1.

I think I have to disagree with this one. I agree programming is cyclical.

But I don’t think we will get rid of CDN’s. I don’t see js going anywhere and with that, I think package managers and bundlers are here with it. I can’t see people going back to vanilla js (even if someone made a more modern jquery alt).

Why do you think start ups would go back to writing their own deps if the ecosystem is mature and said dependency wasn’t part of the core business?

New things come along, developers get excited, proclaim we finally have the ultimate language, framework, tool, architecture. Rinse, repeat. All of the code developed in last week’s or last year’s big thing is still out there, now dismissed as legacy, full of technical debt. Programming is like fashion that way.

Lots of decades-old COBOL code still runs enterprise businesses. Something like 75% of all public web sites were written in PHP, dismissed as obsolete for years. So in a sense everything developers use at all is here to stay for a long while, because the cost and risk of replacing it every few months is too high, and programmers hate maintaining legacy code.

After enough time in the development business you figure out that we mostly reinvent the same flat tire over and over.

Truth

> But then I switched to a shop that uses hasura + netlify and I just can’t see a reason why to never use this pair for CRUD apps

That's a pretty big statement. You seriously haven't ran across any drawbacks/limitations whatsoever? None? I'd be a bit more suspicious if I were you.

Yeah definitely an overstatement. I probably should spend some time thinking about other services and how they might be built? Could be a fun system design exercise.

Limitations could include: Caching queries, netlify doesn’t offer any kind of firewall like you can when using aws directly so you have to roll your own auth, vendor lock-in, datadog is the best option for log monitoring since it’s the only option both netlify and hasura dump too, hasuras monitoring service is only available on their cloud (not the oss version).

Don’t get me wrong, there are definitely limitations. And we haven’t even scaled to something like 100k+ users so I’m sure other limitations haven’t even shown themselves.

But I can’t even comment on that since I’ve never worked on something of that scale yet. I guess my question was more for MVP crud apps.

Just run some migrations, you have a full backend accessible via GraphQL. Add some event triggers and you can hit rest endpoints from changes in your db. Add some custom actions and your fe can hit your rest api for more complex tasks without leaving gql land.

It’s just less code to get things done. But that’s why I’m leaning into the expertise that can be found on HN! I would never claim my opinions are “right”

> you have a full backend accessible via GraphQL. Add some event triggers and you can hit rest endpoints from changes in your db. Add some custom actions and your fe can hit your rest api for more complex tasks without leaving gql land

a) You're assuming everyone agrees GraphQL is always the way to go, which is far from common wisdom. Why is superior - especially for MVPs?

b) You're assuming that create CRUD MVPS in something like Python/Ruby/Node is slower/more complicated than what you're describing here, which is also far from certain. If we're talking about Hackathon style level of code they are all perfectly capable in building CRUDs really quickly.

I'm not saying you're necessarily wrong, I just think you haven't thought hard enough about the tradeoffs.

Personally I like the JAM stack. I refuse to learn things like React as I don't consider myself a pro, and React is a pro-tool. It's like bringing a gun to a knife fight IMHO.

Reply on news.ycombinator.com