Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What to expect from your framework

johan.hal.se

Post reply on HN
Print view View original

21–30 of 87 posts

Re: What to expect from your framework

#21

Post by traverseda »

mattgreenrocks wrote: post #12

Rails is probably the best framework still. But it still feels too low-level. I don’t want to care about the mountains of Web gunk there are: JSON serialization, HTTP methods, cookies, etc. Lack of static typing really hurts the maintenance story, too. I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on. Most web frameworks seem to be obsessed with the web platform to the…

Django is nice, and python's type hints can be nice. Why not have a nice django?

>I really just want to write business logic, wire that up to endpoints in a nice DSL, and move on.

Not really sure what you mean, but django ninja? https://django-ninja.rest-framework.com/

Just write a function, use type hints to say what arguments it takes, and throw a decorator onto it. Very similar to fastApi but with the django framework behind it.

Re: What to expect from your framework

#22

Post by incrudible »

arrowsmith wrote: post #15

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

Companies are already used to hiring frontend and backend separately, it is much easier to find an expert in either than an expert in both. It is also one of the few opportunities where you can meaningfully split up work. How much of an upside that really brings, is secondary. It already happened.

I do not buy into the YAGNI or in-most-cases arguments. Most cases are interactive applications, not the overengineered listicle websites that would be crap, even if they were not SPAs. If you write an interactive application, SSR will soon make your life miserable. The scrolling document approach to application UI sucks, especially on mobile.

Re: What to expect from your framework

#23

Post by cutler »

darkhorse13 wrote: post #2

This is really great, and I'm really happy people are finally waking up to this. I've stuck with Django through all of this and never looked back. Nowadays with stuff like HTMX, things have never been better! Could we do this for CSS-in-JS next please? With React 18 making a strong push for compiled CSS, we have libraries now that let you write CSS (compiled) using Typescript. This is also absolutely crazy to me beca…

CSS has been mangled so many different ways, including the loathsome Tailwind, that I can't imagine what a newb web dev has to plough through these days. Some of us with longer memories were overjoyed to see browsers finally adopting standards after the erosion of Microsoft's reign but now it appears we're intent on destroying the value of what we waited 15 years for. Fer Kreissakes just write raw, unadulterated CSS and enjoy your freedom from the CSS hacks that were unavoidable back in the late 90s/early 2000s.

Re: What to expect from your framework

#24

Post by spinningslate »

ZephyrBlu wrote: post #20
arrowsmith wrote: post #15

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though. Managing any (Literally any) client-side state is also easier with a framework. I'd rather use Preact than write vanilla JS for basic state management.

> Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though.

I've heard this before, and just don't get it. I have, can, and do create view "components" in both Django and Jinja2. They're just templates. Templates that get included in other templates. I've never (never) got to a point where I thought "darn, I want to abstract out this foo thing as a component, but can't". When I really want front end interactivity - like charts - then I'll use a JS library or a web component. With htmx, I can even do partial page updates.

None of that requires the very significant overhead that React/Angular/whatever bring.

>I'd rather use Preact than write vanilla JS for basic state management.

I'd rather use the backend. Because it owns the state, and cache invalidation is one of the two hard things [0].

[0]: https://www.martinfowler.com/bliki/TwoHardThings.html

Re: What to expect from your framework

#25

Post by cutler »

arrowsmith wrote: post #15

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

Aren't you selling Rails a bit short on its front-end capabilities considering Rails 7's embrace of Hotwire and its reworking of the asset pipeline.

Re: What to expect from your framework

#26

Post by johnteller »

I was interviewed for a job a few days back and I was told that these heavy JavaScript libraries are the future of the web. I'm still confused.

Either my country is just behind or what you read on hackernews is not reflective of the real world.

Re: What to expect from your framework

#27

Post by arrowsmith »

ZephyrBlu wrote: post #20
arrowsmith wrote: post #15

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though. Managing any (Literally any) client-side state is also easier with a framework. I'd rather use Preact than write vanilla JS for basic state management.

I get that those are the benefits. All I'm saying is that, in my opinion, the benefits you get from building a SPA are not worth the increased complexity it adds, at least for most of the projects I've encountered in the real world.

Re: What to expect from your framework

#28

Post by fredrikholm »

johnteller wrote: post #26

I was interviewed for a job a few days back and I was told that these heavy JavaScript libraries are the future of the web. I'm still confused. Either my country is just behind or what you read on hackernews is not reflective of the real world.

We aren't a homogeneous group that all have identical perspectives on things.

Re: What to expect from your framework

#29

Post by ZephyrBlu »

arrowsmith wrote: post #27
ZephyrBlu wrote: post #20

Earlier quoted context omitted.

Modelling your frontend as a bunch of reusable components is a big benefit of frameworks. I think it's hard to go half and half with frontend component and backend templating though. Managing any (Literally any) client-side state is also easier with a framework. I'd rather use Preact than write vanilla JS for basic state management.

I get that those are the benefits. All I'm saying is that, in my opinion, the benefits you get from building a SPA are not worth the increased complexity it adds, at least for most of the projects I've encountered in the real world.

I can believe that. For a lot of projects the complexity probably causes more issues than it solves.

Re: What to expect from your framework

#30

Post by arrowsmith »

incrudible wrote: post #22
arrowsmith wrote: post #15

This article is great, and it reminds me of a rant I've been wanting to make for a long time: why the hell does everyone these days insist on building every web app as an SPA? I started my career in Rails. I'm sick of Rails these days as I've worked with it for long enough to become intimately familiar with its flaws; these days I'd pick Phoenix over Rails any day of the week. But still, I'd rather spend a million ye…

Companies are already used to hiring frontend and backend separately, it is much easier to find an expert in either than an expert in both. It is also one of the few opportunities where you can meaningfully split up work. How much of an upside that really brings, is secondary. It already happened. I do not buy into the YAGNI or in-most-cases arguments. Most cases are interactive applications, not the overengineered l…

> Companies are already used to hiring frontend and backend separately, it is much easier to find an expert in either than an expert in both.

I think this gets cause and effect the wrong way around. If companies stopped unnecessarily dividing their stack in two, we wouldn't have so many FE developers who don't know how to do anything on the BE and visa versa. I've worked with frontend "experts" who barely know how to query a database. Specialisation is unavoidable, but it makes no sense to me why we need to be that specialised.

Post reply on HN