[HN Gopher] What differentiates front-end frameworks
___________________________________________________________________
What differentiates front-end frameworks
Author : thunderbong
Score : 141 points
Date : 2023-07-19 19:00 UTC (3 hours ago)
(HTM) web link (themer.dev)
(TXT) w3m dump (themer.dev)
| emorning3 wrote:
| 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.
| spankalee wrote:
| > the fact that interacting directly with the browser DOM is
| very slow and blinky.
|
| This is not really true, or at least hasn't been for many
| years.
|
| Change detection's primary purpose is to let other code know
| when something has changed, and what changed. You could
| theoretically re-render all your DOM based on that information,
| and in many cases that works much better than people expect.
| But the DOM is stateful, and truly large trees of 1000s of
| nodes are too slow to update, so frameworks try to also do
| minimal DOM updates.
|
| > 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
|
| This is also not really true. The browser doesn't update the
| screen until an animation frame. Anything you do synchronously
| is _not_ rendered to the screen until code yields to the event
| loop. Even many async things, done on the microtask queue,
| block the next animation frame giving us visually atomic
| updates.
|
| Lit, for instance, uses this to get async, batching rendering
| without unintended partial renders of the screen.
| JohnFen wrote:
| > I've used a technique called 'double buffering' to rerender
| complete pages off-screen, fast.
|
| I'm absolutely not a web dev (as this comment will make clear),
| but I'm very surprised that browsers haven't been doing this
| all along. I just assumed that they did.
| cloogshicer wrote:
| 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?
| hinkley wrote:
| At peak jquery, I argued successfully for storing the
| metadata on DOM, because then you have a system of record,
| upon which you can build a straightforward source of truth.
| React does a ton of work to solve that architectural puzzle
| another way.
|
| The thing I have run into over and over again is that when we
| try to pretend the system is Y when it is in fact X,
| inevitably the impedance mismatch results in 1) bugs that
| should be easy to reason about but are difficult to fix, and
| 2) a form of pulling the ladder up behind you.
|
| If I want to continue to work on interesting things I have to
| be able to carve out chunks of my code to gift to #3 on the
| bus number list, so I have the bandwidth to double down on
| some other topic or expand into another.
|
| I know which side my bread is buttered on. Many don't. Which
| is why I have a more consistent supply of mentees than many
| of my peers.
| hombre_fatal wrote:
| > I argued successfully for storing the metadata on DOM
|
| Who did you convince?
| stickfigure wrote:
| 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.
| hinkley wrote:
| I just don't think DOM->JSON->server->microservice->DB->m
| icroservice->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.
| lincon127 wrote:
| So what are you disagreeing with? Are you disagreeing that
| change detection is what mostly diffentiates the front-end
| frameworks? If so, what is that important factor that
| differentiates them if not the mechanism that modifies when
| change is detected? Why do you have such a strong belief that
| this factor isn't it?
| travisjungroth wrote:
| They're disagreeing with change detection being the most
| important part of a frontend framework by suggesting that the
| browser API change dramatically so that we fix the important
| problem of... change detection in frontend frameworks. Yeah
| it's not the most consistent.
| naasking wrote:
| Change detection has nothing to do with the speed of DOM
| updates, it's about directly encoding dataflow dependencies to
| avoid code duplication and redundant UI updates. You could
| paper over the lack of dataflow updates by just updating the
| whole screen every time, but you still need to preserve various
| state, like scroll positions, highlighted text, etc. which
| still means only some state changes and other state does not.
| hinkley wrote:
| With the exception of list comprehension, which is IMO not only
| the best feature of jquery but almost enough of a reason to use
| it on its own, browsers have copied most of the features at
| this point. Do you (or anyone else here) see an opportunity to
| copy features from React into the browser?
|
| I know there have been earlier tricks to pop elements off the
| DOM, modify them heavily and then pop them back on. I wonder if
| it would be better to a) provide a way to mark a node and it's
| children as suspended reflow, or b) provide a virtual view
| where you can do operations on off-DOM nodes including ones
| that typically trigger reflow. c) something else entirely
| NewEntryHN wrote:
| In all cases you're going to store and manage your state some
| place. What you describe is managing the state using the DOM
| itself, which would indeed be easier if the DOM wasn't directly
| tied to the screen, but which would still be very cumbersome
| because of the lack of appropriate APIs for managing the DOM as
| an application state.
|
| If you were to go in this direction, you would eventually make
| the DOM less DOM-ish, and the painting mechanism more DOM-ish,
| effectively shifting everything one place and going full circle
| back to the frameworks.
| boxed wrote:
| 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.
| crooked-v wrote:
| For example, there's the way it's _still_ impossible to pass
| data between native Web Components without stringifying it
| first.
| spankalee wrote:
| This is an absolutely stunningly false and ignorant
| statement. I can't believe it's still being repeated.
|
| Web components are objects and they have properties that
| can be set. The entire web components community - which
| includes the developers of apps like Photoshop, Reddit,
| Chrome, Firefox, and a lot more - passes properties down
| through trees of web components _all the time_.
| WickyNilliams wrote:
| Not via html attributes. But it's never been a problem to
| pass data via JS properties:
| someWebComponent.data = { foo: "bar" }
| [deleted]
| jeremyjh wrote:
| You want to store your application state in a widget tree? This
| was the part about the old bit 'o jquery approach that drove me
| absolutely batshit. The logical state of your UI is strewn
| about in Dom objects and their listeners, closures etc. There
| is no one place you can go to see what state is relevant to
| this component.
| infogulch wrote:
| We need DOM transactions.
| nwienert wrote:
| 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.
| tabtab wrote:
| DOM wasn't meant for real GUI's and trying to trick it into
| being one seems a fool's errand. It was meant for static
| documents. DOM is the wrong tool for the job.
|
| Time for a new state-ful GUI markup standard so we don't have
| to rely on the whacky DOM to get expected and common GUI
| idioms.
|
| Maybe build the "engine" on top of the Tk or Qt kits to avoid
| starting from scratch.
| garganzol wrote:
| 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.
| robear wrote:
| 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 updates.
| emorning3 wrote:
| 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 own virtual DOM, so this I can no longer do this. I have
| to do everything the React way. Developing with React is far
| less powerful than JQuery. I still find modern frameworks to
| be a kind of straight-jacket. I hope to have my transforms
| back in a rational way someday.
| ramesh31 wrote:
| Unpopular opinion, but I just simply don't care about performance
| benchmarks between frameworks at all. If thats something you're
| actually faced with, you should be writing your own perf specific
| code. The only thing I care about is support. Can I hire people
| that know this? Is it easy to onboard? Is there a ton of really
| solid open source plugins and packages compatible with it? Is
| there an LTS version? These are the only things that really
| matter day to day.
| AceJohnny2 wrote:
| Offtopic:
|
| The cursive italics are apparently a feature of the Victor Mono
| [1] font used for the full page. While it'd be amusing in Tumblr
| context (where cursive is used for hyperbolic emphasis), I can't
| fathom why one would consider it in a code context, but to each
| their own...
|
| You can change it (at least on Safari) by going into developer
| tools, clicking any node, and removing "Victor Mono" from --font-
| family
|
| [1] https://rubjo.github.io/victor-mono/
| andrewl-hn wrote:
| Victor is also an extremely narrow font. The author of the font
| motivates it as means to squeeze more code per line. Not only
| it would make longer lines more tolerable, but also for short
| lines it reduces the eye movement needed to scan the line.
|
| However, I personally find the narrowness more tiring for the
| eyes to the point that it is even more distracting than the
| cursive.
| jbs55 wrote:
| This also threw me off
| 8organicbits wrote:
| One of the first things I do on a new browser install is to
| disable web fonts. I've never seen a site where they improve
| things, often they flicker in after page load, which is
| jarring.
| timcavel wrote:
| [dead]
| colordrops wrote:
| 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.
| jasmer wrote:
| [dead]
| jbs55 wrote:
| I'm not technical enough for this. I thought a front end was
| about the user.
| jfengel wrote:
| 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.
| ngFanboi45 wrote:
| > Angular's change detection is a disaster. The developer gets
| two suboptimal choices: (1) the slow and naive default
| implementation, or the complexity of managing change detection
| manually.
|
| This is completely wrong. The "naive" approach is the one you
| should always use, with the onpush strategy reserved for breaking
| certain cascading situations manually. But the default approach
| works perfectly fine, it is performant enough, and even more when
| compiled for production, as it runs only once (as compared to
| twice in the debug mode). The author is incorrectly assuming that
| the change detection is slow because it is automatic. That's the
| entire point of the framework btw.
| austin-cheney wrote:
| That is putting the cart before the horse. Frameworks solve for a
| fundamental business problem well before ever approaching any
| technical problems. A front-end framework is an architecture in a
| box, a pre-designed composition. There are a couple of business
| reasons for that:
|
| 1) Provides a common externally defined abstraction, so that
| developers require less training and are more disposable.
|
| 2) Supplement skills of unskilled developers
|
| The reason frameworks do not primarily solve for change
| detection, is because the browsers already provide that.
| Frameworks provide an additional solution riding on the browser's
| solution as an abstraction. Framework don't even really solve for
| a common set of standards either, because the browser provides
| that too. I really want to say that major frameworks provide for
| a more narrowly construed set of APIs and design approaches, but
| the APIs on modern frameworks are absolutely massive, so I cannot
| say that either.
|
| So... frameworks are really just an abstraction to achieve a
| particular design approach, whether good or bad.
| whatshisface wrote:
| 3) Saves you from having to rewrite dataflow and state
| management code with every project. (Saving time is a business
| factor.)
| austin-cheney wrote:
| 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.
| [deleted]
| quest88 wrote:
| You're describing an inhouse framework
| austin-cheney wrote:
| 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
| shigawire wrote:
| What is the difference between code you've written that
| you use from project to project and a framework?
|
| If it is just about the knowledge then wouldn't it be
| valid to just gain that same knowledge about a framework?
| onion2k wrote:
| I don't agree, because in my experience every framework is _fast
| enough_ unless you 're either past what it's capable of (you
| probably aren't) or you're using it wrong (you probably are). It
| is _far_ more important to fine a framework that you like and
| that you understand, because then you 'll write good code that
| the framework can run fast.
| mianos wrote:
| I agree. Of course there is no 'single factor' for almost
| anything.
|
| So, going with the themes of attention seeking hyperbole, I
| would say the 'single biggest factor', is the ability to find
| and keep skilled developers in any of these top 10 frameworks.
| The differences mean _nothing_ when the bigger picture is
| considered.
| alana314 wrote:
| 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.
| boringuser2 wrote:
| This is an issue of you not understanding how to properly
| manage the state of your application, not React.
|
| It's very likely that you're using effects improperly.
| joshribakoff wrote:
| 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
| dezmou wrote:
| React is not reactive at all, the "state" management is you
| calling a function "setState" to re-render the component.
|
| And I find manual render very usefull and once you do it, you can
| have a global state as simple as a global object, no need to use
| useState anymore.
|
| https://github.com/dezmou/useRender
| boringuser2 wrote:
| This is extremely inadvisable for numerous reasons and goes
| against the entire design philosophy of React.
|
| In short, injecting a naive render function over the react
| virtual dom calculation is wildly inefficient.
| dezmou wrote:
| This piece of code only rerender the component as if you do a
| setState, in fact it does a setState under the hood, maybe
| the word "render" is missleading.
| [deleted]
| yakshaving_jgt wrote:
| 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". Surely everyone just needs the one that is most
| efficient and least broken.
| mark38848 wrote:
| Don't you find a language without higher-kinded types or type
| classes frightening, too?
| yakshaving_jgt wrote:
| Funny :)
|
| I'm not sure how to answer this question. Any serious answer
| would spoil the joke.
| croes wrote:
| What about Solid.JS?
| grayrest wrote:
| Solid works differently in that the output is implemented as a
| side effect of a subscription to a piece of state. Simplified,
| think of a signal as an event emitter and a variable with a
| getter and a setter. Using the getter adds its downstream
| effects-most notably adding/modifying DOM nodes-as an event
| listener. Using the setter updates the state and triggers the
| event listeners.
|
| Most other frameworks here (all? not sure about Vue) will
| invalidate and rebuild an entire component subtree if a piece
| of state in them changes. The solid runtime doesn't care about
| components so changing a piece of state high in a subtree will
| only update the piece of the DOM directly depending on that
| state and not any nodes that were authored as sub-components.
| MauranKilom wrote:
| 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?
| tl wrote:
| React:
|
| - had a 3 year head start on Svetle (2013 vs. 2016)
|
| - has major engineering orgs behind it. Facebook started it.
| Microsoft makes it work with Typescript.
|
| - is easier to get started with. While JS-compilation is
| common, it's required for Svetle.
|
| Svelte isn't free of pain points. Like any form of magic, it
| has edge cases. It's better but not "better enough" to de-
| throne React.
| boringuser2 wrote:
| My experience:
|
| JSX is the best templating language.
|
| Svelte hides complexity and this can bite you in tracking down
| issues.
|
| React just feels better to me for a professional project,
| though I like Svelte.
| simlevesque wrote:
| > maybe someone can shed some light into the downsides of
| Svelte
|
| The automatic handling of dependencies and recomputing means
| you have less control over how updates work.
|
| Also I think it is important to understand the mutations going
| on in your ui. Having them explicit like in Vue makes it easier
| to understand what is gonna happen by looking at the code
| versus the implicit way that Svelte uses.
| grayrest wrote:
| > 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.
| boringuser2 wrote:
| Why do you care about compilation output?
|
| Also, your component sounds cumbersome.
| kabes wrote:
| Because the article makes it sound like your application
| code will be smaller because you don't need to ship the
| change detection library/framework. But in a big enough
| application, the explicit change detection code added by
| the compiler adds up to more lines of code than most
| frameworks.
| i-use-nixos-btw wrote:
| 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 bunch of stuff it
| doesn't need to be doing because it's taking my specific
| use case and making it conform with its own model for doing
| generic things, I don't like it.
|
| I was a web developer back when tables for layout, HTML
| attribute soup for styling, and applets for interactivity
| were going out of fashion. Semantic HTML and CSS for layout
| and styling and JS for interactivity were coming into
| fashion. Divs for layout, class soup for styling, and JS
| frameworks for interactivity hadn't yet become mainstream
| when I stopped.
|
| So my default is lean HTML, lean CSS, raw JS. Maybe JQuery
| if needs be. It's an outdated default, but it's mine. The
| thing is, I get great load times and performance for what I
| need. What I need is normal dashboard stuff - though
| because of the nature of the field I work in, it condenses
| a lot of information onto a page and that information is
| updating many times per second.
|
| I don't seem to get enough performance from the frontend
| frameworks I've tried. I don't know if it comes from code
| bloat, or deep call stacks through god knows how many
| levels of indirection, the way DOM updates are issued, or
| something else - but it has just never seemed worth the
| learning curve to end up with something I can't do myself
| with admittedly a lot of work.
|
| As such, I find this review helpful. 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. If it's bloaty
| because it isn't doing backflips through the call stack,
| but is inlining code - that's familiar territory and
| certainly something I can deal with.
| pmarreck wrote:
| The problem is, there is no panacea in technology, only
| tradeoffs. Svelte does look pretty sweet though.
| satvikpendem wrote:
| 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.
| Aerbil313 wrote:
| 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.
| bobolino123 wrote:
| 2016 is not very new
| boringuser2 wrote:
| Actually, that's very old in frontend years.
| karaterobot wrote:
| 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.
| [deleted]
| bob1029 wrote:
| > There are tons of blog posts on the internet about how
| frameworks differ and which one to pick for your next web
| project.
|
| You can also just not pick one.
|
| MDN is my anti-framework.
| kaishiro wrote:
| MDN has a great series of guides on front end frameworks :)
| https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...
| nsxwolf wrote:
| 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.
| MatekCopatek wrote:
| Most of the major frameworks (I'm 100% sure about Vue and
| React) have browser extensions that give you extremely powerful
| dev tools. It's not _exactly_ what you're asking for, but
| pretty close. You can actually click on a random thing, see
| which component it is, what kind of state it's holding
| internally etc.
| frio wrote:
| You may be looking for `sourcemap`s, which store a record of
| the transpilation that has happened and let you work backwards.
| Your browser's tools should fetch them by default if they're
| available, but depending on your frontend stack, they may not
| be generated by default.
| RandallBrown wrote:
| 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.
| rubinlinux wrote:
| And vuejs has a browser plugin which can sort-of show you
| which components call which components to get there.
| commotionfever wrote:
| 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
| jchook wrote:
| VanJS[1] seems to have a somewhat different approach.
|
| The entire framework is surprisingly simple and easy to
| understand. In benchmarks I've seen it perform well, even better
| than SolidJS.
|
| 1. https://vanjs.org/
| gatvol wrote:
| Not a single mention of URLs, statefulness ...
| r_singh wrote:
| 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?
| hbn wrote:
| It flashes a dark theme for a half a second before switching to
| light
| sambroner wrote:
| 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.
| 8organicbits wrote:
| Interesting. I'm seeing something slower. Pagespeed shows 2.7
| seconds:
|
| https://pagespeed.web.dev/analysis/https-themer-dev-blog-
| the...
| lelandfe wrote:
| FCP is limited by transform.js, whatever that is. It looks
| pretty chunky. https://www.webpagetest.org/result/230719_Bi
| DcSR_DDD/1/detai...
| sambroner wrote:
| Even just an eye-test shows it's much faster than that for
| me.
|
| Pagespeed shows .6 for desktop, but locally I'm seeing
| frames loaded under 350ms. I would have guessed much
| faster, but I guess the devtools don't lie.
| esrauch wrote:
| I think devtools can lie in the sense that it can be
| slower when devtools is open in some circumstances.
| rustybolt wrote:
| Impressive? This is the default. You have to actively do
| stuff to make it slower.
| travisjungroth wrote:
| You have to actively do stuff to make a house messy, but it
| can still be impressive when it's clean.
| dylan604 wrote:
| I find it the opposite. You have to actively clean a
| house, but do nothing and it won't be clean
| [deleted]
| formerly_proven wrote:
| Served from a service worker after the first load
| NewEntryHN wrote:
| 52ms for me. Pretty standard for an HTML page.
| suralind wrote:
| Served via service worker, but still Cloudflare serves it
| faster than my very minimalistic static blog. Perhaps it uses
| paid Cloudflare plan?
| beebeepka wrote:
| The way we do SPA is kinda nonsensical because we're fighting the
| browser. It would be great if we could simply change a value then
| see the result on the screen at the next tick. DOM is great but
| not ideal for truly dynamic stuff with lots of things going on,
| which is pretty much the worst case for the tech.
|
| Really dynamic apps can be really fast with canvas but I am not
| we have the tools to replace DOM websites just yet. Maybe in a
| decade.
| franey wrote:
| 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.
| spankalee wrote:
| Svelte isn't a strict win-win. It requires a compiler, and forks
| of JavaScript and HTML.
|
| And it isn't actually very different from React or Vue anyway,
| and in fact quite a bit more limited than Vue (not necessarily
| bad).
|
| Saying: "I'll figure it out for you at compile
| time." --Svelte
|
| is just a non-technical, basically non-meaningful statement.
|
| You need to know _what_ it figures out exactly. What state and
| what state changes are observable? These things matter more than
| whether it's done at compile time or runtime.
|
| And I think the author is ascribing far more power "compile time"
| than what's actually happening. Svelte is not doing some kind of
| sound data flow analysis on your JS code to figure out what could
| change and rewriting your code to be observable (something not
| really possible anyway). It's using specific syntax conventions
| to make some variables into shallowly observable properties. And
| it adds "store" concept, which is more-or-less Signals as
| popularized in Solid, now Preact, and soon Lit and Angular.
| lnenad wrote:
| > Svelte isn't a strict win-win. It requires a compiler, and
| forks of JavaScript and HTML.
|
| These points weren't touched upon by the author. He compared
| the frameworks from one perspective and one perspective only.
| sublinear wrote:
| > Instead, we'll go directly to the crux of the main problem
| front-end frameworks set out to solve: change detection, meaning
| detecting changes to application state so that the UI can be
| updated accordingly. Change detection is the fundamental feature
| of front-end frameworks, and the framework authors' solution to
| this one problem determines everything else about it: developer
| experience, user experience, API surface area, community
| satisfaction and involvement, etc., etc.
|
| I disagree. Sure that's at the core of how a framework is
| written, but all the developers really care about are the
| interfaces. The user doesn't care at all unless it doesn't work
| or is annoying to use.
|
| If your interfaces are dictated by the way the event loop is
| written, there's something wrong that needs to be decoupled.
| Events should be generic and interfaces should be arbitrary to
| what developers want.
| phailhaus wrote:
| Since it's at the core of how a framework is written, it
| affects what the developers must handle and therefore the
| interfaces that are possible. If you know how a framework
| handles change detection, you already know something about the
| interface it must expose.
| dadsquad wrote:
| can't forget library support.
| 12_throw_away wrote:
| Interesting to compare these with the results on the js-
| framework-benchmark page [1] (with the usual caveats about
| benchmarking). Without actually running the numbers,
| qualitatively it looks like there are 3 performance tiers:
| VanillaJS (fastest); Vue, Svelte and Elm (often close to
| vanilla); and Angular and React (sometimes comparable, sometimes
| much slower).
|
| [1] https://krausest.github.io/js-framework-
| benchmark/current.ht...
| avereveard wrote:
| Nyeh. The most important factor in a framework is debuggability
| if the stack trace is messed up and the frames are polluted by a
| hodge podge of state variables I want nothing to do with it.
|
| The rest is nice to have.
| ChrisArchitect wrote:
| From June since no date on it
|
| Shared by the dev https://news.ycombinator.com/item?id=36403909
| pmarreck wrote:
| Technical blog posts without a date should be illegal
| pc86 wrote:
| 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.
| exac wrote:
| Using the current date for the article /s
|
| There must be a browser plugin that offers the date a
| website was first indexed.
| pc86 wrote:
| I seem to recall a (non-technical) blog getting called
| out for basically generating a random date within the
| past month or so for a lot of its content, but that might
| just be a false memory.
| pmarreck wrote:
| That's a brilliant idea, if someone else hasn't already
| implemented it
| mgaunard wrote:
| There is only one important factor: the frameworks others wrote,
| and the ones you wrote yourself.
| rubymamis wrote:
| QML wins with bindings and signal and slots! (In this example the
| the _text_ property of the Text componenet is binded to _count_ ,
| so whenever count changes the text changes).
|
| ```
|
| property int count: 0
|
| Button { onClicked: { count--; } }
|
| Text { text: count.toString(); }
|
| Button { onClicked: { count--; } }
|
| Button { onClicked: { incrementLater.start(); } }
|
| Timer { id:incrementLater interval: 1000 onTriggered: { count++;
| } }
|
| ```
|
| Better in so many ways.
| tashoecraft wrote:
| Haha, the anti angular bias in this is so strong. From getting
| things just wrong to presenting their own feelings as fact. Makes
| me discredit the rest.
| heisenbit wrote:
| I find looking at component level change detection without giving
| equal space to the store change detection and the integration
| between the two insufficient.
___________________________________________________________________
(page generated 2023-07-19 23:00 UTC)