3 ms·

Can we please just get the ECMAScript body to backport some of these common features into the core language itself? I can't keep up with all the javascript fram

Can we please just get the ECMAScript body to backport some of these common features into the core language itself? I can't keep up with all the javascript frameworks of the day :( By the time I finish one feature, ten new frameworks have popped up. I can no longer tell the difference between innovation and anarchy.

worldsayshi 5y ago
>I can no longer tell the difference between innovation and anarchy I think this is kind of the thing with innovation. Innovation is anarchy until the point where the innovation is accepted as best practice. And at that point it's not really innovation. It's just best practice.
- technobabbler 5y ago
  Yeah, but we shouldn't need 15, no, 17, no, 27... different ways to "update the UI when the data changes after an API call". Just one good one -- not necessarily the best, just good enough. Something a bit more advanced than fetch, not quite as complex as useContext. To the end user, websites haven't really changed all that much since the early AJAX days. Input gets received, ajax happens, shit gets updated. Why has the tooling gotten 1000x more complex?
maccolgan 5y ago
Congratulations, now every browser (oh wait, there's only 1 real browser) will implement it slightly differently and you'll use a library once again to reconcile all of them. (Also old browsers, browsers implementing the non-final version of the spec)
- technobabbler 5y ago
  A polyfill lib is different from an entire framework. Besides, even if you use a framework, you still have to polyfill for browser diffs anyway. But with ES standards, at least the code can be largely the same, not as different as vanilla/jQ/React/Angular/Svelt/Vue/someotherslickonewordjsframeworkdujour
lhorie 5y ago
I suggested one such idea (a diffing version of innerHTML) years ago to Mozilla. Ironically, the React team was against it and it fizzled out. In more ironic twists of events, someone eventually wrote a JS implementation of it: https://github.com/tbranyen/diffhtml/tree/master/packages/diffhtml https://github.com/tbranyen/diffhtml/tree/master/packages/di... and nowadays people are talking about HTML-based rendering engines again, making this idea somewhat relevant once more. To be fair to standards bodies, they have done some work. Element.append now exists to make hyperscripts a bit more straightforward, and a lot of reactivity semantics can be implemented on top of Proxy.

worldsayshi 5y ago

>I can no longer tell the difference between innovation and anarchy I think this is kind of the thing with innovation. Innovation is anarchy until the point where the innovation is accepted as best practice. And at that point it's not really innovation. It's just best practice.

technobabbler 5y ago
Yeah, but we shouldn't need 15, no, 17, no, 27... different ways to "update the UI when the data changes after an API call". Just one good one -- not necessarily the best, just good enough. Something a bit more advanced than fetch, not quite as complex as useContext. To the end user, websites haven't really changed all that much since the early AJAX days. Input gets received, ajax happens, shit gets updated. Why has the tooling gotten 1000x more complex?

maccolgan 5y ago

Congratulations, now every browser (oh wait, there's only 1 real browser) will implement it slightly differently and you'll use a library once again to reconcile all of them. (Also old browsers, browsers implementing the non-final version of the spec)

technobabbler 5y ago
A polyfill lib is different from an entire framework. Besides, even if you use a framework, you still have to polyfill for browser diffs anyway. But with ES standards, at least the code can be largely the same, not as different as vanilla/jQ/React/Angular/Svelt/Vue/someotherslickonewordjsframeworkdujour

lhorie 5y ago

I suggested one such idea (a diffing version of innerHTML) years ago to Mozilla. Ironically, the React team was against it and it fizzled out. In more ironic twists of events, someone eventually wrote a JS implementation of it: https://github.com/tbranyen/diffhtml/tree/master/packages/diffhtml https://github.com/tbranyen/diffhtml/tree/master/packages/di... and nowadays people are talking about HTML-based rendering engines again, making this idea somewhat relevant once more. To be fair to standards bodies, they have done some work. Element.append now exists to make hyperscripts a bit more straightforward, and a lot of reactivity semantics can be implemented on top of Proxy.