Series overview
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Foreword
I recently started working with Vue.js in a more d...
For further actions, you may consider blocking this person and/or reporting abuse
Sadly you're not just using ES6 modules, because you're also doing this:
ES6 modules can't load HTML files. This is an extension to ES6 modules. A custom extension created in Webpack's ecosystem but ultimately custom. Which means you might think you're just using JavaScript, but actually you're not.
The problem here is that Webpack could be a thing of the past in a couple of years and you'd end up with code that needs to be fixed before updating the project. I'm really not a fan of that.
I'd rather use .vue files, at least the intent is clear. Will you explain how to use them in a future chapter?
You are right. These imports are not fully ES6. That's why we needed to include the raw-loader. Since this is bundled by webpack you will not get the possibility of using the full functionality of ES6 modules (e.g. load when it is need) out of the box. Still it looks and feels like writing code for ES6 modules.
Some words about your argument Webpack could get a thing of the past in some years: It is the same with everything when we are talking about library driven development. Who knows whether Vue itself will get not maintained anymore? Then the whole code will get useless. There is never a certain guarantee that we can use the tools forever (especially in JS development).
It was not planned that I describe how to use .vue files since I personally do not work with them for certain reasons. But I will explain it in a later chapter and show you my opinion.
Thanks for your feedback.
Sure, Vue could be a goner too, but the same Webpack stains in JavaScript code could be seen in other frameworks. The main difference is that while Vue (or React or whatever) are the core of possibly long spanning projects, Webpack is just a bundling tool - a
devDependency. Something that should allow us to replace it entirely if we feel like it. So why are we adapting our core code to use a bundler, and not vice versa? Why are we locking ourselves into Webpack's ecosystem?If I take an AngularJS project from 2012, I could switch its bundling system from Grunt to Gulp or even Webpack without touching the application's source code. It's not the same if I import html, though.
That's why I'd use .vue files instead: it's a specification from Vue, not from Webpack. So there's
vue-loaderfor Webpack, but there's alsovueifyfor Browserify.Now I got your point. That is an issue that could come up at some point in the future. I agree to your argumentation but not completely that you should not use the Webpack ecosystem to write your code. I like writing code within that ecosystem and I would have no problem with adapting the code when my ecosystem changes.
But I really respect your arguments against using Webpack.
Thanks for that great sharing :)
Well, it's not even that, actually. Webpack is fine as long as I don't bind my code to it 🙃
Yeah I don't have a problem with that but of course some people would say it is a huge pain point. I think I found a setup with browserify. I will try it out within the next day and will give it an additional chapter.
That would be great!
Hi Moritz,
Your tutorial is nice and your explanations are very clear !
I have a few questions about some choices you have made for this tutorial :
buildandbuild:js) which are only aliases to thewebpacksimple command ? I know that you will change this later but for now you are going to use only one of those... :).vuefiles ? You have setted up Webpack and Babel but you loose some great features that provide.vuefiles like scoped style, template linter, etc.Thanks for sharing ! :)
Edit: some misspelling... Oops
Hi Sylvain,
thanks for your feedback. You have two very legitimate questions. Let me try to answer both.
index.htmlto the correct folder what should also be done in a build script even though it is not part of the usual Webpack compiling. Moreover I call thewebpackcommand from thepackage.jsonto avoid installing dependencies on a global level because that could lead to version conflicts when using multiple projects..vuefiles for multiple reasons. Since you are not the first one asking for Single File Components, I will write a chapter just about this and why I do not like working with them.I didn't thought about conflicts when installing global dependencies ! This is a good point ;)
It's very cool to have differents opinions :)
I look forward to read your next chapter !
Yup that is something that I really like as well within the dev.to community.
The next chapter is already published. :)
Very nice intro, thanks for starting this series. As an outsider to web development, it seems to me that the era of "javascript fatigue" is still not over. It takes an enormous amount of complexity (and redundancy) to set up a basic js project with npm and webpack. I understand that this complexity does not grow quickly with the size of the project, it's just that there is so much stuff going on that even a C++ project is easier to get started on.
I agree it sometimes feels like there is a little bit to much overhead currently. But still I like to configure such stuff even in a more complex way. And of course I really do love Web development.
Thank you for your feedback.