Tagged “frameworks”
Too many tools and frameworks
Great summary of the deluge of tools being made (from 2015!). But with a positive take at the end:
Instead of telling people to stop creating new js frameworks. Instead of discouraging people from adding to the vast amount of available tools, I’m going to encourage people to build even more tools. Pick a problem and try to solve it better than anyone else has before. Having better tools will help us push the web forward. And it’s okay if 90% of them are bad. The 10% will be worth it.
CSS Frameworks, hype and dogmatism
Sensible writeup. The trashing and attacks over gd frameworks is terrible and unnecessary. Use whatever tech you want!
Second-guessing the modern web
Lot of good parts
The high performance parts aren’t React. Mapbox GL, for example, is vanilla JavaScript and probably should be forever. The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too much for any company to include it as part of an SDK. Same with the Observable runtime, the juicy center of that product: it’s very performance-intensive and would barely benefit from a port.
The less interactive parts don’t benefit much from React. Listing pages, static pages, blogs - these things are increasingly built in React, but the benefits they accrue are extremely narrow. A lot of the optimizations we’re deploying to speed up these things, things like bundle splitting, server-side rendering, and prerendering, are triangulating what we had before the rise of React.
See all tags.
