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

51–60 of 256 posts

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

#51

Post by boxed »

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…

That's not nearly all there is to it. If the DOM was fast and you could control redraws, it would still be horrible.

A performant big pile of mud is still a big ball of mud.

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

#52

Post by 8organicbits »

sambroner wrote: post #43
r_singh wrote: post #39

This website loads staggeringly fast (much faster than HN and my own static site which uses Gatsby and is hosted on Cloudfront). What’s the reason for this?

Really impressive stuff. Seems to have slowed down slightly now that it's on the front page, but blazing fast when I first opened it.

Interesting. I'm seeing something slower. Pagespeed shows 2.7 seconds:

https://pagespeed.web.dev/analysis/https-themer-dev-blog-the...

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

#53

Post by commotionfever »

RandallBrown wrote: post #46
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…

Apologies if you're aware of this already but every browser has a web inspector built in where you can point and click on something and at least see the HTML and CSS associated with it.

and you can also click on a request in the network tab and find out the line of code triggered it, including callstack

also with react dev tools you can click somewhere on the page and see the react component, it's props, etc. similar tools are available for other frameworks

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

#54

Post by franey »

It is something that distinguishes them, certainly. As someone who switched from using Vue to React at my day job, dev tooling & editor support have been the things that stand out the most to me. React works well with Vite, which has helped make it easier to use, and I've been migrating projects away from Webpack + Jest to Vite + Vitest, which saves a lot of dependency maintenance. I definitely miss Vue 3's VS Code extension when I work in React, though.

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

#55

Post by nwienert »

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 think your idea of speeding up the DOM is the right one, but the view transitions API has almost nothing to do with it. That’s more for whole page changes, and doesn’t solve the main issues which is that the DOM simply does way too much and is bloated to all hell, and that JS is single threaded.

I’d like to see a new mode introduced ala “use strict”. I know the big brains at the top hate this but we need a way to shake off some legacy especially in the DOM. A few changes to its semantics could dramatically speed it up. And then the second part would be a way to share events and DOM across workers so we can put React essentially off the main thread. These two changes together would make websites able to feel like native apps.

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

#56

Post by rustybolt »

sambroner wrote: post #43
r_singh wrote: post #39

This website loads staggeringly fast (much faster than HN and my own static site which uses Gatsby and is hosted on Cloudfront). What’s the reason for this?

Really impressive stuff. Seems to have slowed down slightly now that it's on the front page, but blazing fast when I first opened it.

Impressive? This is the default. You have to actively do stuff to make it slower.

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

#58

Post by garganzol »

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…

DOM changes are only a part of the story. Another part is a component model that allows to build complex software from tiny and sometimes messy individual pieces.

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

#59

Post by pmarreck »

exac wrote: post #45
pc86 wrote: post #40

Earlier quoted context omitted.

But how will I drive traffic to my evergreen course funnel with publication dates all over my articles? The FA actually doesn't do this, but a lot of things (including those that do very well on HN) do for exactly this reason.

Using the current date for the article /s There must be a browser plugin that offers the date a website was first indexed.

That’s a brilliant idea, if someone else hasn’t already implemented it
Post reply on HN