4 ms·
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
by hardwaresofton 8y ago
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 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...
- jvanveen 8y agoI 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 https://github.com/wearespindle/fuet and https://github.com/wearespindle/gulp-fuet https://github.com/wearespindle/gulp-fuet), which makes it easy to keep buildsteps for component js, template markup and styling separated.
- hardwaresofton 8y agoThat'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-compiler/ https://gitlab.com/mrman/systemjs-plugin-vue-template-compil... [1]: https://jspm.io/ https://jspm.io/