Comment by vanderZwan | Hacker News Reader

Comment by vanderZwan | Hacker News Reader

Parent Full thread

> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem

I think the request for a native API for a Morph DOM/Virtual DOM has a similar problem. He wants a native solution so the frameworks can "focus on differentiating based on the convenience of their APIs", but he's forgetting that any native API will in itself impose a style on the frameworks if the latter want to be performant.

Given the diversity among current solutions, that would be the same as picking one of them to thrive and all the others to be forced to become more like it. Which is the opposite of what he wants.

Also, it's not like you can take any JS-based solution, make it native, and expect it to be faster because now it's made with magic C++ pixie dust.

Also, maybe the different internal data structures among browsers means that they each would prefer different reconciliation approaches, making it hard for them to agree on anything.

I'm not saying that it's impossible to have a well-designed native solution that makes everything nicer, but it's also not exactly a trivial problem to solve. And unlike JavaScript frameworks, once it's standardized the browser vendors are stuck with it, so I can understand if they are conservative about it.

I think one thing to keep in mind is that just because something is available in the browser, that doesn't mean that all other approaches are suddenly moot and will never be able to displace it - XMLHTTPRequest is also still available, for example, but did get replaced by `fetch`.

But in general, you raise a good point - just because something worked well with developer tooling, doesn't mean that it would work well when integrated in the browser. You see the same e.g. when people are calling for runtime type validation in the browser just because they like TypeScript, even though the pros and cons would be completely different.

And XHR is still better than fetch. It supports progress events and SSE. I'm not really sure why fetch exists if it doesn't add new/better functionality. It's handling or lack of handling 302s is crap too. You can set it to "manual" handling but then can't manually handle it.

Fetch exists because everyone just writes a 10 line adaptor function that looks like fetch anyway, so might as well build it into the browser and save the trouble for people who don't need progress events.

Eh... the API is a little nicer but if it's weaker overall I think we might as well keep using the XHR wrappers over bloating the standard API. I end up wrapping fetch with with more niceities anyway.

> XMLHTTPRequest is also still available, for example, but did get replaced by `fetch`.

True, although that also highlights my "once it's standardized the vendors are stuck with it forever" point

Just a heads up, the author is a woman and uses she/her pronouns.

Thanks for the correction, that was sloppy of me (usually I default to "they" when I don't know an author's gender). Too late to edit my comment now sadly.

Reply on news.ycombinator.com