4 ms·
But even better: 1) Use a framework/language that is optimized by default instead one that is slow by default. Ex: Svelte only recalculate only the part of the
by ChrisCinelli 7y ago
But even better:
1) Use a framework/language that is optimized by default instead one that is slow by default. Ex: Svelte only recalculate only the part of the UI affected by a change. Most of the other frameworks recalculate the whole virtual DOM.
2) When you can write something fast or slow in the same amount of time go for the fast one. It seems trivial even mentioning it but sometimes people with "make it work first, make it better later" do not even spend few seconds pondering this.
- JMTQp8lwXL 7y agoPractically, not much can be quickly built in Svelte. There's thousands of React components I can download right now to solve my problems. Shipping features to users has a much bigger impact on a business than subpar page load times.
- tobr 7y ago“not much can be quickly built in Svelte” - is this an experience you actually have from trying it? Because it’s very far from what I’ve experienced. So many things in Svelte can be done with surprisingly little code. Also in my experience, those thousands of React components are going to be a source of new problems. The more of them you have, the more likely you’ll run into frustrating limitations that contorts your code to an unmanageable mess.
- JMTQp8lwXL 7y agoI do not. However, I have used React and Angular and they all take roughly some baseline amount of effort to achieve anything. And in all of them, I've had a times the need to rely on the community to ship product features faster. Have you tried implementing accessible drag-and-drop lists? Atlassian, for example, has spent years working on that problem, making a well-polished, enterprise-grade, cross-browser dnd solution (react-beautiful-dnd). And DND might be just a small feature of any otherwise much larger app. Foregoing all of these existing tools to start with a new UI framework is not a decision to be made lightly.