4 ms·

Part of it is that the web platform itself can't evolve as fast as industry would like it to, so in the meantime we pull together/test out new features we'd lik

by _bxg1 7y ago

Part of it is that the web platform itself can't evolve as fast as industry would like it to, so in the meantime we pull together/test out new features we'd like to see in JavaScript, until the web can implement them natively. Just look at jQuery: it was a proving ground for fetch(), document.querySelector(), and more. Now it's unnecessary. Part of it I think is that we're still in a period of growing-pains. The web is transitioning from a document platform to an app platform, and until it fully catches up to that mandate, we have to bridge the gap with layers upon layers of frameworks. I think we're entering the downslope of that process, but it isn't finished. That said, I do wonder why there isn't so much as a proposal for native HTML templating (the <template> tag doesn't count). This has been industry-standard practice for 5 years now and would benefit immensely from a native implementation. It seems like it's well past time to get that ball rolling.

marcosdumay 7y ago
> I do wonder why there isn't so much as a proposal for native HTML templating There were XHTML with XLSTs. It was widely rejected, most people didn't even see the point.
- _bxg1 7y ago
  We need a little more than that, though. You can accomplish that right now with JS template string literals and innerHTML: function myComponent(props) { return ` <div> ${props.name} </div> ` } ... document.body.innerHTML = myComponent({ name: "Bob" }); The problem is that it always completely obliterates the DOM, instead of changing just the parts that need to change. The browser, of course, has plenty of information with which to do that in C++ instead of requiring the use of something like React. But for some reason it hasn't been implemented.
  - dnautics 7y ago
    You may be looking for morphdom, which is a very lightweight version of what you want, but of course browser support for this would be nice. https://github.com/patrick-steele-idem/morphdom https://github.com/patrick-steele-idem/morphdom
  - numtel 7y ago
    Lithtml implements declarative DOM using string literals like this very efficiently. I'm of the opinion that sticking with React when Lithtml exists is just fear of writing vanilla classes.
- kokx 7y ago
  That might be because XSLT was very hard to use. There were some XSLT processors, but none of them were in-browser or anything close to that. There were promises of browsers that would implement it, but AFAIK no browser really did. XSLT didn't have a simple syntax either. Looking at XSLT, it basically does what most templating engines do these days. But in a more complicated manner. Just look at Wikipedia's example [1]. About ease of use in programs, if you were using XSLT, you had to output XML which then had to be put through an XSLT processor. If you are outputting XML to another program or database or whatever anyway, that would be possible. But if you are only outputting XML so it can be transformed to XHTML by an XSLT processor, for which you had to write something in XSLT, you could just spare all the hassle and directly output HTML anyway. [1]: https://en.wikipedia.org/wiki/XSLT#Examples https://en.wikipedia.org/wiki/XSLT#Examples
  - bryanrasmussen 7y ago
    I am sorry but you are wrong about several technical issues regarding XSLT. FF and IE had XSLT processors in 2006 and I suppose they still do (although could be wrong about the still do), there were at any rate XSLT processors in browsers back til the early years of this century, although hey, not in every browser. Opera was definitely dead set against ever implementing one. You did not have to output XML, you could output XML, text, or html, depending on the output format the processor would handle how your output format should work (as it was a declarative language) thus if you output html the processor would handle turning XML like br elements into html br elements, not that that is any great thing, but it is a fact you could output other things than XML
XCSme 7y ago
Yes, I think the problem is in way the current web ecosystem is evolving. People notice shortcomings of current browsers, they create frameworks that add the needed functionality (usually in a really hacky way that adds a lot of complexity and creates new problems), browsers acknowledge the potential feature (... wait 5-10 years...) feature is implemented, said framework becomes redundant and everyone now has to learn a shiny new framework. The saddest part is that the shortcoming that the initial framework tries to solve is, most of the times, insignificant compared to the complexity that the framework is adding. The truth is that we are all just "play-testers". We keep mocking new browser features, put them in the real world, test them, and then browsers can easily decide what features really provide value and should be implemented. The real problem is that this is a never-ending cycle. We started to like this creation of new features so much that we never really focus on what we have and try to make the most out of it. We keep adding bloat to fix imaginary problems, when we already have all the tools that we need. I am not referring to new functionality, such as Web Payments or OffscreenCanvas, but to frameworks that try to mimic what the browsers are doing and just do it in a slightly better way.
- _bxg1 7y ago
  > The real problem is that this is a never-ending cycle. That's where I disagree. I think the web was fundamentally unsuited to the "application" use-case and has been making its way in that direction for 5-10 years now. I think once we reach that destination, the churn will drop off dramatically. The platform will become enough, for the most part, and we may shrug off the need for comprehensive "frameworks" altogether in favor of simple libraries, like most other language ecosystems.
  - XCSme 7y ago
    I do feel that the application use-case has already been reached, yet I do not think this cycle speed is going to change. I do hope that at some point this will stop as this cycle is wasting way too many human brain resources which could be otherwise used on more interesting problems.
    - 7y ago

