Hacker News Reader

Comment by outsidetheparty | Hacker News Reader

Vue components have the html template, the javascript code, and the component's scoped CSS all in one file. You can define the template in a string, or even in JSX if for some reason you wanted to do that, or you can just use regular old HTML which is stored alongside the javascript that controls it and the css that styles it.

View on HN

That is what I like the most in Vuejs : you have the choice.

This might not apply to the case here, where are talking about code style, but I find that in programming it is often good not to have a choice. More options means more decisions, more decisions means more complexity involved in completing a task, and it means more questions the next person reading or maintaining the code will have.

There are clear patterns in Vue that encourage you to put your filters, methods and every other piece in its place, but at the same time, depending on your deadline you can choose not to create a single-file component for every <li> and just use a <template> tag. I like that! I understand your point, though.

But a template is not "regular old HTML". HTML is a standard for declaring marked up text. What Vue and similar libraries do is make adhoc variants of HTML (all different) with extra looping constructs and if/then constructs and so on. The templates also require embedding snippets of JavaScript code in them -- code which standard JavaScript/TypeScript IDE tools don't know about and so can't refactor, validate, or navigate.

These templates may look declarative because the look HTML-ish but they are not -- because of the embedded code that can call arbitrary functions in your application. The result is hard to debug and reason about. Where do you put a breakpoint in such a template? How do you abstract part of a template into a function? How do you add logging to such templates? How do you know what object is having its data accessed for templating languages like with Angular that do complex contextual lookups behind the scenes? How do you get code coverage reports? How do you get code completion? How do you get precise error reports? And so on. For more on why templates are a bad idea, see: https://blog.dantup.com/2014/08/you-have-ruined-html/

That is why I feel these sorts of template-based approaches will eventually be discarded as obsolete for writing single page applications as web programming continues to progress (in favor of generating UIs directly from code). HTML-ish templates feel familiar to people with experience building progressively enhanced web apps by sprinkling a bit of CSS and JavaScript on top of HTML generated from a server -- but for single-page apps that spend most of their time converting JSON from a server into HTML (or just doing stand-alone activities), a templating HTML-first approach make little sense. You just don't need extra templating machinery that you need to learn and maintain and that just gets in the way of development.

By contrast, consider the HyperScript API for generating HTML from JavaScript/TypeScript (as used in Mithril, Maquette, and optionally in Inferno and some other vdom libraries).

For example:

    h("div", 
        h("ul",
            h("li", "one"),
            h("li", "two"),
            h("li", "three"),
            someExtraListItems(),
            otherItems.map((item) => h("li", item.name))
        ),
        isListEditable ? 
            h("button", { onclick: editList }, "Edit extra list items") : 
            []
    )

If you use the HyperScript approach (especially with Tachyons.css or similar), you are just writing JavaScript/TypeScript/whatever and can leverage all of the language's features. JavaScript-first for modern SPAs!

You should try tsx (typescript jsx). It is 100% first class code: autocomplete of names and attributes, type safety of attributes, unlimited mixing of tsx and JavaScript, rename refactoring, navigate to definitions, etc.

It is similar to a function based approach, but has many advantages that reduce code and increase productivity.

Here is a page of examples from me React typescript setup repo:

https://github.com/toldsoftware/boilerplate-react-typescript...

> These templates may look declarative because the look HTML-ish but they are not

Yes! Precisely. How many of these "regular old HTML"s I've seen and even used. Each with their own looping constructs, their own if/then constructs. The benefit, honestly, was lost on me then and is still lost on me.

React is not perfect. JavaScript is horrible. But pretend "HTML" templates are so much worse for all the reasons you describe.

I still suspect there must be something to Vue, though. So many people like it. Many of them have tried React, so I'm sure it's not like they're all ignorant to the glory of JS-based rendering. I wonder what it is.

> Where do you put a breakpoint in such a template?

Just use chrome. It will show compiled template that look much like jsx.

Eh, Vue support the same thing too with render function. Under the hood, the template is compiled to a single render function too.

Reply on news.ycombinator.com