281–290 of 337 posts
I can't trade TSX for any text templates. Being able to write tags and having them syntax-checked with types support is indispensable. I wish that those frameworks embrace TSX rather than trying to drag users to the dark past.
Svelte supports TS.
Earlier quoted context omitted.
Serious answer? SEO and accessibility. HTML lets search engines crawl pages and screen readers read pages (which can often be a legal requirement). If we're rethinking the web stack I'd advocate for htmx with wasm-based web components for more complicated stuff like if you needed to polyfil in some new image format, or run a terminal emulator, or do webrtc calls with your own fancy custom noise reduction algorithm. Y…
> Serious answer? SEO and accessibility. How is WASM less accessible than Javascript? Are crawlers parsing minified and obfuscated Javascript sources and deriving meaning from them in a way they couldn't from WASM code?
I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…
Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from do…
I think this is the key take away.
React is great and offers a lot of tunability in terms of performance but to me it often feels a lot like writing low level code.
When I use something like Vue, Petite-Vue, Svelte, Angular (flawed but underrated) - it feels like using something high level (like an ORM) that is designed to take something difficult and map it to something human readable.
The relationship between my changes in code/state ergonomically translate across to the template and that leads to very maintainable applications.
In reality though, despite the endless stream of blogs telling you how to write React applications, React isn't prescriptive on how you write it. You can create "view models" with proxy objects to implement primitive data-binding in components and use Context to inject dependencies.
In fact I once wrote a compiler that compiled html template syntax into `React.createElement()`, and along with a supplied runtime I was able to use React as a backend for a reactive template renderer.
> Svelte and Vue approach to SFCs
I have personally found SFC to be super annoying given they are not optional and require custom tooling.
A single file is nice sometimes but I don't really mind if a component is split into 3 files (js, css, html) as long as they are associated with each other somehow. I just want to ensure that my view renderer requires the least amount of tooling possible so my project will stand the test of time and I can be self reliant for updates.
Can I use my own test runner? Can I pick my version of TypeScript? Can I setup my own eslint? Can I set up my own css preprocessor? Can I use custom compiler configuration (like using SWC)?
To me, the fact that React doesn't require a compiler (aside from translating jsx) is its greatest asset, and Vue/Svelte and Angular's greatest shortfall.
It's just a shame that React is so fiddly to work with
I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…
Mobile phones have gotten faster, and so have mobile js improvements, so I wouldn't be surprised if it's negligible overhead these days.
Earlier quoted context omitted.
Oh geez. It's Internet Explorer CSS Behaviors all over again. "Those who do not learn from the past…"
Close but not exactly, there is no esoteric HTC stuff for example. element.selector { prototype: ClassName url(in-module.js); color: blue; ... } That above is significantly better than almost-dead-at-birth WebComponents: let customElementRegistry = window.customElements; customElementRegistry.define('my-custom-element', MyCustomElement); One simple CSS property instead of 20+ additional entities https://developer.moz…
Meanwhile, shit that would actually help framework authors, like native morphDOM don’t happen.
Imagine being someone in the semiconductor industry reading this. You're at the absolute pinnacle of high-tech and are approaching the limits of material reality to realize a 20% faster CPU. It's a true super human accomplishment. Software developers: well yes, 99% of the cycles I use are completely needless, but it's still plenty fast enough! Which we justify with the idea that a framework like React is abstract, he…
Any device with a modern web browser can run a React application. Sure, Electron and the alternatives are resource hungry, but they allow developers to create true cross-platform applications.
Sure, there are other ways to create a cross-platform app, but none of those approaches allow you to tap into the massive number of web developers that exist.
Earlier quoted context omitted.
The main divide I've observed is whether you are encouraged to use JavaScript's built-in control flow and code reuse mechanisms or a less expressive DSL. Hooks are pretty sweet but I think they should have launched with higher order hooks that used the same lifecycle as original React. That way you wouldn't need to think too hard about things like object identity (which I think is the state management issue you're ge…
What makes the svelte template language less expressive than JSX in your view? Props and expressions will look similar in both (minus the useXX ceremonies), and the rest is all loops and if conditions. Writing simple inline conditions in JSX is painful, so it already starts with a negative score.
Earlier quoted context omitted.
Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from do…
> templating makes it far easier to understand I think this is the key take away. React is great and offers a lot of tunability in terms of performance but to me it often feels a lot like writing low level code. When I use something like Vue, Petite-Vue, Svelte, Angular (flawed but underrated) - it feels like using something high level (like an ORM) that is designed to take something difficult and map it to something…
When I demo side projects and my own work to my coworkers they are always surprised "I didn't know you could do that!" and the thing is they can't because they are all stuck using React.
Earlier quoted context omitted.
What makes the svelte template language less expressive than JSX in your view? Props and expressions will look similar in both (minus the useXX ceremonies), and the rest is all loops and if conditions. Writing simple inline conditions in JSX is painful, so it already starts with a negative score.
The template language doesn't compete with JSX. It competes with JSX + JavaScript, which is far more expressive.