Vue CLI 3: A Game Changer for Front End Development?
vuejsdevelopers.com
vuejsdevelopers.com
That was good.
Only drawback .. it was based on flash and got killed by Adobe.
Disclaimer: I'm the author.
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.
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 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 hope that we can get away from the plethora of little CLIs at some point.
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.
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.
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.
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.
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.
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".
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.
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
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.
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.
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.
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.
I know that Vue.js could be abandoned too, but for some reason I am not as concerned about it. (personal foible I suppose)
It's a curse and a blessing.
- 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.
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.
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...
[0]: https://gitlab.com/mrman/systemjs-plugin-vue-template-compil...
[1]: https://jspm.io/
Even if you precompile libs
See: Roadmap for react-scripts@2.0 https://github.com/facebook/create-react-app/issues/3815
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...
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.
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.