EJS via Hapi for the frontend markup, Vue.js (if needed) for creating components

[taoeffect]

See http://hapijs.com/tutorials/views + new edits to #6.

Hapi's vision plugin homepage has great examples of how to set this up and what templating languages are supported.

Tasks

• Figure out whether (and how) we should make the site both CDN-friendly (i.e. keeping it deliverable as purely static files) and designer-friendly. On-the-fly rendering of the front-end markup using EJS via Hapi is not a good long-term solution. Maybe the right thing to do is to render/compile the EJS templates to static .html files like jekyll does it?
• Remove any .vue files that are unneeded.

[taoeffect]

EJS is supported by Hapi (along with a bunch of other templating languages, but ejs seems to be the most relevant/useful, like a JS version of PHP).

• http://ejs.co
• https://scotch.io/tutorials/use-ejs-to-template-your-node-application

[taoeffect]

What Vue.js is good for (and not)

• Reducing HTML markup and making collaboration easier. To open a facebook-style chatbox at the bottom of the window, you just insert <chatbox param1="foo" param2="bar"></chatbox>, etc.
• Synchronizing data between the view (the widget) and the model (the JS object). I.e. two-way data bindings. Rule of thumb: if data-binding is unnecessary then there's no need for Vue.js to be involved.
• Creating logic-heavy widgets for widget-heavy "apps" like Slack, etc.
• Serving "web 2.0" (2.5?) static websites. I.e. you put your entire modern website in an .html file, have it call an API, and serve it to people over a CDN. Thanks to client-side routers the URL will magically change on "page visit". 👈 This might be the most relevant part for us as it works well with the future move to Ethereum.

It's not convenient for much else. It is especially not good for designers who are used to plain-old markup. Apparently, being friendly toward designers is one of its strong points, but that's compared to other frameworks like React.js / Angular / Ember. Nor is it useful for creating relatively "small" widgets like input fields or buttons.

Many websites, including many "large scale" websites, have little need for this stuff. Even twitter and github don't do the single-page app thing!

What EJS is good for

EJS is basically PHP except JavaScript.

So it is good for that style of programming, and it is therefore much more friendly and usable for designers (and programmers!).

Vue.js can be used to prevent the EJS from overcrowding the markup.

Some code not needed

Sorry @wemeetagain for not figuring this out earlier, but I think you'll agree that it doesn't make sense to replace one line of markup (the <button> tag) with a 26 line .vue file. Suggesting that we do that was my silly mistake. OTOH such mistakes are useful for figuring out what Vue.js is and isn't really useful for.

Many of the .vue files could be replaced by .ejs files. OTOH with .ejs it may be the case that unless we do a bunch of pagename/index.html files the .ejs will have to be rendered on the fly by Hapi (making the frontend not serve-able by CDNs and possibly causing issues with future Ethereum integration).

If we want to serve static content without a folder hierarchy then the vue-router is needed, otherwise not.

If we don't go the single-page static site route then the only thing in #6 that might be worth using Vue.js for is this widget:

Undecided for now

I've re-opened issue #6 for now as I'm not sure .ejs is the right way to go.

Servers are a bad thing, and we do want to move away from them. Moving toward them is probably not what we want to be doing if we can help it.

It may be the case that if we stick with Vue.js and its .vue files, even if it takes folks a bit of getting used to, we might end up being able to more easily hot-swap out the backend for Ethereum later on.

In thinking about this it may be worth it for me to revisit my Webpack research and see if, for example, it has a way to bundle .ejs files—it turns out there is, along with a million other template languages. Modern web development is a trip.

Webpack loaders of note

• https://github.com/akim-mcmath/ejs-html-loader
• https://github.com/webpack/html-loader
• https://github.com/avaly/dust-loader
• https://github.com/cusspvz/ect-loader

TODO: see if browserify has can do this as well.

Preliminary searching suggests it does (see ejsify), but has less community support for this, and browserify itself might not be as well designed in this regard as Webpack. Also, ejsify uses an older version of EJS (1.x, not 2.x, although it looks very simple to fork it and update it).

So... maybe one avenue to explore (without breaking/rewriting a bunch of the stuff we have now), is to add a gulpfile that uses webpack and an .ejs loader and see how close we can get to having a nice "traditional modern" setup.