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.

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.

https://vuejs.org/v2/guide/single-file-components.html

I'm in the completely opposite camp. Many small files are easier to maintain with large teams. The one caveat is the files need to be very well organized. I'm personally a fan of having a folder for each component with separate js/html/css/test files living side by side.

In general, mixing html/js/css in a single file feels really dirty to me, but that might just be PTSD from a past life where I did a bunch of work on PHP spaghetti code with no separation of concerns.

I agree. I am building a big angular 1 project right now and for every new component I make a new folder with three files - html template, sass, and javascript controller. It works the best in my opinion. Otherwise the files would just be way too big.

Even worse, I once worked in an environment where our web server was an Oracle database, serving snippets of pages from stored procedures on port 80.

Single file components are extremely common in Vue. You can also render templates with JavaScript (although from what i've seen, this is much more intuitive in React than Vue)

That doesn't solve the problem though -- you still have two sources of truth. Is this array processed in the template or the JS? Where does this crazy directive get called? How does the model get updated when you click some element? That mental back-and-forth becomes a huge pain in a big project. With JSX you never have to worry about it.

For the life of me I cannot shake the feeling that Vue is just a simpler Backbone/Marionette. React was life changing because it actually solved the problems I had as a professional I-do-this-every-day web developer. I can't feel that way about Vue.

Have you tried Vue? I had that impression too—that it's like Backbone/Marionette—but people have told me it's not. I don't think you mess with the DOM and I don't think you refer to elements except for the root, like in React.

I don't know where you formed your impression of what Vue is like, but what you're describing is really not anything like it.

This is my impression of templates as a tool. I dislike Vue for the same reasons I dislike Angular and Marionette.

Ok... I mean, JSX is templates too; it's just a different syntax. Vue supports JSX if you prefer that syntax.

I think you have a mistaken impression of Vue, it's much more similar to React than it is to Angular.

JSX is different though -- it's sugar around a 1:1 mapping to plain old JavaScript. There's no magic behind the scenes binding variables or interpreting stringly-typed code.

I wasn't aware you could use JSX with Vue. If you do, what benefits does Vue offer?

Vue simplifies a lot of the "data propagation" from what I've seen of React. I loved React's vdom and props, but just felt the syntax for props (e.g. `.setProp({name: val})` was excessive boiler plate. Vue simplifies that aspect with reactive props and data, its just more intuitive for me than React. One big improvement is the really nice system for `computed` and `watch` properties which reactively transform data. Your templates (jsx or the default html-directives, which I prefer) can rely on `computed` properties to transform from say an Dict to a list for say a list of `li` components. It gives a nice "raw input data -> reactive data transforms -> reactive html repr` flow.

"sources of truth" usually refers to data.

Having some designated separation of presentation and data is usually understood as a good thing.

I get that having them located in strongly separated locations increases workflow friction, but that isn't how Vue does things, and the rest of the problems you're talking about are present in any system where presentation and data have some kind of separation convention.

I'm also not convinced there where React is used to collapse the difference between the two it's actually solving problems rather than switching to a different set of problems, but then again I suppose every engineer has the right to pick which set of problems they prefer to wrestle with.

In a larger Vue application you would use a data store (ie Vuex). The only thing that can mutate the data are "mutation" methods in the data store. It is your single source of truth.

If you aren't using a data store, your parent component would solely be responsible for mutating data. If the child component needed to alter it, it would raise an event that the parent would listen to and make whatever modifications necessary.

I'm having a lot of trouble truthfully understanding your "mental back-and-forth" issue and I'm wondering if it's an inexperience with Vue issue. Give it a try... I'm willing to bet you'll love it.

My guess is that they started looking at Vue before v2.

Maybe using "source of truth" was bad phrasing, the question is about rendering data not the data itself. I am convinced templates are a fundamentally broken technology. In React there's only one place things happen: in the JSX. This is not true for Vue -- you have at least two discrete objects (the template and the view) communicating back and forth.

Have you seen Vue's single file components?

It's a (single file), which would look something like (idk how to format code on h/n lol):

<template> <ul> <li v-for="message in messages">{{ message }}</li> </ul> </template>

I realize this is a completely trivial example, but is this what you're getting at? Everything related to that component is in a single place. The template itself handles any UI specific logic: conditionally showing an element, looping, binding an event.

Any real logic is going to be handled from the component itself.

That said, Vue actually supports using a render function as opposed to using a template. You can even use JSX if you want (though I certainly wouldn't consider JSX a first class citizen in Vue).

But do you see the inter-dependencies between the script and the template? The template is assuming that it's provided a variable named messages and that it's an array of ready-to-display strings. And this information is stringly typed -- will your editor complain if you fail to define messages? Can I use Typescript to ensure that each message is what I expect? Sure, it's easy enough for simple examples but I've seen it fall apart quickly for large projects with multiple developers.

I'm not seeing the issue here.

This kind of system is extremely common on the backend---Python's Django and Ruby on Rails, to name a few frameworks follow the practice of templates being given data and simply acting upon it.

Since these are dynamically typed languages, there's no IDE typing support in the template.

There's just testing.

As someone who uses Django regularly, I can say there's a huge swatch of territory between "small examples" and "large projects".

That territory can easily cover teams of 19, and multimillion dollar projects.

Right, it's a common technology and it's always been a pain. With React everything is well-defined and typesafe (either through PropTypes, Typescript, or Flow) and the IDE support is fantastic.

That's my whole contention -- Vue is just a better iteration of the same old painful experience. React actually solves the problems I have.

the templates rendered. There is a singular state, because data flow is one directional. mutating properties is an anti-pattern in vue.

Vue has one source of truth: the data stored in each component. You bind elements in the template to that data and they get automatically re-rendered when it changes, and you bind events in the template to methods (or just ad-hoc things like @click="toggleVar = !toggleVar" for a boolean) that update that data.

This includes child components, which trigger events that you bind in the parent component.

> @click="toggleVar = !toggleVar"

Oh boy. Another reason why I don't like templates -- you invariably end up with magical incantations like this. Working with JSX has given me an incredible distaste for templating languages.

Somewhat magical.

All bound expressions in Vue are javascript expressions. Names are typically bound on "this", which is the component instance. So the above expression is equivalent to

    this.toggleVar = !this.toggleVar.

Not entirely true -- I know there's at least special processing for filters: https://vuejs.org/v2/guide/syntax.html#Filters

Separating CSS always seemed stupid to me, I was so happy when it finally became "best practice" to have inline styles within isolated components. HTML is the markup and as far as I'm concerned the styling is part of that markup.

I don't understand how anyone ever thought CSS's style inheritance was a good idea. I don't mind HTML and even JS these days but CSS really needs to be sent straight back to hell where it came from.

One word: re-usability.

the components should be reusable, not the styles on them.

Besides global font settings CSS nowadays is mostly used for positioning and isn't reusable.

For components, bundling the CSS makes sense. For other use cases external CSS resources with inheritance are very beneficial.See for example Scalable and Modular Architecture for CSS or any modern CSS framework for lots of examples.

reusing css is a great idea for websites, react and Vue are most commonly used for web app where the atomic unit of reusability is the component.

Yes, I agree on separation being overrated. It was probably pushed to promote teams working on UI/UX and programmers with overlap but code being on its own. In practice, developers usually modify the css from how it is done from designers as in practice, things seem to change.

You still get reuse but use it like a default export if styles are used in more than one place.

I like Vue because it puts style, markup, and template into the same file (single file components), but separates them in a way that's incredibly intuitive. I also love how simple Vue feels. Like it doesn't feel like it's doing any sort of dark magic under the hood, it just makes sense in a way that you can wrap your head around the entire thing in an afternoon, and that's refreshing.

Also the docs are like really really good. The Vue guide is a better experience than the official Angular tutorials (don't even get me started on the non-typescript angular documentation). They're a huge strong point for this project, especially considering how young it is.

My experience is that the HTML CSS experts can more easily understand Vue components. So going back and forth between dev and UX is simpler with Vue.