8 ms·
Vue CLI 3: A Game Changer for Front End Development?
- ng12 8y agoAm 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.
- yarrel 8y agoI 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.
- chrischen 8y agoI 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 8y agoIf 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.
- gremlinsinc 8y agoI 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.
- INTPenis 8y agoAs 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.
- bazza451 8y agoAgree, never had any problem. People just can’t be bothered to learn
- jsight 8y agoI 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.
- lechiffre10 8y agoThe 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.
- pjmlp 8y agoA 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.
- deleted 8y ago[deleted]
- hutzlibu 8y agoHave you ever tried Adobes Flex Builder? That was good. Only drawback .. it was based on flash and got killed by Adobe.
- myth_drannon 8y agoFlash (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
- brandonmenc 8y agoFlex 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 8y agoWe have Apache Royale https://royale.apache.org/ https://royale.apache.org/ for that. Compile your Flex MXML + ActionScript to HTML + JS and more.
- anothergoogler 8y agoYet, 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.
- andyfleming 8y agoI 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 8y agoI 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/97e2be1d428aae8460a33dfbee0ca866 https://gist.github.com/mikew/97e2be1d428aae8460a33dfbee0ca8...
- k__ 8y agoDoesn't it allow some kind of custom scripts?
- mikewhy 8y agoI'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.
- ng12 8y agoIt 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.
- acemarke 8y agoThere's a more standardized way to overwrite parts of a CRA config - see https://github.com/timarney/react-app-rewired https://github.com/timarney/react-app-rewired .
- anothergoogler 8y agoYo 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.
- k__ 8y agoPssht, don't tell them :D
- antonkm 8y agoI 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.
- zmmmmm 8y agoYes. 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.
- alexkavon 8y agoWelcome 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 8y agoPhtt. 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.
- karmelapple 8y agoHow does this compare to Ember CLI? https://ember-cli.com https://ember-cli.com
- RobertRoberts 8y agoNot 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 8y agoYou 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
- deleted 8y ago[deleted]
- RobertRoberts 8y agoI 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.
- mike1o1 8y agoI 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 8y agoFinally 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. ;)
- superasn 8y agoFor 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
- languagehacker 8y ago"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 8y agoYeah, that made me laugh. Is it really a relief to have a config file you can't see instead of one you can?
- dictum 8y agoGiven `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 8y agoFair 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".
- syspec 8y agoAm 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
- hardwaresofton 8y agoReasons 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 8y agoMithril[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 8y agoMithril 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...
- luord 8y agoNot 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.