by _bxg1 7y ago

marcosdumay 7y ago

> I do wonder why there isn't so much as a proposal for native HTML templating There were XHTML with XLSTs. It was widely rejected, most people didn't even see the point.

_bxg1 7y ago
We need a little more than that, though. You can accomplish that right now with JS template string literals and innerHTML: function myComponent(props) { return ` <div> ${props.name} </div> ` } ... document.body.innerHTML = myComponent({ name: "Bob" }); The problem is that it always completely obliterates the DOM, instead of changing just the parts that need to change. The browser, of course, has plenty of information with which to do that in C++ instead of requiring the use of something like React. But for some reason it hasn't been implemented.
- dnautics 7y ago
  You may be looking for morphdom, which is a very lightweight version of what you want, but of course browser support for this would be nice. https://github.com/patrick-steele-idem/morphdom https://github.com/patrick-steele-idem/morphdom
- numtel 7y ago
  Lithtml implements declarative DOM using string literals like this very efficiently. I'm of the opinion that sticking with React when Lithtml exists is just fear of writing vanilla classes.
kokx 7y ago
That might be because XSLT was very hard to use. There were some XSLT processors, but none of them were in-browser or anything close to that. There were promises of browsers that would implement it, but AFAIK no browser really did. XSLT didn't have a simple syntax either. Looking at XSLT, it basically does what most templating engines do these days. But in a more complicated manner. Just look at Wikipedia's example [1]. About ease of use in programs, if you were using XSLT, you had to output XML which then had to be put through an XSLT processor. If you are outputting XML to another program or database or whatever anyway, that would be possible. But if you are only outputting XML so it can be transformed to XHTML by an XSLT processor, for which you had to write something in XSLT, you could just spare all the hassle and directly output HTML anyway. [1]: https://en.wikipedia.org/wiki/XSLT#Examples https://en.wikipedia.org/wiki/XSLT#Examples
- bryanrasmussen 7y ago
  I am sorry but you are wrong about several technical issues regarding XSLT. FF and IE had XSLT processors in 2006 and I suppose they still do (although could be wrong about the still do), there were at any rate XSLT processors in browsers back til the early years of this century, although hey, not in every browser. Opera was definitely dead set against ever implementing one. You did not have to output XML, you could output XML, text, or html, depending on the output format the processor would handle how your output format should work (as it was a declarative language) thus if you output html the processor would handle turning XML like br elements into html br elements, not that that is any great thing, but it is a fact you could output other things than XML

XCSme 7y ago

Yes, I think the problem is in way the current web ecosystem is evolving. People notice shortcomings of current browsers, they create frameworks that add the needed functionality (usually in a really hacky way that adds a lot of complexity and creates new problems), browsers acknowledge the potential feature (... wait 5-10 years...) feature is implemented, said framework becomes redundant and everyone now has to learn a shiny new framework. The saddest part is that the shortcoming that the initial framework tries to solve is, most of the times, insignificant compared to the complexity that the framework is adding. The truth is that we are all just "play-testers". We keep mocking new browser features, put them in the real world, test them, and then browsers can easily decide what features really provide value and should be implemented. The real problem is that this is a never-ending cycle. We started to like this creation of new features so much that we never really focus on what we have and try to make the most out of it. We keep adding bloat to fix imaginary problems, when we already have all the tools that we need. I am not referring to new functionality, such as Web Payments or OffscreenCanvas, but to frameworks that try to mimic what the browsers are doing and just do it in a slightly better way.

_bxg1 7y ago
> The real problem is that this is a never-ending cycle. That's where I disagree. I think the web was fundamentally unsuited to the "application" use-case and has been making its way in that direction for 5-10 years now. I think once we reach that destination, the churn will drop off dramatically. The platform will become enough, for the most part, and we may shrug off the need for comprehensive "frameworks" altogether in favor of simple libraries, like most other language ecosystems.
- XCSme 7y ago
  I do feel that the application use-case has already been reached, yet I do not think this cycle speed is going to change. I do hope that at some point this will stop as this cycle is wasting way too many human brain resources which could be otherwise used on more interesting problems.
  - 7y ago