The Vue from here is .js wonderful

Once upon a time, a web designer's life was pretty simple. HTML, CSS and maybe (just maybe) a few JavaScript snippets to keep things interesting. These days, not so much.

The Vue from here is .js wonderful

Once upon a time, a web designer's life was pretty simple. HTML, CSS and maybe (just maybe) a few JavaScript snippets to keep things interesting. These days, not so much. Whereas you 'can' knock stuff together and compile a basic web page from HTML, CSS and a collection of JS snippets, it's really not going to stack up to much when compared to other websites and online applications now available on the net.

So .. just how far do you need to go if you're going to compete. I looked briefly at Angular a couple of years ago within the context of 'extending' what I was already doing, and came to the conclusion it was pointless. Too much messing around for what the current code pretty much already did. Indeed the same could be said for many of the features of Angular (and it's competitors) if you take those features in isolation or indeed out of context. To really see reason for the buzz, you need to start "all-in" and develop your site / application within one of the new frameworks and use all the features they provide. It's a different world!

After experimenting with Vue.js, within a couple of hours I was completely (and permanently) hooked. Although it 'will' work with other stuff (which was one of the initial attractions for me over React.js), it's best used from within the provided environment in the way that was intended. If you do this, all the dynamic stuff you used to fret over, that all becomes second nature.

Firstly, your entire application now exists within one page, i.e. your application becomes a SPA (Single Page Application). Essentially, instead of reloading a new page when the user clicks on a link, assuming the link is "local" to the site, the new page is loaded dynamically "into" the current page. What's the point? Well, firstly it's quicker as all your assets (CSS, JS etc) remain cached and secondly, you retain your global JS context, which means you get to keep your global variables as you transition between pages (and also websockets!), so you can actually write a persistent JavaScript application that survives page transitions.

This was enough to get me started, but my initial reaction was "yeah, but it's going to cause Google lots of indexing problems..", well, not if you do it right - which brings me back to using all the features provided  by the framework. You can (and historically I did) switch pages "manually" simply by having lots of parallel DIV's and simply hiding all but the one you want shown, then output each of your pages in a DIV. Works, but you have no "routing", i.e. the shown page isn't reflected in the address bar.

Enter the Vue Router! Inside your main HTML page you just need a tag to mark where you want the pages to appear. (router-view)

<template>
  <div id="app" style="height:100%">
    <transition name="fade" mode="out-in">
      <router-view name="main"/>        
    </transition>
  </div>
</template>

Then you need to implement each of your pages as a Vue "component" (which is relatively basic / straightforward), then all you need to do is implement a "router" section to specify which URL relates to which component, and linking to said URL shows the selected component wherever you left your "router-view" tag. Hey presto, you have full address bar / URL based routing and browser history, but all happening automatically within ONE physical web page .. so the router looks something link this .. and you can obviously add as many routes / pages you you need;

export default new Router({
  mode: 'history',
  routes: [
    { path: '/',
      components: { main: mainApp },

All very fancy, and stuff you could do "by hand", but when you add it to all the other killer features like "reactive variables" .. imagine you have a paged data table on the screen, typically this will be drawn 'from' a list structure. In Vue.js, if you "bind" this data-table to the source list, whenever you change an entry in the list, it's immediately reflected in the data-table. So .. if you bind all your display widgets back to data structures loaded dynamically over AJAX or Websocket type IO, all you ever have to do is accept IO updates into your internal data structures, and the screen displays and any data driven widgets will look after themselves. Fire and forget! Now add in the "shadow dom", or if you're an old games programmer "double buffering", you can accept screen updates at a "much" faster rate than your display can cope with, without locking up your machine. i.e. an automatic counter for display / update overrun, with the added benefit of much more efficient and faster screen updates all-round.

Sounds like fun, but looking back at the supplied framework, you also get access to things like Babel (google it, you'll like it!) sass, scoped css, webpack (don't look!) and command line options to serve the content up locally for testing, and to produce a "build" i.e. all the required assets stitched up and ready to be served up by a production web server.

So, if you're looking to produce a website that's going to "do" something, consider Vue.js as a cool framework for making you life (much) easier ..