5 ms·
I wouldn't mind a build tool if it didn't require a ton of JavaScript files (looking at you Babel.js). Recently I had to start a new project and decided to use
by guessmyname 8y ago
I wouldn't mind a build tool if it didn't require a ton of JavaScript files (looking at you Babel.js).
Recently I had to start a new project and decided to use Go for the back-end and Vue.js for the front-end, but I was concerned about all the tooling that I would need to integrate just to power the front-end side of the website. More so considering that my employer's business has nothing to do with web development so all this overhead would be unjustifiable. I spent several days reading and trying to understand what every tool included by Babel.js was doing until I gave up after the +20th module. It felt like a nightmare to see the gigantic dependency tree inside the "node_modules" folder.
I felt relieved when I found that Vue.js Components don't need to be compiled [1].
I also found this article interesting [2] with information on different approaches.
This is what I ended up with (my own design):
/project/
├── docker-compose.yml
├── Dockerfile
├── README.md
├── backend
│ ├── about.go
│ ├── app.go
│ ├── home.go
│ ├── main.go
└── frontend
├── public
│ ├── app.min.js
│ ├── bootstrap.min.css
│ ├── favicon.ico
│ ├── about.min.js
│ ├── styles.min.css
│ ├── vue.min.js
│ └── vue-res.min.js
└── views
├── base.html.tpl
├── home.html.tpl
└── about.html.tpl
Where "app.min.js" contains the basic Vue.js options like this:
var Application = function() {};
Application.prototype.el = '#app';
Application.prototype.delimiters = ['${', '}'];
Application.prototype.data = {};
Application.prototype.created = function() {};
Application.prototype.methods = {};
And the sub-sequent pages, like "About", load a JavaScript file with this:
Vue.component('about', {
template: '#about',
data: function() {
return {…};
},
methods: {…}
});
[1] https://vuejs.org/v2/guide/components.html https://vuejs.org/v2/guide/components.html
[2] https://medium.com/js-dojo/7-ways-to-define-a-component-template-in-vuejs-c04e0c72900d https://medium.com/js-dojo/7-ways-to-define-a-component-temp...
- philliphaydon 8y agoYou should check out the vue cli.
- guessmyname 8y agoI already tried it, but it also depends on Babel.js [1]. Here is the dependency tree upon installation [2] 144M in total. I just created a fresh project with it, and the directory is now 134M and I just selected Eslint + Prettier for linting and formatting. I don't want to know how big the project would be if I were to choose the other available options (Router, Vuex, Babel, etc). This week I spent 1-2 hours designing a lightweight project structure to use Vue.js components without the build tool, it worked pretty well and it does what I need it to do, which is simply DOM binding, Ajax requests, and minimal templating because the rest is already handled by the back-end in Go. [1] https://github.com/vuejs/vue-cli/blob/3193b0d/package.json#L44-L61 https://github.com/vuejs/vue-cli/blob/3193b0d/package.json#L... [2] https://pastebin.com/raw/x3kJ91xP https://pastebin.com/raw/x3kJ91xP
- brazzledazzle 8y agoBut you don’t have to commit or deploy the dependencies right? It’s just that size for the build isn’t it?
- guessmyname 8y ago> But you don’t have to commit or deploy the dependencies right? Yes, I have, otherwise I will impose Node.js + NPM as a dependency for my co-workers who — again — are not web developers, they just want to quickly modify one or two things and deploy without my involvement, so I have to build something as standalone as possible, this means (in this and other projects) that I have to commit the whole "node_modules" folder with the rest of the files. And if anyone thinks this is a weird requirement, I can tell you that last year I did some contractor work in four web agencies in San Francisco, and they all had a policy of "commit all the dependencies" because they wanted to "lock" the files to a specific version. They used to lock the dependencies using the "package.json" file, but after all the recent fiascos with NPM and their registry, they stopping relying on the constant download of these files during every deployment, something that we were considering even before the problems with NPM because downloading +200M of files for every execution of the test suite in the CI server was posing a significant cost for not reason. If NPM and their registry were more stable, I would just put everything in the "package.json" file and ignore the +100M of code in the dependency tree, but unfortunately, the Node.js is voting for a different philosophy that has been biting them for several years now, they still haven't learnt the lesson.