Live data from Hacker News

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

themer.dev

41–50 of 256 posts

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

#41

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?

You need to learn a custom DSL for logic instead of using just Javascript. This makes it worse for TypeScript as well as other tools like for linting, etc. Personally I'll never learn another DSL after JSX.

Implicit 2 way data binding which makes logic hard to follow in larger projects, same with their reactivity model.

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

#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 the DOM you immediately see a bunch of changes happen, with portions of the screen being blanked out, and layout changes happening, and a whole bunch of other nasty stuff happening immediately, which all sucks. And updating a physical screen is slow too, double sucky. Change detection is a technique for minimizing updates to the DOM to avoid the suckiness.

I implemented word processors, and I've used a technique called 'double buffering' to rerender complete pages off-screen, fast. And then update the screen smoothly. If we used a proper word processor engine to display our UIs instead of a browser engine then we'd have no need for React etc... After decades, Chrome finally has a rational equivalent to this technique called the View Transitions API.

My hope is that the days of doing change detection are numbered and we can finally leave all this change detection crap behind us.

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

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

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

#44

Earlier quoted context omitted.

Well it is very new. React has a massive inertia, so it dominates for now. I do FE work and see Svelte is gaining popularity.

2016 is not very new

Probably as much as the 3 year difference is the fact that Facebook made and evangelized React. I know I didn't hear about Svelte until 2018-2019, but I knew about React within a few days of its release.

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

#45
post #40

Earlier quoted context omitted.

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.

Using the current date for the article /s

There must be a browser plugin that offers the date a website was first indexed.

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

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

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

#48
post #22

Earlier quoted context omitted.

Those are trivial to solve for and then once you do solve for it its just a matter of copy/paste from project to project with about 10 minutes of rewiring. That costs dramatically less than spinning up a large framework project to project, but frameworks save on training time because most developers cannot solve for these problems on their own.

You're describing an inhouse framework

That is called Affirming the Consequent. Something like: all frameworks are composed of code so therefore all code eventually forms frameworks. It's a common form of nonsense.

https://en.wikipedia.org/wiki/Affirming_the_consequent

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

#49
post #24

I’m not technical enough for this. I thought a front end was about the user.

It is. But the hardest thing about the user is interacting with them. When the user does something, something in the program changes, and you have to change the screen to match. Or updating the screen when some information comes in from outside (like an API call).

That's basically what the article is about: keeping state in synch with the user interface. There are a bunch of different ways to do it. TFA compares a few of them.

A front end has to do a lot of other things, and it's kinda overstating it to say that state is "the single most important factor". But maybe not by much.

Post reply on HN