
Vue CLI 3: A Game Changer for Front End Development? - evo_9
https://vuejsdevelopers.com/2018/03/26/vue-cli-3/
======
pjmlp
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.

~~~
hutzlibu
Have you ever tried Adobes Flex Builder?

That was good.

Only drawback .. it was based on flash and got killed by Adobe.

~~~
brandonmenc
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.

~~~
cforcloud
We have Apache Royale [https://royale.apache.org/](https://royale.apache.org/)
for that. Compile your Flex MXML + ActionScript to HTML + JS and more.

------
ng12
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.

~~~
chrischen
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.

~~~
ng12
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.

------
anothergoogler
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.

~~~
alexkavon
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.

~~~
h4b4n3r0
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.

------
languagehacker
"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.

~~~
l_t
Yeah, that made me laugh. Is it really a relief to have a config file you _can
't see_ instead of one you can?

~~~
dictum
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.

~~~
l_t
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".

------
RobertRoberts
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.

~~~
spankalee
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](https://github.com/Polymer/lit-element)

~~~
RobertRoberts
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.

~~~
spankalee
| 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.

~~~
RobertRoberts
> _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.

------
hardwaresofton
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.

~~~
how_to_bake
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](https://mithril.js.org)

~~~
hardwaresofton
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...

------
superasn
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

------
syspec
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

~~~
h1d
parcel-bundler bundles a modified CSS in half a second, quicker than alt
tabbing back to browser and no config file.

~~~
syspec
node-sass is still faster, and no config

------
mike1o1
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.

~~~
vmware505
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. ;)

------
andyfleming
I believe the new version of create-react-app (2.0) will have a bit more
flexibility.

See: Roadmap for react-scripts@2.0 [https://github.com/facebook/create-react-
app/issues/3815](https://github.com/facebook/create-react-app/issues/3815)

~~~
mikewhy
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...](https://gist.github.com/mikew/97e2be1d428aae8460a33dfbee0ca866)

~~~
k__
Doesn't it allow some kind of custom scripts?

~~~
mikewhy
I'm not sure if it allows custom user-based stuff.

There's things like react-scripts-ts that do things like add TypeScript. But
they are actually forks of react-scripts, a whole series of packages.

------
karmelapple
How does this compare to Ember CLI?

[https://ember-cli.com](https://ember-cli.com)

------
luord
Not gonna lie, one of my favorite things about vue is that cli.

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.

