loading...
Cover image for Buildless Vuejs

Buildless Vuejs

kyleparisi profile image Kyle Parisi ・2 min read

The Slide

This isn't a, "this is how you should do it", post. This more like how you could do it and works well for something like an internal dashboard. I started with this strategy because I figured it would help my coworkers be able to jump right into the source code. The only requirement to run locally or in production is an HTTP server. This makes deployment very easy. Copy files to the server.

1x Magnification

These 2 libraries make it all work. A side benefit to this approach is you get configurable code splitting.

.
├── [page-name]
│   └── index.html
├── css
│   └── app.css
├── favicon.ico
├── index.html
└── js
    ├── [page-name].js (each page gets a js file)
    ├── bootstrap.js (configure requirejs & global functions)
    ├── components
    │   ├── [page-name]
    │   │   └── page-component.vue
    │   └── global-component.js
    ├── library(s).js
    └── pages
        └── [page-name]
            ├── page1.vue
            └── page2.vue

Every index.html file gets 3 things to work.

  1. require.js - library which will load required files dynamically
  2. bootstrap.js - configurations for require.js and global utilities
  3. [page-name].js - page specific requires, initial state, Vue component mounting, and anything else you need for the page

10x Magnification

// [page-name].js
require([
  "Vue"
  // library(s).js,

  // components/global-component.js,

  // components/[page-name]/page-component.js,
], function(Vue/*, library(s)*/) {
  new Vue({
    el: '#app',
    data: window.data
  });
});

In the above snippet, require([<stuff>, is where the "code splitting" happens. Of course everything in that array will be a network request. Another very nice benefit is that you don't have to register your vue components! The last benefit I found is that the .vue files are easily readable in devtools.

100x Magnification

In my setup I went the lazy route and use a global state object (window.data) to control the vuejs data. This approach can be tricky to understand when js will observe a change. But if I'd like to mock a state, it is pretty pleasant just modifying that object in the console.

For reference:

Buildless-vuejs

Pretty basic way to develop a vuejs app.

Running local

Only requirement is an http server. Here is how I do it:

# in ~/.bash_profile
function server() {
    local port="${1:-8000}"
    open "http://localhost:${port}/" && python -m SimpleHTTPServer "$port"
}
server

Then open http://localhost:8000.

Running remote

Upload to CDN or AWS S3 hosting bucket.

Posted on by:

kyleparisi profile

Kyle Parisi

@kyleparisi

Working on https://buildapart.io, https://fluxion.app in my spare time.

Discussion

pic
Editor guide
 

@kyleparisi

As far as I can tell vue cli 3 does a pretty good job at producing a clean and lean/optimized build that can be just pushed to production.

Is there a real use case for buildless-vue ? I am not being judgemental. I am not an expert on Vue.js and hence the question.

 

of course!! you can found several use cases, for instance, you can have your website in WordPress or something similar, and then use Buildless VueJS to create a better Register Form with fancy features like a Wizard Assistance. (I just did it in a client's website)

I usually have to work with WordPress plugins, so I really love Buildless VueJS, it allow me integrate VueJS only on specific zones and put it on a simple plugin in a very easy way.

 

Fair question. It's a matter of preference and needs. I suspected that my coworker hated anything cli related so I tried to make it as easy as possible for them. If the project were public facing, I probably would have used a build step (as all of our public projects do) regardless of my coworkers opinions. If I have to start another internal project, I probably will repeat this pattern because it's easy on the mind and spirit.

 

Neat. I am using ES modules instead of requirejs and that works decently well. I found 3 downsides to this approach:

  • adding new components etc is a few lines of manual work (acceptable)
  • CSS cannot be scoped without using lit-element components (acceptable)
  • npm packages that are not ESM ready need a simple conversion (mildly inconvenient)

For non-production, or light hobby websites, I find this perfectly acceptable, and I really prefer being able to edit html/js without heavy building that takes hundreds of megabytes of disk space. This way I can also use my custom Node.js server without having to wrestle with Nuxt or similar, but of course, to each their own.

 

Is there a reason it needs a server?

:: Nevermind I get it now ::