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

What dif­fer­enti­ates front-end frame­works

themer.dev

Post reply on HN
Print view View original

141–150 of 256 posts

Re: What dif­fer­enti­ates front-end frame­works

#141

Post by genuine_smiles »

aluminum96 wrote: post #131

> To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be a…

> and they are not particularly similar to Svelte stores either

How does Svelte differ? I’m somewhat familiar with SolidJS, and had always assumed Svelte was somewhat similar.

Re: What dif­fer­enti­ates front-end frame­works

#142

Post by rglover »

There's another, often ignored differential factor for frameworks and that is ergonomics. All of the frameworks here require specific domain knowledge to pick up and understand. That knowledge typically involves confusing concepts (Svelte and Vue aren't too bad here) that waste a ton of developer time just to wrap their head around [1]. When I look at Angular, it feels like one of those contortionist boxes at a magic show.

This is why I ended up building Joystick [2]. The amount of time I was wasting trying to reason through how a framework wanted me to do something vs. actually building what I wanted was driving me nuts (not to mention, having to watch people I was mentoring who had less experience struggle even more).

[1] Meaning, beyond a trivial interface, any sort of complex UI is often (not always) burdened by the framework's lack of clear ergonomics. There's a lot of having to learn "why it did that" in the way of getting stuff done.

[2] https://github.com/cheatcode/joystick

Re: What dif­fer­enti­ates front-end frame­works

#143

Post by grayrest »

i-use-nixos-btw wrote: post #100
boringuser2 wrote: post #63

Earlier quoted context omitted.

Why do you care about compilation output? Also, your component sounds cumbersome.

I’m mainly a C++ developer, not a frontend developer (though I dabble), and when I have a choice of multiple approaches the first thing I do is go to godbolt.org, implement MWEs and compare the assembly. I also do a lot of code generation, and my absolute goal is to have it write code that I’d write if I were doing it by hand. That’s pretty key for me. If the output is better, then good. If the output is doing a bunc…

> So my default is lean HTML, lean CSS, raw JS.

This is fine but having spent a decade of my career doing this, I would never advocate for it in an app with any kind of frontend complexity or a chance to grow into it. The frameworks mostly obviate the need to understand layout thrashing, resource cleanup, and retained state conflicts in the DOM. If you're doing simple stuff these don't matter but they're challenging to fix and more challenging to stay fixed when a group is contributing.

> Svelte has caught my attention and I want to give it a go, but if the output is bloaty then that’s a red flag for me

Your use case is a pretty good fit for Svelte and you're likely to get output you'd find acceptable and given your preferences I think you're more likely to prefer its sensibilities over other frameworks that could provide the perf you're looking for. The tradeoff is kind of like the tradeoff between monomorphization vs virtual dispatch. The Svelte compiler is basically inlining the update code instead of using shared code in a runtime.

Re: What dif­fer­enti­ates front-end frame­works

#144

Post by luketheobscure »

aluminum96 wrote: post #131

> To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be a…

There are a large number of very incorrect statements in this article.

> True to its de-facto tagline, change detection in React is “just JavaScript.”

Then in the example, the author updates a variable with `setCount(count - 1)`. That's not "just JavaScript". Just JavaScript would be `count = count + 1`.

Re: What dif­fer­enti­ates front-end frame­works

#145

Post by roblh »

nsxwolf wrote: post #37

You know what I've always wanted in a front end framework, as a back end developer that sometimes is forced to work on front end tickets? I want a development build mode that generates some kind of project metadata where I can just point to something on the screen and get a report of all the interesting files in the project that are responsible for what I'm seeing: * API calls * Templates * CSS * Controllers, etc. My…

Sveltekit has a thing now where when I do the standard ctrl shift c and highlight something, it’ll open the file in vscode responsible for it. It’s honestly a little bit unsettling, but I think it’ll be useful with some practice.

Re: What dif­fer­enti­ates front-end frame­works

#146

Post by mr_toad »

emorning3 wrote: post #42

Totally disagree with this. Change detection is nothing but a hack to get around the fact that interacting directly with the browser DOM is very slow and blinky. Imagine a world where interacting directly with the browser DOM didn't suck, then none of these libraries would exist. The crux of the problem is that the browser immediately reflects changes to the DOM to the screen. And when you make a bunch of changes to…

