DDG search drop in powered by ddg.patdryburgh.com
tldr; There isn’t much much vue-with-jspm support outside of the systemjs-plugin-vue, so I made a thing that compiles jspm templates from html files, and JSPM+VUE is really working for me. Also, Vue.JS is the view library people should recommend to beginners. Not React.
It looks like jspm isn’t winning the mindshare of new JS developers these days. Though I’m not sure I can blame anyone for not having mindshare left to give, with the constant onslaught of new libraries, frameworks, doodads and what-have-yous that pop up from day to day. It seems like people these days are mostly switching to webpack. Once upon a time, I looked at webpack’s home page (1.0 or maybe even earlier I think) and couldn’t for the life of me tell you what it was, or what it was for. Since then, the have completely overhauled their documentation (from 2.x), and how to use the tool has become much clearer. Well either way, the
If you’re curious about JSPM, check out this video (youtube). If that excites you, give JSPM a try. If it doesn’t, check out webpack. I’m very biased towards JSPM, but that’s increasingly seeming to be just me, and I may try webpack in the very close future, so I can speak from a (somewhat) more balanced standpoint.
From here on in the article, I will often use systemjs and jspm interchangeably, but note that they are indeed different:
jspm is the packaging framework and javascript package manager/frontend tool that enables my build process
systemjs is a module loader, used by afore-mentioned jspm
Check out their website. I’m a huge fan of KnockoutJS, and love that it isn’t much more than declarative bindings. I often recommend that people learn the vast world of JS by going from vanilla js -> jquery + js -> knockout + js ->
I also hold a weird amount of love for elegant, small things – in the past I’ve looked at (and seriously considered) mithril, rivets, and some other similar “micro” frameworks and all of them have mostly made me think “I should do a project in this someday”. However, Vue.JS was the most recent one that made me think that AND reminded me of a thing I liked already (knockout), so here we are.
There’s actually already a plugin for using SystemJS and VUE together, called systemjs-plugin-vue. I could have used this plugin, but chose not too, because I’m still not super-duper onboard with putting all the different types of files into one .vue file.
For those unfamiliar (skip this paragraph if you’re already familiar…), you can write vue components as one file (with a .vue extension, normally), which contains all the HTML, CSS, and JS to make the component do it’s job. Pre-processing build tools (like webpack and jspm, will do the work if creating the required sources when you go to compile/minify. I think the reason grouping the markup/styling/functionality (HTML/CSS/JS) in this way is gaining ground is because people are starting to view the component as the concern, not the markup/styling/functionality. People normally cite “separation of concerns” for the reason we (should) keep HTML, CSS, and JS file separate, but as anyone who’s worked with JS can tell you, things get real messy and hard to distinguish when you start doing data-binding, and changing CSS from JS, and trying to target dynamically created JS elements from CSS. Lots of ink has been spilled (probably?) on the topic, so I’m not going to discuss it much further here, except to state that I haven’t yet felt the benefits/drawbacks of using one .vue file per component. It’s probably the case that I’m missing out, but I’m just not ready to cross that line just yet.
So for me, the existing approach didn’t quite work… It also didn’t seem to be presently maintained (but that of course doesn’t mean it doesn’t work). I was out to translate just the HTML files to templates.
So as with most things in JSPM, it’s pretty easy to add new libraries/codebases/dependencies/future-problems to JSPM:
jspm install vue.js --lock
As anyone who has ever managed dependencies for a long time, always make sure to lock (--lock) your dependencies, so shit doesn’t break randomly, and all upgrades are a conscious effort (which is a good thing, despite how it sounds). Don’t try to build a house on shifting sands.
The problem (ok not really a problem) here is the the default version of Vue.JS that is imported is the runtime version. Vue.JS has different standalone and runtime builds. The main difference being that the standalone build contains the template compiler, so you can just import and go. The runtime build, however, does not, and it expects your templates to be compiled by something else beforehand.
ASIDE This is actualy one of the things I LOVE about Vue.JS and thinks it really gets right. Beginners these days are rushing to learn React and Flux and all these new fangled frameworks, but just getting started with react requires so much previous knowledge, and so many contortions with tooling that I imagine only marketing dollars and hype train schedules are what is causing people to recommend React to beginners. Vue is easy enough (if you remember Angluar 1, it was similarly simple) to just include one script, write how they tell you to write, and get something up on the page. No need to transpile, no need to run a server, no need to study crazy syntax, or adopt a whole new mindset.
There are a few ways to solve this problem:
config.js) that makes an exception and loads the standalone version of the buildCheck out:
Number 1 seemed like the easiest option, and was at the time (though finding out how to do it was an excersize in google-fu, since jspm’s documentation is actually kinda bad/sparse/hard-to-find).
The override looking like:
...
packages: {
"vue": {
"main": {
// Load vue w/ template engine (standalone) in non-production contexts
// (i.e. just serving the page during dev)
"~production": "./dist/vue.common.js"
}
}
}
...
Benefits:
Turns out though, there are problems with this approach:
Bundling for production is broken, because HTML files still come in as HTML.
Do you really want to compile templates in production???
After doing the wrong thing for a while and realizing that I needed to compile the darn templates things, through a bit of trial and error, I got a systemjs plugin working that would do the translation for me, which was fun in and of itself.
Check out the documentation for instructions! Please feel free to send me an email if you find anything that doesn’t work or is too difficult to understand.
Basically, the plugin does nothing but call the compiler under the covers (but does this for you at build time, not runtime). I added some work for the consumer unfortunately (mostly because of my choice to use gitlab instead of github), but all in all the solution works, and I’m super happy with it.
One of the requirements for my current project is that it also needs to work in slightly more stringent CSP environments (which honestly should probably be a requirement for lots of websites these days), and I’m glad to say that this requirement is satisfied under this solution (which is a huge relief).
Looking back on earlier in the week, I think my life has been vastly improved. I’m starting to seriously grow a love for Vue.JS, becuase it just gets out of my way, and I have automated (as per usual) my build with jspm bundle-sfx, make and entr, and while it’s not the snappiest reloading process in the world it’s pretty easy and obvious.
Most of my time now is spent building my own sandcastles (components) in Vue.JS, and I feel very productive. I love a lot of the decisions Vue.JS makes, and the lines it draws in the sand, and also how fast it loads up. Also, supported by jspm, bringing in dependencies is a breeze and building is ezpz.
Vue.JS is the view library people should recommend to beginners. Not React.
-https://gist.github.com/dherman/7568080 -https://github.com/ModuleLoader/es-module-loader/blob/v0.17.0/docs/loader-extensions.md -https://www.npmjs.com/package/vue-template-compiler -https://github.com/systemjs/builder/issues/22 (saw example of proper translate function on this site… I’m 100% a newbie to under-the-covers transpiling/module-loading interfaces)