NOTE: Snowpack is obsolete at this point, which makes this post, um, less useful.

If you've been working with JavaScript for a while, you'll know that things have changed from the day when the code end users saw in production was the same code you hacked with your hands. Though I might prefer the days of Vanilla.js, it's gotten nearly impossible to hold a job without knowing how to transpile code.

If you're still on the Vanilla side of the chart, transpiling JavaScript code is when you take a recent version of JavaScript, or, more properly, ECMAscript, and essentially compile it into an older, more compatible version. Transpiling is a "source-to-source" compilation, from one programming language (or version) to another, so to speak.

Maybe you want to use "farts" or "fat arrow functions" where you can exchange this code...

function (x) {
    return x + 1;
}

... with the shorthand...

(x) => x + 1;

Or maybe you want to use shorthand property definitions, which turns this:

var o = {
  a: a,
  b: b,
  c: c
};

... into...

let o = {a, b, c};

Or maybe you just want to use let and const instead of being limited to var.

Or, even better, maybe you want to use TypeScript, which is a great idea, bringing along the bug-squashing safety of strong-typing without sacrificing the abilty to go full dynamic when you need it.

You get the point. JavaScript keeps adding features (as does TypeScript), but older browsers won't magically support all of them. You need to turn your cutting-edge code into something [insert lowest common denominator based on your browser requirements] can run.

That's transpilation. Even if you're not going to transpile something, you need to be aware of how it works so that you can pick the right tools for your projects.

I'll probably make a video at some point, but I would like to quickly get down the steps I think I'd take when moving from a vanilla, es5-compatible JavaScript codebase.

Notes, warnings, and caveats

Why target your transpilation for es5? es5 is the latest version IE supports, as a benchmark. es6 requires more modern browsers. Luckily requirements to support IE seem to be going the way of the dinosaur.

That said, I haven't (yet) run into a situation where a transpiler balks at targeting es5. That is, why not include IE if transpiling to something newer buys me nothing? Everything I can do in es6 I can, thanks to some insane transpiler shimming, do in es5.

Warning: This is not going to be a howto, I'm afraid, but a command recipe for those who already kind of know what they're doing.

It's also not a really nuanced recipe. For instance, when you run npm init, you probably don't want to use the -y flag and should instead pick a specific license. For some reason, using the -y flag means you'll pick "ISC", "a permissive free software license published by the Internet Software Consortium" instead of "UNLICENSED" for your project, and "UNLICENSED" is what the docs say to use for copyrighted code.

So use at your own risk.

And to be overly clear, this is for browser development, not server-side node dev, natch.

Recipe to move es5 codebase to modern JS (with snowpack, webpack, & babel)

Here's the 10,000' view:

• Use Snowpack to transpile your TypeScript into modern JavaScript.
• Use webpack to fold your modern JavaScript into a single file.
• Use babel to transpile your modern JavaScript into es5 compliant code.
• (Use some node code, called by your build process, to link to that single es5 page from your starting html.)

Here are the specific steps:

