News for hackers. Stuff that matters.
Re:React Concurrent Mode by marcosdumay on Thursday October 24, 2019 @05:23PM (#21349327)
> 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.

Re:React Concurrent Mode by _bxg1 on Thursday October 24, 2019 @05:28PM (#21349386)
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.
Re:React Concurrent Mode by dnautics on Thursday October 24, 2019 @06:03PM (#21349663)
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
Re:React Concurrent Mode by numtel on Saturday October 26, 2019 @01:56AM (#21361983)
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.

Re:React Concurrent Mode by kokx on Thursday October 24, 2019 @06:28PM (#21349847)
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

Re:React Concurrent Mode by bryanrasmussen on Thursday October 24, 2019 @07:08PM (#21350108)
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