Vue CLI 3: A Game Changer for Front End Development?(vuejsdevelopers.com)
vuejsdevelopers.com
Vue CLI 3: A Game Changer for Front End Development?
https://vuejsdevelopers.com/2018/03/26/vue-cli-3/
65 comments
A game changer would a Delphi like RAD tooling IDE, fully based on WebComponents, with backend integration and an eco-system of companies selling UI components, not yet another CLI tool.
Have you ever tried Adobes Flex Builder?
That was good.
Only drawback .. it was based on flash and got killed by Adobe.
That was good.
Only drawback .. it was based on flash and got killed by Adobe.
Flash (and Flex as collater damage) got killed by Apple.
But yeah, I agree even now, nothing compares to Adobe Flex on the developer productivity aspect
Flex was better than anything in use for web front end to this day, imo. Aside from requiring Flash, but iirc targeting HTML/js as an output format was on the roadmap.
We have Apache Royale https://royale.apache.org/ for that. Compile your Flex MXML + ActionScript to HTML + JS and more.
Yet, as a user, there's nothing I dreaded more than the all-Flash application. Binary blob, no integration with the OS, and accessibility was an afterthought. Basic things like highlighting text to copy, tabbing between controls, Enter to submit, would not work. We should take care to not view the history of Flash through rose-tinted glasses.
I know some people think that. Personally, I hated both the programming model and the interfaces that resulted from it. It was much worse than the competitive HTML/CSS interfaces of the era to actually use in most cases.
Flash got replaced by Animate CC and they still sell Dreamweaver, but it not quite the same.
CxJS is designed having desktop-like, data-intensive applications in mind and offers a full set of UI components and charts out of the box.
https://cxjs.io
Disclaimer: I'm the author.
Disclaimer: I'm the author.
Looks interesting, good luck with CxJS .
Why no one create it yet?
Maybe because Web development is dominated by FOSS tooling and as such very few companies are willing to invest the money to pull it off, as very few would be willing to pay for such tools.
Then there is the whole Web foundation that makes it pretty hard to actually use layout designers and components in a way that can work across frameworks and browsers.
Only now with CSS Grid and WebComponents is the Web finally catching up with what was already possible in desktop framework engines of the late 90's.
There are a few startups working on these ideas, but again, the main question is how they will manage to stay alive.
Then there is the whole Web foundation that makes it pretty hard to actually use layout designers and components in a way that can work across frameworks and browsers.
Only now with CSS Grid and WebComponents is the Web finally catching up with what was already possible in desktop framework engines of the late 90's.
There are a few startups working on these ideas, but again, the main question is how they will manage to stay alive.
[deleted]
I believe the new version of create-react-app (2.0) will have a bit more flexibility.
See: Roadmap for [email protected] https://github.com/facebook/create-react-app/issues/3815
See: Roadmap for [email protected] https://github.com/facebook/create-react-app/issues/3815
I really wish they allowed for a TINY bit of configuration. I understand their need for batteries include, but having to eject to add `target: 'electron-renderer'` is pretty whack.
I wrote a thing that overwrites CRA's own webpack configs with one that loads said configs and passes them to a function you control. There's probably a package that does this, or a better way of doing it, but here's what I have: https://gist.github.com/mikew/97e2be1d428aae8460a33dfbee0ca8...
I wrote a thing that overwrites CRA's own webpack configs with one that loads said configs and passes them to a function you control. There's probably a package that does this, or a better way of doing it, but here's what I have: https://gist.github.com/mikew/97e2be1d428aae8460a33dfbee0ca8...
It seems like such an obvious oversight. All they had to do was allow me to define a hook function that would let me to arbitrarily modify the Webpack configs before start/build. Every time I ever ejected it's because I had to add a one or two line change to the Webpack configs.
There's a more standardized way to overwrite parts of a CRA config - see https://github.com/timarney/react-app-rewired .
Yo dawg, I heard you like configuration so I put Babel config in your Webpack config in your Vue3-CLI config so you can configure while you configure.
In all seriousness, I'm not seeing how yet another build system with a plugin architecture changes anything for frontend development. I'm also not seeing what this extra layer offers over using Webpack directly.
In all seriousness, I'm not seeing how yet another build system with a plugin architecture changes anything for frontend development. I'm also not seeing what this extra layer offers over using Webpack directly.
People should learn their tools and systems, but I think it is very important to make it as easy as possible for people to get started with your framework, language or system. Nothing kills interest as quickly as not even being able to get started on something; to get people up and running is probably the single most important thing if you want your project to get any significant amount of users.
I struggled a few months to get a decent working structure for multiple environments working when I had to do a largish front-end project (out of my comfort zone and not really a big fan of Javascript), so I think tools like vue-cli are a good idea: set up a sensible base structure, and work on from there if you have both experience and time. Showing an idiomatic architectural layout might also help people to move more quickly from basic "Hello, World!" examples to larger, non-trivial applications, which in my experience is a problem for most programming languages.
I struggled a few months to get a decent working structure for multiple environments working when I had to do a largish front-end project (out of my comfort zone and not really a big fan of Javascript), so I think tools like vue-cli are a good idea: set up a sensible base structure, and work on from there if you have both experience and time. Showing an idiomatic architectural layout might also help people to move more quickly from basic "Hello, World!" examples to larger, non-trivial applications, which in my experience is a problem for most programming languages.
Welcome to DJS (Department of JavaScript), please take a number, stand in the line to your right, and migrate your code to the next coolest framework.
Phtt. Migrate? That's crazy talk. Rewrite!
On a more serious note: that's why I exited frontend dev 15 years ago and never looked back. I now do hard-ass C and C++, and once I write something it runs for many years with no changes, and dependencies are often a decade old or more.
On a more serious note: that's why I exited frontend dev 15 years ago and never looked back. I now do hard-ass C and C++, and once I write something it runs for many years with no changes, and dependencies are often a decade old or more.
Yes. A lot depends on how well transparent this dynamic construction of the webpack config is and whether you can really customize it or not. I've spent a bit of time having to fiddle with very specific options in my VueJS webpack config and as fiddly as that is, the ability to directly edit them at least makes it possible to do just about anything I need. Trying to debug why a config you can't see is not working, being unable to take simple examples from the manual or Stack overflow and directly put them into my config ... sounds like it could end in a nightmare.
But, jury's out, so far the Vue developers have managed to make good decisions about most of these things, so they've earned at least a little benefit of the doubt.
But, jury's out, so far the Vue developers have managed to make good decisions about most of these things, so they've earned at least a little benefit of the doubt.
I came here to post something similar. The re-re-re-invention of the wheel is getting tiring. I'm having a hard time as seeing this as progress.
Pssht, don't tell them :D
How does this compare to Ember CLI?
https://ember-cli.com
https://ember-cli.com
Am I the only one who thinks Webpack is really not _that_ bad? I spent a day or two learning it back in 2015 and it's served me well ever since.
Not to mention tools like this end up increasing the net complexity, not reducing it. I recently looked at forking create-react-app to get it working in a custom environment, and wow. What a mess.
Not to mention tools like this end up increasing the net complexity, not reducing it. I recently looked at forking create-react-app to get it working in a custom environment, and wow. What a mess.
I think the main issue is the inconsistency in tutorials out there and the different ways of setting up webpack and using all the loaders. For example you can use loaders and specify them in config, or directly in an import/require statement.
If that's the case I think FB could've served the community better by just publishing recommended Webpack configs than cargo-culting everyone into CRA.
As a backend person slowly breaking into frontend dev and using Vue.js, this is exactly the problem.
I started using vue-cli for my latest projects and it handles webpack for me. So far I haven't had a reason to touch webpack directly.
I started using vue-cli for my latest projects and it handles webpack for me. So far I haven't had a reason to touch webpack directly.
I generally just use it w/ laravel defaults and use laravel on backend... so far never had an issue... Sometimes I need to edit some stuff in the webpack config for edge cases, but still never had much problems.
I think it depends on the use case. I've found Webpack unintuitive, heavy and complex but I can see how flexible and expressive it would be for people who need to do more than I need to.
Agree, never had any problem. People just can’t be bothered to learn
The point of create-react-app is to get up and running quickly. When you start wanting to customize things it doesn't really make much sense to use it at that point. That's why it's a mess.
I tend to agree, tbh. I would prefer these tools to focus on making webpack examples and making themselves easy to use in webpack.
I hope that we can get away from the plethora of little CLIs at some point.
I hope that we can get away from the plethora of little CLIs at some point.
Not needing to compile Vue.js is what got me started with it.
Looking forward to pure ES6 module version of Vue.js as a standard build for download from vuejs.org/npm. There's a test build (or something) from Nov. 2017, but it's not advertised, and it's an older version.
But it would mean no CLI/build/config needed at all to implement Vue in more modern environments.
But any improvements in the ecosystem is better for everyone.
Looking forward to pure ES6 module version of Vue.js as a standard build for download from vuejs.org/npm. There's a test build (or something) from Nov. 2017, but it's not advertised, and it's an older version.
But it would mean no CLI/build/config needed at all to implement Vue in more modern environments.
But any improvements in the ecosystem is better for everyone.
You should check out lit-html+LitElement.
It's standards Web Components from the get-go - you don't write to a non-standard API and then compile it out like with Vue, you just use the standard connectedCallback(), disconnectedCallback(), etc
lit-html is standard JS, with all the flexibility of a non-standard syntax extension like JSX, but without a compiler. Templates are expressions, can be passed to higher-order functions, and use JavaScript for control-flow.
It's all ES modules, published to npm as ES modules, and loadable directly from CDNs like unpkg.com into all modern browsers.
No CLI or custom tools needed, but also works with all the tools our there.
Edit, link: https://github.com/Polymer/lit-element
It's standards Web Components from the get-go - you don't write to a non-standard API and then compile it out like with Vue, you just use the standard connectedCallback(), disconnectedCallback(), etc
lit-html is standard JS, with all the flexibility of a non-standard syntax extension like JSX, but without a compiler. Templates are expressions, can be passed to higher-order functions, and use JavaScript for control-flow.
It's all ES modules, published to npm as ES modules, and loadable directly from CDNs like unpkg.com into all modern browsers.
No CLI or custom tools needed, but also works with all the tools our there.
Edit, link: https://github.com/Polymer/lit-element
I don't trust anything Google builds anymore, they've thrown so many projects under the bus that I'm not willing to invest in anything they build.
Unless I am really misunderstanding the connection of Polymer and lit-html... But also JSX gives me an icky feeling, I'd rather use standards compliant code everywhere. (while I contradict this statement with my v-bind: stuff everywhere, lol)
Plus, I got up and running with Vue.js on a major project in a day, and had reproduced a major jquery/ssr app in a week. I don't have much motivation to change at this point.
Unless Vue.js esm build never materializes, but that is a ways off to be concerned about now.
Thanks for the suggestions, I will take a look at lit-html again when I get a break.
Unless I am really misunderstanding the connection of Polymer and lit-html... But also JSX gives me an icky feeling, I'd rather use standards compliant code everywhere. (while I contradict this statement with my v-bind: stuff everywhere, lol)
Plus, I got up and running with Vue.js on a major project in a day, and had reproduced a major jquery/ssr app in a week. I don't have much motivation to change at this point.
Unless Vue.js esm build never materializes, but that is a ways off to be concerned about now.
Thanks for the suggestions, I will take a look at lit-html again when I get a break.
| I don't trust anything Google builds anymore, they've thrown so many projects under the bus that I'm not willing to invest in anything they build.
Google's a huge company that makes a huge number of things. Of course you're going to hear about canceled projects, but there are far more that aren't canceled. But trust what you will, I can't really argue for or against that.
| But also JSX gives me an icky feeling, I'd rather use standards compliant code everywhere
lit-html is standard JavaScript. It uses tagged template literals for markup rather than non-standard syntax. But because template are expressions, they're structurally very similar to JSX expressions, and there's basically a 1-1 relationship between JSX forms and lit-html. So if you like the power and flexibility of JSX, but not the non-standard syntax.
I only suggested LitElement because of your desire for something like Vue but in pure ES6 modules and without a compiler. Since Vue is heavily inspired by Web Components, and LitElement meets your other requirements, I thought you might find it interesting.
Google's a huge company that makes a huge number of things. Of course you're going to hear about canceled projects, but there are far more that aren't canceled. But trust what you will, I can't really argue for or against that.
| But also JSX gives me an icky feeling, I'd rather use standards compliant code everywhere
lit-html is standard JavaScript. It uses tagged template literals for markup rather than non-standard syntax. But because template are expressions, they're structurally very similar to JSX expressions, and there's basically a 1-1 relationship between JSX forms and lit-html. So if you like the power and flexibility of JSX, but not the non-standard syntax.
I only suggested LitElement because of your desire for something like Vue but in pure ES6 modules and without a compiler. Since Vue is heavily inspired by Web Components, and LitElement meets your other requirements, I thought you might find it interesting.
>I only suggested LitElement because of your desire for something like Vue but in pure ES6 modules and without a compiler.
Which I appreciate, thanks. I have looked into it, but it was so long ago I had forgotten about it. And to be frank, it hasn't gotten a lot of attention online.
That being said, I will wait a while to see if Vue.js comes around with an ESM build (I guess I could make one myself, but that seems to brittle). And if not, then I will have motivation to look into another library/framework.
Which I appreciate, thanks. I have looked into it, but it was so long ago I had forgotten about it. And to be frank, it hasn't gotten a lot of attention online.
That being said, I will wait a while to see if Vue.js comes around with an ESM build (I guess I could make one myself, but that seems to brittle). And if not, then I will have motivation to look into another library/framework.
> I don't trust anything Google builds anymore, they've thrown so many projects under the bus that I'm not willing to invest in anything they build.
Google will terminate free consumer products that don't work out, but my experience is that they will provide multi-year deprecation periods on things that developers or businesses rely on. For example, Angular 1 only went into maintenance mode last month, and will be supported until 2021.
Google will terminate free consumer products that don't work out, but my experience is that they will provide multi-year deprecation periods on things that developers or businesses rely on. For example, Angular 1 only went into maintenance mode last month, and will be supported until 2021.
[deleted]
Yup, that's how they got me hooked. After I was in, I understood the advantages of making bundles.
Strange thing is, this also works with React.
https://github.com/kay-is/react-from-zero
https://github.com/kay-is/react-from-zero
React (to me) has the same problem Angular has, a nasty stench of a corporate overlord that will throw everyone under the bus for it's own benefit. I know it's "opensource", but many opensource projects are messed up/abandoned by big corps for the latest and greatest ideas that suit them better.
I know that Vue.js could be abandoned too, but for some reason I am not as concerned about it. (personal foible I suppose)
I know that Vue.js could be abandoned too, but for some reason I am not as concerned about it. (personal foible I suppose)
Yes, I understand this.
It's a curse and a blessing.
It's a curse and a blessing.
I think it absolutely can be. Ember CLI and its addon exosystem is probably one of my favorite parts about Ember. It's great to see other front-end frameworks adopting similar patterns.
Finally other projects start to grow up a little bit to Ember.js, I still feel the most matured and powerful is Ember. Not hyped, because it is just works out of the box. Incredible. And it is already with us for years. ;)
For me the biggest game changer with vue-cli 3 is the inbuilt multi page support (not sure if it was present before). Rarely have I encountered any apps with a single page and this used to require all sorts of hacks before. But now it is as simple as adding a 'pages' entry in vue.config.js
"You may be relieved when you install your first Vue CLI 3 project and see there is no webpack.config.js in the project root. This is because most project configuration for Vue CLI 3 is abstracted into plugins and is merged into the base configuration at runtime."
Well, I guess have fun untangling that knot whenever there's a problem with Webpack! We all know how easy and fun the last Webpack major version upgrade was to all the things out there designed to reduce the amount of interaction with it when bootstrapping a project.
Just freaking learn Webpack, dude. I agree that it sucks, but not everything about your job needs to be fun.
Well, I guess have fun untangling that knot whenever there's a problem with Webpack! We all know how easy and fun the last Webpack major version upgrade was to all the things out there designed to reduce the amount of interaction with it when bootstrapping a project.
Just freaking learn Webpack, dude. I agree that it sucks, but not everything about your job needs to be fun.
Yeah, that made me laugh. Is it really a relief to have a config file you can't see instead of one you can?
Given `vue inspect` or even a `console.log(config)` inside the `configureWebpack` function in vue.config.js, it's very much a config file you can see.
Fair enough -- it's not like it's completely opaque. But when I start a project and see there is no webpack.config.js in the project root, I feel the opposite of relief.
For example, if there isn't a config file, it's usually because there are more than one. Or, even worse, the config is dynamically generated. A build process like that is much harder for me to fully understand than one with a simple webpack.config.js.
However, this may be biased, as it's coming from the perspective of someone who already "knows Webpack".
For example, if there isn't a config file, it's usually because there are more than one. Or, even worse, the config is dynamically generated. A build process like that is much harder for me to fully understand than one with a simple webpack.config.js.
However, this may be biased, as it's coming from the perspective of someone who already "knows Webpack".
Am I the only one that dislikes webpack? It's a lot slower than just good ol' browserify, when using watchify.
Even if you precompile libs
Even if you precompile libs
Reasons I instantly loved Vue when I came across it:
- Single file include,
- Included in-browser template compiler if you wanted it (plus the option to write view functions manually)
- Comprehensive Documentation that you could read through in a hour
- Reasonable embrace of HTML, CSS, and JS as separate tools. For example, most of the reactivity system is managed in JS, but the integration with HTML components is excellent -- nothing crazy like passing all your variables through a single `data` attribute on a <div>.
Vue seems to be working hard to build a moat of complexity around itself. I think it all started with the introduction of .vue files. I personally don't understand the need to put 3 different languages in the same file. Vue CLI is another step in the same direction of adding complexity. It looks like simplicity because "oh it's so easy for new people to get started", but if this keeps going, you're going to get tons of people who don't learn the basics/don't understand how the underlying tools work/can't fix problems in their own codebase because they didn't write the first 20% of it.
I still love Vue but I'm very very skeptical that this complexity they're adding isn't going to snowball, and eventually vue-cli will be the only supported way of creating vue apps, with some of the features that keep Vue simple being removed because they "prevent" progress.
Also, Vue CLI is not a game changer. Frontend frameworks all seem to have their own CLIs now, which is baffling in-and-of itself on the face of it.
- Single file include,
- Included in-browser template compiler if you wanted it (plus the option to write view functions manually)
- Comprehensive Documentation that you could read through in a hour
- Reasonable embrace of HTML, CSS, and JS as separate tools. For example, most of the reactivity system is managed in JS, but the integration with HTML components is excellent -- nothing crazy like passing all your variables through a single `data` attribute on a <div>.
Vue seems to be working hard to build a moat of complexity around itself. I think it all started with the introduction of .vue files. I personally don't understand the need to put 3 different languages in the same file. Vue CLI is another step in the same direction of adding complexity. It looks like simplicity because "oh it's so easy for new people to get started", but if this keeps going, you're going to get tons of people who don't learn the basics/don't understand how the underlying tools work/can't fix problems in their own codebase because they didn't write the first 20% of it.
I still love Vue but I'm very very skeptical that this complexity they're adding isn't going to snowball, and eventually vue-cli will be the only supported way of creating vue apps, with some of the features that keep Vue simple being removed because they "prevent" progress.
Also, Vue CLI is not a game changer. Frontend frameworks all seem to have their own CLIs now, which is baffling in-and-of itself on the face of it.
Mithril[0] has had those three points since the beginning.
Updates to their documentation will soon reference Parcel instead of Webpack, but neither are required. Just include the file in your html and the reactivity (and routing!) are included.
The reason I like it is because you have to understand the core concepts. But once you do, you can easily build on them to get what you need. And it remains fast even if you don’t do things perfectly idiomatically. If that makes sense... So it’s probably best for small teams that want to be very fast and effective.
[0]: https://mithril.js.org
Updates to their documentation will soon reference Parcel instead of Webpack, but neither are required. Just include the file in your html and the reactivity (and routing!) are included.
The reason I like it is because you have to understand the core concepts. But once you do, you can easily build on them to get what you need. And it remains fast even if you don’t do things perfectly idiomatically. If that makes sense... So it’s probably best for small teams that want to be very fast and effective.
[0]: https://mithril.js.org
Mithril is awesome! I really like it, it's one of the only micro frameworks that I feel is really underrated right now (I also took a look at rivets, and few others). I've actually really been feeling mithril! I avoided mentioning it to seem like I was trying to funnel people to another framework.
I like mithril because it's even simpler, and it has a few more concepts built in that are almost always necessary (ajax, etc), and the reactivity system is almost ridiculously simple -- if you don't fire an event stuff won't happen.
I think what mithril lacks is the adoption, or even better some sort of centralized repository of components that people who are fans of mithril can use. That, and an integration with Nativescript, so it can get "mithril-native" for free...
I like mithril because it's even simpler, and it has a few more concepts built in that are almost always necessary (ajax, etc), and the reactivity system is almost ridiculously simple -- if you don't fire an event stuff won't happen.
I think what mithril lacks is the adoption, or even better some sort of centralized repository of components that people who are fans of mithril can use. That, and an integration with Nativescript, so it can get "mithril-native" for free...
I also didn't like SFC (mainly because of lack of control and performance issues) and made a small wrapper around the reference template compiler (https://github.com/wearespindle/fuet and https://github.com/wearespindle/gulp-fuet), which makes it easy to keep buildsteps for component js, template markup and styling separated.
That's awesome! Yeah, I ended up wrapping the reference template compiler[0] for JSPM[1] which I use and love.
[0]: https://gitlab.com/mrman/systemjs-plugin-vue-template-compil...
[1]: https://jspm.io/
[0]: https://gitlab.com/mrman/systemjs-plugin-vue-template-compil...
[1]: https://jspm.io/
Don't even know why since once it's run and the project is setup, it mostly stays out of the way, and I've learned to put all configuration in package.json.
Hmm, maybe that's why.