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…
What differentiates front-end frameworks
101–110 of 256 posts
Re: What differentiates front-end frameworks
#102Re: What differentiates front-end frameworks
#103Earlier quoted context omitted.
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
If it is just about the knowledge then wouldn't it be valid to just gain that same knowledge about a framework?
Re: What differentiates front-end frameworks
#104Offtopic: 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]…
However, I personally find the narrowness more tiring for the eyes to the point that it is even more distracting than the cursive.
Re: What differentiates front-end frameworks
#105This 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?
Re: What differentiates front-end frameworks
#106Earlier 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.
Re: What differentiates front-end frameworks
#107I 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.
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.
Re: What differentiates front-end frameworks
#108You 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…
Re: What differentiates front-end frameworks
#109Earlier 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.
Re: What differentiates front-end frameworks
#110Totally 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…
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.