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

31–40 of 87 posts

Re: What to expect from your framework

#31

Post by epiphonium »

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…

Side note, but just wondering what you think Rails's flaws are? What did you got sick of?

Re: What to expect from your framework

#32

Post by mst »

revskill wrote: post #4

"Concatenates text and fires it off to the browser in a straightforward and predictable way." What ? It's in 2023, you don't want to concanate text ?

That would rule out almost all server side templating systems, and most non-JSX client side ones (svelte, vue and angular all involve it to some extent) so I don't think that's quite right.

I think maybe you've misread the author talking about the fact that most server side templating systems are fundamentally fancy ways to concatenate text as meaning writing the literal text concatenation yourself without having a library do it for you?

Re: What to expect from your framework

#33

Post by darkhorse13 »

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.

Or they have invested so much into some JS "framework" (most likely React) that they are heavily biased to get this to work properly. Same thing happened at the previous place I worked at.

Re: What to expect from your framework

#34

Post by beezlewax »

cutler wrote: post #23
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…

Refreshing to see someone else who hates Tailwind. It's a nightmare.

Re: What to expect from your framework

#35

Post by mst »

KronisLV wrote: post #7

> So half of this blog post has actually been sitting on my drive for a couple of months because I’ve had a good long sad about the distressingly low bar we’ve set for something to bill itself as a Framework. I suppose this is partly because we’ve never really agreed about what constitutes one, and spoiler alert I don’t have a proper working definition either. But let’s get this out of the way first: React is not a f…

The usual heuristic I've encountered is that a library is something where your app code uses it and asks it to do things, and a framework is something where your app code hands off top level control and the framework asks your app code to do things.

Whatever you think of that terminology, I think the majority of available things you can use do fall substantialy into one or other of those categories and the difference in working style while using them is a distinction worth being aware of.

Re: What to expect from your framework

#36

Post by Kiro »

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…

Wow, I truly hope you are wrong. Non-scoped CSS where you have to come up with names for everything and that doesn't live right next to the markup in the same file as the component is the worst. The whole cascading part is also something I hope I never have to deal with again with conflicting styles being inherited and overridden all over the place. Just let me isolate everything and let me freely copy a component file with all styling included without relying on any global CSS.

Re: What to expect from your framework

#37

Post by yoran »

ZephyrBlu wrote: post #17
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…

There is quite a lot of inherent complexity of web as a platform. If frameworks were any more abstracted they would be too brittle for a lot of use cases. Btw, use Sorbet for Ruby static typing. It's very ergonomic.

We adopted Sorbet for our codebase a couple of months ago, and I couldn't be happier with that choice. Sure, it's not as powerful as Typescript (e.g. no way to specify a union of constants like `type Result = 'ok' | 'error'`), but it's worth it just for the nil-check alone. And it's great for documenting too. It's easy to forget what type a method expects for its parameters.

Re: What to expect from your framework

#38

Post by ZephyrBlu »

spinningslate wrote: post #24
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.

> 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…

If you think templates are a substitute for components there is very little to discuss. Templates hide hierarchy, are not easily composable, are not easily shareable (Can you publish a set of templates on NPM?) and cannot easily have complex self-contained logic.

Another big upside of JS components which does not exist in templates is typechecking.

Templates are good if you don't have complex hierarchies and have relatively simple layouts that aren't very dynamic, but they're not the same as components.

JS frameworks have relatively low overhead compared to the total size of most sites. React is ~50kb gzipped. There are also of plenty lightweight options.

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

The backend does not own UI state. If I need to filter or sort a collection I don't want to make a request to the backend. If I need to make a selection I don't want to wait for the backend to respond before the UI updates. And so on.

Re: What to expect from your framework

#39

Post by vsareto »

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…

I personally think full stack is more popular than separated roles. They want to hire full stack because you don't really need an expert most of the time, and full stack smashes the two jobs together while paying less. This makes management easier on the surface because you can swing the entire team towards back end or front end work. And of the more capable full stack devs, you can get them to dive into expert topics as needed (JIT expertise).
Post reply on HN