> I implemented word processors, and I've used a technique called 'double buffering' to rerender complete pages off-screen, fast.

Node trees can be created without attaching them to a document. Then the whole tree can be attached with one call,

There’s no need to attach nodes individually. I don’t know why anyone would want to do that.

Re: What dif­fer­enti­ates front-end frame­works

#147

Post by grayrest »

boringuser2 wrote: post #63
grayrest wrote: post #34

Earlier quoted context omitted.

> maybe someone can shed some light into the downsides of Svelte Svelte trades off runtime size for component size. It was created in the context of infographics for the New York Times online and for projects that roughly line up with that it's pretty much the technically best option. I like the Svelte authoring experience and introduced it for a few components in a React based low-code platform. The reason I phased…

Why do you care about compilation output? Also, your component sounds cumbersome.

> Why do you care about compilation output?

I was advocating/piloting a new framework in the app and was unhappy with the output versus the input and perceived complexity. I spend a significant fraction of my time cleaning up performance issues. A good chunk of that is download size so I care in general about what I'm sending across the wire.

> Also, your component sounds cumbersome.

Sure. It was the classic feature creep scenario.

Re: What dif­fer­enti­ates front-end frame­works

#148

Post by mr_toad »

emorning3 wrote: post #95
robear wrote: post #61

Earlier quoted context omitted.

I don't see it that way. The main need for change detection in my opinion is to remove the need to update parts of the DOM in an imperative manner. It is fine to do that for smaller projects but when a project gets large, it becomes difficult to reason about the myriad of changes happening without a system to handle that. I find any one of the examples in the linked post way more easy to reason about than manual DOM…

I agree with you that going back to the JQuery days of unmaintainable imperative code would not be a good thing. But with JQuery I was able to create adaptive UIs by applying 'transforms' to the DOM, I really miss that. Think of the way that 'tag helpers' can apply cross-cutting transforms to Razor Page applications, I used to do things like that with JQuery. React et al cuts me off from both the browser DOM and it's…

React discourages direct DOM access, but it’s still possible.

https://react.dev/learn/escape-hatches

Re: What dif­fer­enti­ates front-end frame­works

#149

Post by robertoandred »

hinkley wrote: post #111
stickfigure wrote: post #90

Earlier quoted context omitted.

Data comes from the server as JSON. Data comes from the user as DOM events and changes. There's always going to be an impedance mismatch. The DOM API sucks, so React et al went all in with state-as-objects. IMO it was the right call.

I just don't think DOM->JSON->server->microservice->DB->microservice->server->JSON->DOM is sustainable long term. It's had a good run, but it's a big part of the reason I'm looking at Phoenix for a personal project. React is predicated upon solving the wrong problem. Talk about impedance mismatches.

I'm not sure switching to DOM->JSON->server->microservice->DB->microservice->server->DOM will make much of a difference.

Re: What dif­fer­enti­ates front-end frame­works

#150

Post by dgb23 »

emorning3 wrote: post #121
cloogshicer wrote: post #66

Earlier quoted context omitted.

I don't know... even if the DOM was super fast, would it really be ergonomic to keep all your state in the DOM tree and only work with that? I kinda doubt it. So then you'd have to store some state in JS, and some in the DOM, and again you get a syncing problem, since you lost your single source of truth. Or did I misunderstand your comment?

>> Or did I misunderstand your comment? Well, I can see now that while I expressed my dislike for change detection I didn't paint a good picture of why I think we'd be better off without it :-). While I appreciate React's declarative programming style I dislike the fact that React (and all the change-detecting alternatives) force me to interact with the DOM through their APIs. JQuery allowed me to do whatever the hel…

I‘ve written a UI a few months ago with only lithtml and direct DOM manipulation and it worked pretty well.

I needed to do calculations and reading bounding boxes from the DOM initially and on resize. Basically a hack to get around CSS limitations.

It was crucial that this is fast enough to avoid flickering.

I wouldn’t have attempted this with react. I think it would still be possible with useEffect, but I tried the most lightweight and fast by default approach that was feasible.

Have a look at lithtml.

Post reply on HN