1. Ensure you've got node installed globally
   • The node install will include installing npm.
   • If you know you will need to swap to different versions of node for different projects (as in you know you have some older ones that won't work in the latest version of node), google nvm ("node version manager").
     • You should, however, know if this applies to you.
     • (If this is your first transpilation project, different versions of node don't apply. Yet.)
2. Navigate to an es5 code base.
3. In the home directory of the codebase, run npm i -y
   • See caveat about licensing, above.
4. Now run npm install -D snowpack
   • Snowpack is a development tool only imo.
   • It is not a conventional transpiler so much as a package manager.
   • snowpack's goal is to allow you to develop in a browser that supports whatever version of JavaScript you want to program in (vs. deploy) quickly.
   • It does, however, support compiling TypeScript on the fly. That and the more deliberate management of libraries are the biggest gains snowpack buys for me.
5. "Port" your existing es5 to TypeScript by changing all JavaScript files' extensions from .js to .ts
   • TypeScript is a superscript of JavaScript, so that's all you have to do.
   • On macOS, you can use this command:
     • find . -iname "*.js" -exec bash -c 'mv "$0" "${0%\.js}.ts"' {} \;
   • I've got a PowerShell script to do this somewhere, but until I find it, try these answers.
6. Add a snowpack.config.js file to the root directory.
   • I'm glossing over a lot here. See below the receipe for an example snowpack config.
7. Add "start": "snowpack dev" to your package.json's scripts collection
8. Install webpack as a "dev dependency" for your project with npm install -D webpack-cli
   • Example webpack config is below.
9. Add this build command to your package.json's scripts collection:
   • "build": "snowpack build && webpack"
   • Here, snowpack is going to compile your TypeScript into JavaScript.
   • Then webpack is going to take the compiled JavaScript and pack it into a single index.js file.
   • Hang in there. We're getting to the transpilation.
10. npm install --save-dev babel-loader @babel/core
    • We're using Babel to transpile the code.
    • Up until this point, we needed a modern browser that understood our untranspiled code.
    • Not a big deal as you develop, but potentially a very big deal before releasing.
11. Add this command to package.json:
    • "launderIndexHtml": "node ./buildscripts/build.js"
12. Add build.js to your project's home directory using the template, below.
13. Edit package.json's build command to include this new build command:
    • "build": "snowpack build && webpack && npm run launderIndexHtml",
    • Why didn't we just start with that for our build command? Idk. This recipe is too tutorial-ly, I suppose.

Suggested initial snowpack.config.js

/*global module */
module.exports = {
    mount: {
        public: { url: "/", static: true },
        app: "/",
    },
    buildOptions: {
        out: "./dist",
    },
    devOptions: {
        open: "brave",
    },
};

Why does this open Brave when in devOptions.open? Well, I like to have a browser dedicated to testing and Canary wasn't an option snowpack supported at the time of this writing, strangely enough.

Suggested initial webpack.config.js

/*eslint-disable */
const path = require("path");
module.exports = {
    entry: "./dist/index.js",
    output: {
        filename: "./index.js",
        path: path.resolve(__dirname, "dist"),
    },
    module: {
        rules: [
            {
                test: /\.(js)$/,
                exclude: /node_modules/,
                use: ["babel-loader"],
            },
        ],
    },
    resolve: {
        extensions: ["*", ".js"],
    },
};

Custom build.js script

/* eslint-env node */
// We need to do two things after we've compiled our TypeScript with snowpack,
// transpiled into es5 with babel, and bundled & minified with webpack:
// 1. Update index.html to load our minified es5 file as-is, not as a module.
// 2. Get rid of the source we bundled into our webpack output.
var fs = require("fs");
var indexLoc = "./dist/index.html";
fs.readFile(indexLoc, "utf8", function (err, data) {
    if (err) {
        return console.log(err);
    }
    var result = data.replace('script type="module" src="./index.js"', 'script src="./index.js"');
    // var result = data.replace(/script type="module" src="./index.js"/, 'script src="./index.js"');
    fs.writeFile(indexLoc, result, "utf8", function (errWrite) {
        if (errWrite) {
            return console.log(errWrite);
        }
    });
});
function getDirectories(path) {
    return fs.readdirSync(path).filter(function (file) {
        return fs.statSync(path + "/" + file).isDirectory();
    });
}
var foldersToKeep = ["lib", "css", "assets"];
getDirectories("./dist").forEach((x) => {
    if (foldersToKeep.indexOf(x) === -1) {
        fs.rmdirSync("./dist/" + x, { recursive: true });
    }
});

Labels: howto, javascript, transpilation, typescript

This is part of a series explaining how to use VueJS to create a transplation-free client-side templating architecture. I'm not claiming this is The Best Way to create a UI, but it's a good thought experiment for minimizing ceremony.

• Part 1: VueJS introduction -- Progressive, observables, loops, & ifs
• Part 2: Components, Templates Types, and SPAs (unedited)
• Part 3: Using Render Functions & HTML Files (to come)

NOTE: I haven't reread/edited this one yet, I'm afraid. Bbl.

In Part 1, we had all the tools we absolutely required to make a single page app (SPA) with VueJS, but the HTML was a mess. Worse, if it got any more complicated and the different "views" shared any UI, we could tell it'd quickly stop being DRY.

The solution to this problem is to employ reusable components. Here's a quick visual from the "Intro to VueJS" video from Vue's home page.

Concentrate mostly on the stuff in the middle... we might want to use that Product Image component in a few different places, for instance. With components, we can define it once, and then reuse all over the place.

Now there are a number of different ways to create components, but, honestly, only a few that really make sense in a practical work environment. The first that we're going to review -- and the one most sites, including Vue's own documentaions start with -- really doesn't make great sense: inline text. But let's do it anyway for kicks. The reason will make more sense later...

Let's take that "cats" markup from Part 1 and componentize it.

Old markup:

<!-- ==== FROM HERE ==== -->
<div v-if="activeUi === 'cats'">
    <h3>Cats</h3>
    <ul>
        <li v-for="cat in cats">
            {{ cat }}
        </li>
    </ul>
</div>
<!-- ===== TO HERE ===== -->

<div v-else-if="activeUi === 'dogs'">
    <h3>Dogs</h3>
    <ol>
        <li v-for="dog in dogs">
            {{ dog }}
        </li>
    </ol>
</div>

<div v-else>
    <h3>Neither dogs nor cats</h3>
    <ul>
        <li v-for="x in others">
            {{x.name}}, a {{x.type}}

            <!-- And note that we can embed ad infinitum, natch -->
            <ul v-if="x.type === 'rooster'">
                <li>"That's a joke, I say, that's a joke son!"</li>
            </ul>
        </li>
    </ul>
</div>

Vue's component model is pretty conventional, and awfully familiar if you've used React. Here, there's no real business logic. We just need to get that the cats data into the component and then loop over it. And we do that with props, which is just a fancy way of saying properties that we bind in the component's declaration in our HTML.

Here the above cats-specific markup as a component. I've got it in a new file marked components.js so that it's not mixing with my core business logic, but you can drop it anywhere you want, as long as it's executed before your main Vue app instantiation. Recall that I've got my main Vue call in a document.addEventListener("DOMContentLoaded", function() {...}); wrapper, so it's not going until the rest of the page is read and rendered.

/*global Vue, window */
(function () {
    "use strict";

    Vue.component("cats", {
        props: ['store'],
        template: '<div><h3>Cats</h3><ul><li v-for="cat in store">{{ cat }}</li></ul></div>'
    });
}());

And here's how the HTML changes:

NOTE: Check the : before store, which tells us to bind the object represented by "cats" rather than treating it as a literal string.

<!-- ==== FROM HERE ==== -->
<cats v-if="activeUi === 'cats'" :store="cats"></cats>
<!-- ===== TO HERE ===== -->

<div v-else-if="activeUi === 'dogs'">
    <h3>Dogs</h3>

    <!-- ... and so forth... ->

That's certainly a lot cleaner, right? If we componentize it all, making similar dogs and others components, we exchange all the markup from the first code dump, above, to this:

<cats v-if="activeUi === 'cats'" :store="cats"></cats>
<dogs v-else-if="activeUi === 'dogs'" :store="dogs"></dogs>
<others v-else :store="others"></others>

A few things to note:

1. Our HTML looks great. No clutter. If we want to see what happens with cats, we know to look at that specific component.
2. The template string can include Vue markup. You see {{ cat }} there. So that's cool -- we can get as nesty as we want.
3. The template string is okayish for the small markup we have, but boy, that'd be messy for lots of markup. It's not even easy to read as it stands!

I bet we can do better, right? Let's see if there's a way to keep the HTML in its own file, where we're not worried about newlines or surrounding values in single quotes, and escaping single quotes in the template, and...

Pros and Cons for VueJS Template Types

There's a decent intro to the different ways you can create templates for components in Vue here on medium from Anthony Gore. Let's run through them and list some pros and cons.

1. String
2. Template literal
3. X-Templates
4. Inline
5. Render functions
6. JSX
7. Single page components

1. String

The first is what we just did. template is literally a string. As Gore says, "I think we can all agree that templates in a string are quite incomprehensible. This method doesn’t have much going for it other than the wide browser support." It's really not scalable, and heaven help anyone debugging or editing a large HTML value within quotes.

2. Template Literals

The second is to use es6's "template literals". This is a new syntax which allows us to define multiline strings using backticks instead of quotes to delimit strings. That's great, and would improve our cats component definition quite a bit...

Vue.component("cats", {
    props: ['store'],
    template: `
<div>
    <h3>Cats</h3>
    <ul>
        <li v-for="cat in store">{{ cat }}</li>
    </ul>
</div>`});

That's a big step up, but it's not IE happy at all. For me, at least, that's still an issue. There's also spotty escape sequence support, so it's not really HTML ready. And strangely, they don't have any compatibility right now (20180411) for Safari on iOS. ??

3. X-Templates (script tags)

X-Templates are when you use the trick that you can drop HTML into a script tag with an id and then link to it from your component definition. This allows you to embed all your components' html into a single file if you wanted, which is an improvement.

<script type="text/x-template" id="dogs-template">
    <div>
        <h3>Dogs</h3>
        <ol>
            <li v-for="dog in store">
                {{ dog }}
            </li>
        </ol>
    </div>
</script>

That, of course, can go anywhere you want in your html, or in a script include. This isn't an end of the world, and is actually how we used to do templates in KnockoutJS. The only thing I hate is that it feels a little kludge and that it's harder to get your editor set up to highlight the HTML code as HTML inside of script tags.

The component is very clean, however.

Vue.component("dogs", {
    props: ['store'],
    template: "#dogs-template"
});

4. Inline templates :^P<######

Inline templates are a horrible idea, and I can't even find a place on Vue's website that claims it's supported. I'm not saying it's not supported. I'm saying it's a horrible idea. Inline templating is when you put the template between the component's tags in your "parent" markup. Here's Gore's example:

<my-checkbox inline-template>
  <div class="checkbox-wrapper" @click="check">
    <div :class="{ checkbox: true, checked: checked }"></div>
    <div class="title"></div>
  </div>
</my-checkbox>

OMGWTFBBQ! The whole purpose of components is that you can then reuse them with minimal overhead. Now I get it -- perhaps there are times when you want different markup for each use of the component. Maybe. But if something's ever duplicated, you're stuck cut and pasting markup, and you've lost your DRYness. Yuck.

5. Render Function: Spoilers

I'm going to come back to render functions. *wink wink wink*

6. JSX & 7. Single file components.

The final two involve transpilation. You can use JSX in Vue if you want, just like you're back in React-land. Insert Kerriganian "WHY?!!?!"

The second is actually what you probably came to Vue for in the first place, single file components. I really do like the idea of single file components. They contain the template, javascript, and, get this, scoped CSS all in the same file. It sounds wonderful.

Here's why it's not, from vuejs.org:

For Users New to Module Build Systems in JavaScript

With .vue components, we’re entering the realm of advanced JavaScript applications. That means learning to use a few additional tools if you haven’t already:

• Node Package Manager (NPM): Read the Getting Started guide through section 10: Uninstalling global packages.

• Modern JavaScript with ES2015/16: Read through Babel’s Learn ES2015 guide. You don’t have to memorize every feature right now, but keep this page as a reference you can come back to.

After you’ve taken a day to dive into these resources, we recommend checking out the webpack template. Follow the instructions and you should have a Vue project with .vuecomponents, ES2015, and hot-reloading in no time!

To learn more about Webpack itself, check out their official docs and Webpack Academy. In Webpack, each file can be transformed by a “loader” before being included in the bundle, and Vue offers the vue-loader plugin to translate single-file (.vue) components.

NOTE: Either of these involve the gateway drug to that horrible cesspool of build scripts and maintenance that I'm trying to avoid for you. It's also a, well, JavaScript builds are not exactly a broken window; they're more like a stained glass window. Once you have a single piece of stained glass, someone on the team is going to add eighteen more build steps^H^H^H^H^H^H pieces of stained glass, and suddenly you have a priceless stained glass window that looks like a snowflake, if you get my [wait for it...] drift.

Again, this is how everyone does JavaScript development these days, but I'd warn you against it. At the very least, let's see how bad things get if we avoid transpiliation, if just as a thought experiment. The series is called "Templating without Transpilation", after all.

Tune in next time in Part 3, when we finally get where we're going, using, you guessed, it, render functions, and have a solid architecture that allows templating without transpilation.

Labels: howto, javascript, transpilation, VueJS

This is part of a series explaining how to use VueJS to create a transplation-free client-side templating architecture. I'm not claiming this is The Best Way to create a UI, but it's a good thought experiment for minimizing ceremony.

• Part 1: VueJS introduction -- Progressive, observables, loops, & ifs
• Part 2: Components, Templates Types, and SPAs (unedited)
• Part 3: Using Render Functions & HTML Files (to come)

I heard about VueJS a while back on from Shawn Wildermuth guesting on Yet Another Podcast, and figured I'd take a look. The most interesting thing about it was its claim to be a "progressive framework"...

From vuejs.org:

Vue (pronounced /vjuː/, like view) is a progressive framework for building user interfaces. Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is easy to pick up and integrate with other libraries or existing projects. On the other hand, Vue is also perfectly capable of powering sophisticated Single-Page Applications when used in combination with modern tooling and supporting libraries.

Incremental adoption, you say? As in, I could use its templating without any other libraries? RLY? I mean, Vue bills itself to be a pretty mature lib. Heck, you can go full-bore, Babel and JSX with VueJS if you want to. That marks a sort of max progression. Can we find a similarly minimally progressive stack?

Once burned...

Last year, I spent most of my time working on a system that used React, JSX, and MobX using Babel for transpilation. It wasn't a horrible client-side stack, but I've never wasted so much time on build systems since I was new to ant. We updated and debugged with each new release of anything of those three, and it drove me crazy with what Shawn Wildermuth calls the "ceremony" of coding -- all the magic incantations and rituals you have to go through and maintain before working code comes out.

Using transpilation and riding the bleeding edge instead of writing deployable code means everything you do costs you -- let's say -- an extra 10%, and, in the wrong hands, more. Do you really get that time back with transpilation?

Just because everyone else is putting together complex JavaScript build processes (and they are. Projects that don't include "the dev who maintains the build" are becoming few and far between, and that dev is always front and center on interview calls pretending their role is absolutely critical to a project's success), do we have to go full Cranberries? (pro tip: see album title, young'uns)

I don't think so. I'm not against transpilation, if it's well managed. But if I can use a library that doesn't require transpilation, but can still give me a good templating system, I'm curious. Just for fun, let's see if VueJS can keep us transpilation-free.

How progressive is VueJS, exactly?

NOTE: If you already know Vue, stay with me. Skim the balance of this so you know where I'm coming from, and then stop at the end, where I start talking about what's missing. Then tune in next time, for Part 2, where I fill in what's missing & seal the deal.

Let's take the minimal VueJS setup as described in their introductory guide, where we assume zero libraries other than Vue are present.

What's below is the minimal Vue setup from their guide, with just enough changed so that we...

1. Have something that'll work in a live example
2. Include a form element to test our binding
3. Have a button to access our data programmatically (standing in for a call back to the server)
4. Wait until the DOM has loaded before initializing to begin templating
   • If we were using true Vue templates, we wouldn't have to do this. More on that in Part 2.
5. Some gymnastics to pass JSLint.

Excuse the last. It's an unshakeable addiction.

^{(That said, you should use JSLint too. ;^D)}

/*global Vue, window */
document.addEventListener("DOMContentLoaded", function() {
    "use strict";
    window.app = new Vue({
        el: '#app',
        data: {
            message: 'Hello Vue!'
        },
        methods: {
            report: function () {
                // Note that it's app.property, not app.data.property
                console.log(JSON.stringify(window.app.message, null, "    "));
            }
        }
    });
});

And the HTML needed to match is super simple.

<html>
    <head>
        <title>Look how simple</title>

        <script src="../vue.js"></script>
        <script src="./app.js"></script>
    </head>
    <body>
        <div id="app">
            {{ message }}<br />

            <input
                type="text"
                v-model="message"
            /><br />

            <button
                type="button"
                v-on:click.prevent="report"
            >Add new</button>
        </div>
    </body>
</html>

And poof! We've got an interactive, VueJS-templated web page.

That's... great. Right?

Vue does observables right

Actually, it is great, kinda. data is just a datastore. Vue wraps it in observable overhead, so in many ways, it reminds me, at this level, of KnockoutJS. It's advantage? That we're not wasting time dealing with any of that overhead ourselves, in code or our mental model. Knockout had this horrible convention where you had to call a function to get a "raw" observable, which often threw people for loops).

Vue beats out KnockoutJS easily here. You can very simply put in properties to serve as hooks in your data object to hang all of your datastores, and when you set them, they iterate through your object models and make everything an observable too. If you set message, above, to some giant json model, all of that model would be observable. And each property would be accessible in plain old javascript object ("POJsO") notation.

/*global Vue, window */
document.addEventListener("DOMContentLoaded", function() {
    "use strict";
    window.app = new Vue({
        el: '#app',
        data: {
            payload: {
                b: { c: 2 }
            }
        },
        methods: {
            report: function () {
                // Note that it's app.property, not app.data.property
                console.log(JSON.stringify(payload.b.c, null, "    "));
            }
        }
    });

    // Pretend some event caused this.
    window.app.payload = {
        a: 1,
        b: {
            a:"a",
            b:"b",
            c:"c"
        },
        c: 2
    };
});

And then a quick change to our html...

<div id="app">
    {{ payload.b.c }}
</div>

That, I like. That's how you should do observables. It's the same mental model as a plain ole JavaScript object. There's no "oops, that's an observable! Remember to treat it like a function!" overhead. It's simply magic.

Okay, okay, I haven't looked, but it's almost certainly some getter and setter overhead, which works like magic here. That's why it's important to note that window.app.data is inaccessible. What we don't want to do is blow up our observable chain.

How not to observe...

NOTE: The follow-on from that is that you can't do this:

window.app.payload.d = "spam" and expect spam to be observable. You have to set something that's already an observable, or the extra setter logic won't fire. That just makes sense.

But you can pick up the observable train wherever you want...

NOTE: You really shouldn't be updating your data object's object model for the most part, however. That's a code smell, imo. You'll be getting nice large JSON payloads from your server, and you might have some navigation and convenience objects for managing views, but that's about it. If you make changes to data, that should be going back to the server. And if you're changing the data model on the client, that's probably a business rule that should've been handled on your server-side, not the client-side, where your interest should be almost exclusively presenting views.

Keep your interests separated.

Moving towards an SPA

There are really only two more things you need to know to get pretty close to making minimalistic single page apps (SPAs) with VueJS: conditionals and loops.

Loops with v-for

Loops are easy. If you have an array of objects in your datastore, you can loop through them easily with v-for, repeating the markup within that marked node as many times as you have objects.

So if you had data = { stooges: ["Larry", "Moe", "Curly", "Shemp"] }, your markup would be something similar to:

<div id="app">
    <ul>
        <li v-for="stooge in stooges">
            {{ stooge }}
        </li>
    </ul>
</div>

Easy. And if your stooges were objects instead of strings, that's done just like you'd expect, thanks to the POJsO setup Vue supports.

data = { 
    stooges: [
        { name: "Larry", desc: "the curly-headed one." },
        { name: "Moe",   desc: "the relatively smart one." },
        { name: "Curly", desc: "the bald one. See what they did there, with Larry having the curly hair?" },
        { name: "Shemp", desc: "the one nobody knew in the 70s, but somehow everyone did starting around 1990." }
    ]
};

And change the markup to match:

<div id="app">
    <ul>
        <li v-for="stooge in stooges">
            {{ stooge.name }} is {{ stooge.desc }}
        </li>
    </ul>
</div>

Conditionals with v-if

Now let's look at conditionals. If you only want something to be rendered when some condition is true, you plant that portion of your markup in a conditional.

 <html>
    <head>
        <title>Animal types and examples</title>

        <script src="../vue.js"></script>
        <script src="./app.js"></script>
    </head>
    <body>
        <div id="app">

            Display all animals of type: <input
                type="text"
                v-model="activeUi"
            /><br />

            <div v-if="activeUi === 'cats'">
                <h3>Cats</h3>
                <ul>
                    <li v-for="cat in cats">
                        {{ cat }}
                    </li>
                </ul>
            </div>

            <div v-else-if="activeUi === 'dogs'">
                <h3>Dogs</h3>
                <ol>
                    <li v-for="dog in dogs">
                        {{ dog }}
                    </li>
                </ol>
            </div>

            <div v-else>
                <h3>Neither dogs nor cats</h3>
                <ul>
                    <li v-for="x in others">
                        {{x.name}}, a {{x.type}}

                        <!-- And note that we can embed ad infinitum, natch -->
                        <ul v-if="x.type === 'rooster'">
                            <li>"That's a joke, I say, that's a joke son!"</li>
                        </ul>
                    </li>
                </ul>
            </div>

        </div>
    </body>
</html>

You're half-way there. To an SPA, that is.

If you use conditionals with reckless aplomb, you could force your way to a complete SPA. No, really, you're done. You could have every portion of your app in some div marked with the proper conditional, and have everything appear iff it's supposed to.

There're just two problems. At some point, it's going to be very difficult to keep this DRY. You will eventually want to use the same markup (HTML) and business logic (JavaScript) in two places that are each embedded deep within some other portion of HTML.

And, well, that's HTML is already a mess. It's sprawling and difficult to grok quickly, which means it'll be difficult to maintain.

Wouldn't it be nice if we could cut that previous html down with some custom components, like this?

 <html>
    <head>
        <title>Animal types and examples</title>

        <script src="../vue.js"></script>
        <script src="../components.js"></script>
        <script src="./app.js"></script>
    </head>
    <body>
        <div id="app">

            Display all animals of type: <input
                type="text"
                v-model="activeUi"
            /><br />

            <cats store="cats" v-if="activeUi === 'cats'" />
            <dogs store="dogs" v-else-if="activeUi === 'dogs'" />
            <other store="others" v-else />

        </div>
    </body>
</html>

... and to do it without transpilation?

We can. And we will. In Part 2.

Labels: howto, javascript, transpilation, VueJS

Oh google. Your raw source makes me something something.

Why is this in the page itself? Why do you need so much source to display your page? What ever happened to humans writing html code?

I know I sound like an assembly programmer in the land of OO, but it still makes me sad. ;^)

Labels: cyborg, Google, human, javascript, sad, transpilation

JavaScript transpilation is a neat trick, but in practice you may seem to simply trade one multifaceted, shifting platform -- what works crossbrowser -- for another -- here, a set of constantly changing hipster libraries.

There are simple solutions to the shifting , each with one major flaw:

• Target a "lowest common denominator" or "limiting reagent" browser (ie, IE[x]) with "native" JavaScript.
  • This stinks because even IE11's tools are much worse than Chrome's DevTools.
  • Yet if you don't live in your "worst" browser, you're going to miss issues. No, you are. Every time.
• Pick one set of transpiled technologies & practices, and, within reason, stop.
  • You're still going to have to test in browsers
  • You'll still be responsible for debugging third-party code.
  • You'll disappoint your hipster programmers.

Interpreted incorrectly, transpilation gives the impression that you're developing for an environment like a server: a controlled, homogenous system. You're not. It's not node. And I've yet to see a practical advantage beyond very specific, situated uses -- JSX compilation for React, for example -- provided transpilation. It's all still very familiar zeroes and ones.

Labels: crockford, javascript, node, transpilation