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

31–40 of 256 posts

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

#31

Post by yakshaving_jgt »

mark38848 wrote: post #25
yakshaving_jgt wrote: post #17

So the single most important factor that differentiates front-end frameworks is DOM diffing performance? Well, IIRC, Elm is faster than all the examples given, and yet front-end developers find Elm to be weird and frightening. So I’m not sure I agree with the premise of the article. I also don’t agree that there can be so many valid answers to “Find a change detection paradigm that fits the needs of your application”…

Don't you find a language without higher-kinded types or type classes frightening, too?

Funny :)

I’m not sure how to answer this question. Any serious answer would spoil the joke.

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

#32

Post by colordrops »

Worthless article if it doesn't include Web Components or Web Component-based frameworks like Lit. Google, Adobe, Netflix, SpaceX, and many other companies use standards-based components, so it's not some niche thing. Funny that the "framework" that will probably outlast everything in the article isn't even mentioned.

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

#34

Post by grayrest »

MauranKilom wrote: post #9

Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?

> 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 it out was a chat component that was ~600 LoC and 50-something reactive variables in a moderately complex chain blew up into ~5k LoC of output. I also ran into what seemed to be some transient invalidation issues. I was short on time to debug this and engage with the Svelte community so I rewrote it in React to match the rest of the system. It's possible I was doing something wrong but I don't have enough confidence to bet on 3.x again. I'll take another look when 4.x comes around.

> Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?

There's significant network effects around the established frameworks. Nobody gets fired for picking React. I personally think Solid is the best overall technically but the ecosystem and mindshare is smaller and that matters to a company making a business and not necessarily technical decision.

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

#35

Post by joshribakoff »

alana314 wrote: post #33

The problem I have with react is that if I set a variable using a hook, it's asynchronous and not immediately available in my code. It's nice for updating the DOM but causes me lots of race conditions.

This is by design, the race conditions are caused by your implementation not complying with the constraints it was designed for you to stay within.

Use a local variable (not react state) if you need to store a value and read it back synchronously. Use a useEffect hook if you need side effects to run when react state changes, and finally useMemo if you need derived react state

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

#37

Post by nsxwolf »

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 usual technique of finding some text content, looking for an i18n file and working my way backwards is tedious.

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

#40

Post by pc86 »

pmarreck wrote: post #27
ChrisArchitect wrote: post #21

From June since no date on it Shared by the dev https://news.ycombinator.com/item?id=36403909

Technical blog posts without a date should be illegal

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.

Post reply on HN