3 ms·
Great questions! >Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers? The basic concept of "bind
by dimmke 4y ago
Great questions!
>Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers?
The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does.
I think under the hood, the people who actually write the DOM apis would know how to do that in the most performant way possible. I know any native approach would certainly be faster than a Javascript framework. To me the more important part is getting the API surface right.
That's the big problem with a lot of these standards updates. They kind of half assedly add a feature that's inconvenient and then nobody uses it. They need to think more like "How can we incentivize people to drop X framework and do it natively?"
>if your proposed solution would look similar to current JS solution X, why would it be better than X?
It'd almost certainly be faster being built into the native code, but yes the goal is to remove the build process and tooling. But also to bring things back into balance. Right now, most web apps are a big bundle of JavaScript. But with these changes, it'd be several HTML files, JS files, CSS files. In balance again. Each technology has its own place. I think the average skillset of front-end developers would improve massively if they didn't have to do stuff like chase down NPM problems or debug Webpack.
- Chris_Newton 4y agoI appreciate the ambition to reduce the complexity and tooling overheads. Unfortunately, I doubt we could define a sufficiently general API for the kind of functionality you’re talking about. There is too much variety in the applications we now build with web technologies. Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables. To be fair, that might already be a substantial proportion of all web UI development. But the kind of data binding you’re talking about wouldn’t help at all with implementing a word processor, an FPS game or a data-heavy app built around interactive visualisations. A foundation where UIs are built from simple pieces of DOM derived directly from corresponding variables in JS would severely restrict what we could build on top.
- dimmke 4y agoIn my scenario, it's not like I'm saying JavaScript frameworks can't or shouldn't exist. My point is they have become the default and I don't think they should be. We will always need JS frameworks. It's where some of our best ideas have come from. I just think it's time that some of the most successful ideas make it into the standards.
- crabmusket 4y ago> Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables. That would be a very admirable and IMO sufficient goal. Being able to do "modern forms" with "native" capabilities seems fairly reasonable. The word processor, fps, data heavy requirements are IMO being taken care of by WebAssembly, which is a more appropriate technology for those sorts of things than the DOM is anyway.
- crabmusket 4y agoI look forward to the post coming into my RSS reader :) > they didn't have to do stuff like chase down NPM problems or debug Webpack. The ship has well and truly sailed on that one. Building a reactivity framework into the browser isn't going to solve dependency management or transpiling. But I wonder if ESM is going to change this game a bit. Now that dependencies are statically analysable in the page source, a CloudFlare or similar could sit between the "source" and the browser and do intelligent caching and bundling transparently.