Comment by _bxg1 | Hacker News Reader

Comment by _bxg1 | Hacker News Reader

Parent Full thread

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.

> 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.

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.

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

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.

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

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

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.

> 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.

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.

> I do feel that the application use-case has already been reached

It clearly hasn't though, as demonstrated by this very OP ;)

Everything people are complaining about here, in addition to the problem being addressed by Concurrency Mode, are things that writers of native apps don't have to fight with:

- Lack of concurrency

- Complex, layered build systems

- Several layers of syntax transformation as an industry baseline

- Lack of a consistent story for modules

- Overall jank-proneness

- Platform bloat like that in Electron

But then why re-solve all these problems if you can just build a native app? Because native platforms over the decades have repeatedly tried and failed to a) be truly cross-platform and b) have truly flexible, well-documented layout systems. The web gives us those. We just have to go back in and add the things it lacks.

When all of these problems have been solved and a new framework is still coming out every week, then we can talk about frivolous effort being expended. Until then these are real, worthwhile problems being worked on.

I agree that native platforms have failed to give us the things that the web platform gives us, and that we want those things in our solutions, but it does not mean that we will ever actually be able to add in the things that the web lacks - I suppose that we will be able to but I must also entertain the possibility that there is some mutually contradictory thing in the two paradigms that we are not seeing.

Reply on news.ycombinator.com