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

51–60 of 87 posts

Re: What to expect from your framework

#51

Post by dchuk »

ozim wrote: post #45
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…

How do you implement editable list of items where requirements are that: - editing/creating new has to be in a popup - people don't want full page reload because they lose context (and have "feel" it beeing slow even if it is not) - edit-table is not a solution because amount of settings will fit popup - some things like item name in a list has to be updated in the list after saving in popip which requires two way da…

This would be trivial in Hotwire with Rails

Re: What to expect from your framework

#52

Post by yurishimo »

arrowsmith wrote: post #41
ZephyrBlu wrote: post #38

Earlier quoted context omitted.

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

> The backend does not own UI state. It does with Phoenix LiveView. And for stuff that shouldn't need to talk to the backend I find Alpine.JS to be a comfortable option that's very lightweight and several orders of magnitude less complex than React.

How have you found the latency to be? Are you shipping in multiple regions? Is this something you think about actively? I know there are ways to optimistically update if you want, but that sort of defeats the purpose imo. (I say this as someone extremely interested in Elixir/Phoenix)

Re: What to expect from your framework

#53

Post by incrudible »

vsareto wrote: post #39
incrudible wrote: post #22

Earlier quoted context omitted.

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

You do not need an expert most of the time, except when you do, at which point you better have one on board. You can mix and match, but keep in mind that context switches are expensive too.

Re: What to expect from your framework

#55

Post by naasking »

beezlewax wrote: post #34
cutler wrote: post #23

Earlier quoted context omitted.

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.

Haha, I love Tailwind and Tachyons! Writing CSS is still a PITA.

Re: What to expect from your framework

#56

Post by yurishimo »

fuzzy2 wrote: post #42
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.

> hackernews is not reflective of the real world. Say it isn’t so! :-D Just as an example: When was the last time you read about Angular on the HN frontpage? Basically last decade. Does that mean nobody uses Angular? Hell no. It is extremly widely used by big-ass corps. It’s just that their devs generally aren’t in the HN crowd. What companies do, what their support cycles are and how conservative their tech leaders…

Can you name some companies that are actively investing in Angular right now besides Google? It feels like React has taken over for many large businesses (non-tech focused) because it's "easier" to hire React devs.

I used to work for a company where our manager (a few steps below CTO) was pushing for us to migrate to React from Vue so they could hire more people to come in and help with feature development. We pushed back and afaik the team is still using Vue today.

Re: What to expect from your framework

#57

Post by christophilus »

ozim wrote: post #45
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…

How do you implement editable list of items where requirements are that: - editing/creating new has to be in a popup - people don't want full page reload because they lose context (and have "feel" it beeing slow even if it is not) - edit-table is not a solution because amount of settings will fit popup - some things like item name in a list has to be updated in the list after saving in popip which requires two way da…

I do this in Preact and it is a breeze.

But I also did it in an old Rails app with a bit of jQuery and partials. The modal loaded its markup from an endpoint. Saving was an http post that returned html which I injected into the DOM using some basic sorting / filtering logic. It was… ok, but there was duplicated logic on the front and back ends. I think if I had to abandon SPAs again, I’d probably have the “save” endpoint return the full page and just replace the html each time so that all logic lived in one place. To hell with efficiency— it’d probably be just fine and quite simple.

Re: What to expect from your framework

#58

Post by christophilus »

yurishimo wrote: post #52
arrowsmith wrote: post #41

Earlier quoted context omitted.

> The backend does not own UI state. It does with Phoenix LiveView. And for stuff that shouldn't need to talk to the backend I find Alpine.JS to be a comfortable option that's very lightweight and several orders of magnitude less complex than React.

How have you found the latency to be? Are you shipping in multiple regions? Is this something you think about actively? I know there are ways to optimistically update if you want, but that sort of defeats the purpose imo. (I say this as someone extremely interested in Elixir/Phoenix)

I tried something like liveview way back in the day (10 or 15 years ago) and latency was the killer. It’s probably much better these days with 5G and more efficient refreshing (we did full page refreshes, IIRC). But this is still the reason I won’t use liveview or an equivalent. If you do run into latency issues, you’re in for a world of pain if your entire application is architected incorrectly.

Re: What to expect from your framework

#59

Post by christophilus »

yurishimo wrote: post #56
fuzzy2 wrote: post #42

Earlier quoted context omitted.

> hackernews is not reflective of the real world. Say it isn’t so! :-D Just as an example: When was the last time you read about Angular on the HN frontpage? Basically last decade. Does that mean nobody uses Angular? Hell no. It is extremly widely used by big-ass corps. It’s just that their devs generally aren’t in the HN crowd. What companies do, what their support cycles are and how conservative their tech leaders…

Can you name some companies that are actively investing in Angular right now besides Google? It feels like React has taken over for many large businesses (non-tech focused) because it's "easier" to hire React devs. I used to work for a company where our manager (a few steps below CTO) was pushing for us to migrate to React from Vue so they could hire more people to come in and help with feature development. We pushed…

I’d say 50% of the devs I know use Angular. .NET shops love it. Fidelity and a lot of other financial businesses use it. I’d put money on heavy usage in the enterprise, though I haven’t been in that world in a long time.

Angular core has 3.5M weekly downloads. Quite a lot fewer than React’s 20M but still significant.

Re: What to expect from your framework

#60

Post by KronisLV »

mst wrote: post #35
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…

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

I think that the offered terminology is nicely put and should be good enough to describe most cases! However, what we might find is that either it's more of a spectrum than a binary library/framework division (e.g. your example of falling mostly into one or the other, even if not wholly), or that things start to depend on how we use certain technologies.

In my experience, Vue, React and Angular, even Svelte would typically all be used as frameworks, even if that's not the mainstream description of them. The "project" with whatever business logic needs to be implemented would be built within those technologies - using their approaches to components, data binding, validations, routing, state management and so on, possibly by integrating additional bits of code with them, where not available out of the box, still typically with one or two idiomatic (popular) packages.

But hey, regardless of the naming/classification aspects they can all be a good choice (as can Nuxt or Next.js, as well as SSR) for at least certain kinds of projects, as long as some inherent drawbacks of the architectures themselves aren't forgotten about.

Post reply on HN