My typical use case doesn't need native apps - a PWA is good enough for me. I will not comment on speculation about the compile-to-native feature because personally it is irrelevant.
I can say that as you I prefer Vue over React and some of my personal reasons are:
* I like opinionated frameworks
* I don't like to mix Javascript and HTML - I can handle a Vue template to any designer but I would not trust a JSX file to a non-programmer.
* Vue is easier for developer onboarding - with Vue the gap between a junior and a senior developer is way smaller.
React may be better, I don't care, Vue is easier for my development style.
PWA is not good enough for us due to heavy usage of mobile device camera and picture resizing (client side) for package receiving process in the warehouse. PWA fails to provide consistent performance in such conditions, and issues with bluetooth scanners in Safari/PWA on iOS devices add up. Other than that, I agree Vue.js is superior to React in a lot of use cases, especially for web.
A thing that will sell vue/react native for me is the ability to only use them for UI. I don't wanna use them for logic or heavy stuff. Just have them for render the UI.
This mean, easy way to embedb into iOS/Xamarin.NET.
I have look at react native and NativeScript and both are very hack-ish for my taste.
Good assessment. To summarize the argument, Vue.js is just as good and some would argue better than React for web development, but the React ecosystem really puts it over the top, especially React Native.
For those like me in the Vue camp, with the React-native dilemma, there is Fuse tools for the interim till week matures. Very clean separation between UI and JS logic.
I’m the founder writing code (but not the only technical person) for my three person startup. In October I started migrating our MVP from server side templates to Vue, given we had direction and traction on a product line that justified the time investment. It’s turned out to be a great decision (although likely one that could have been made with react as the choice as well).
My “success story” is how Vue helped me to massively improve our user experience in low bandwidth or high latency environments. Our startup is trying to reinvent the ways that companies approach their review process, and one of the things we do is run a workshop on delivering actionable feedback during the review cycle. We have users log into our app during the workshop, and this often happens in conference rooms over congested WiFi. Our MVP used turbolinks, so it felt generally “snappy” during normal use, but could feel sluggish if moderate latency was introduced (such as a congested router).
Since I completed the rewrite to Vue (which took only about two weeks because of how simple it was to pick up, even for a non frontend person like myself), we’ve had multiple launches that both would have likely bombed had we not done the work to move to something less dependent on a tradition client -> server -> client response cycle to render the next “page”.
Either way, I’ve become an advocate for vue. I love single file components, love the documentation, and am very happy with the community libraries. All in all, I’m very bullish for Vue in 2018 as a happy new users.
Appreciate the comment about high and low bandwidth performance by vue. 80% of the world is low bandwidth and such solutions built with such tools have an opportunity to have a much farther reach.
Have you had any exposure to using vue as a progressive web app that can sync and work offline first?
Have you come across any vue.js offline app experiences?
I've looked at PWA & working with offline, but it's an optimization I'd like to have, not one that we absolutely need. Right now, given how crunched we are for resources, everything I work on has to fall into the category of "absolutely need", otherwise I de-prioritize it.
For us, the reason why we don't necessarily "need" PWA or full offline is that we do have an initial online component that is dynamic, so fully supporting an offline mode (a la, full on iOS or Android app) would change a lot of assumptions & optimizations we've made with how our product works. PWA seems promising, but it still feels slightly early to me. It's not that I don't think it will eventually win, but right now it has just enough complexity with minimal payoff, that I've punted for now (although it's probably closest to what we're looking for).
Appreciate your detailed reply. I'm working on a problem with mobile, offline first as a key part of the solution and have been leaning towards vue if for nothing else it's appearing simplicity, flexibility, and ability for new devs to get up to speed on the project quicker.
The current incarnation / wave / interpretation of PWA still seems to be maturing. The js layer definitely brings its challenges and rewards, while browser innovation and evolution continues to better support PWA.
Still.. A bit of this PWA stuff makes me feel like we're going through a cycle from the past.
Syncing ones data and being offline for the majority of time to work on a mobile laptop or pda was normal with dialup, prior to wifi. Tools like Lotus Notes apps ran and synced data for offline use reasonably well including handling conflicts (while not so good at other things).
Offline first syncing is still largely a need inucrative remote industrial operations today and for the majority of countries in the world whom have much less bandwidth access, I'm glad PWA is emerging as a tool along with WebAssembly.
I found a few projects using vue and PWA and will try some things out - want to avoid any assumptions of adding PWA later as it's a key to my problem set.
Yes, sorry for just tossing this one in there. Our product is build on top of rails 5.x, and rails has support for turbolinks. They make your server-side rendered application 'Feel' more SPA, by only refreshing the parts of the page that have actually changed upon server response.
It still requires a massive payload to be sent across the wire, as well as a full render on the server, so it's not the "king of efficiency", but it definitely improves the end user experience in many ways.
In my case, I wanted an even snappier experience, where a user clicking on a button would trigger an immediate transition, with the "saving" happening behind the scenes. Before, on a slow or bogged down connection, you could see page transitions take second(s), which felt like an eternity when you had to go through our 50+ screens during our workshop. Now, with heavier backgrounding, those transitions are instantaneous, and the end-user doesn't need to wait but a millisecond (draw time) for the next page.
When would you recommend using turbo links over Vue? Or, conversely, would you recommend people not even bother with turbolinks?
I'm learning Rails and haven't gotten to that stuff yet, but I'm wondering whether I should even waste my time learning them if something like Vue is just superior and just as easy to implement.
You can have both at the same time. If you want to build a SPA, go for Vue only. Build if you want to have a more traditional application and only use Vue for some views, it will work with turbolinks, you just have to use a gem to help you with the caching (turbolinks cachês the body tag to speed up the back button, and the gem clears the Vue app before the caching happens making it idempotent).
I agree. We still admire Vue.js after using it for more than a year and writing hundreds of lines of Vue.js code every day. No chance I would choose React+Redux in cases when I know I need quick progress on my web project - Vue.js allows you to be very productive, cutting corners in the right places, while still keeping the reasonable code quality, and writing very little of boilerplate.
MobX+React would be just like Vue, but with the benefits of the larger React ecosystem and full type checking with typescript/flow, and the drawback of mandatory build tooling.
i've been wondering about that too, and would love to see some write-ups of people that have react+mobx for at least a few months if not more, how it worked out for them, plusses and minuses.
It is similar, but it will mean you get off the highway of React "preferred way" - for example, in case you start working with React Native you might have an issue of using different state management solutions for your web and mobile stack - it looks like nobody is using Mobx with RN in serious projects.
Actually we use React+mobx on both our web and RN stacks and it's been great. What we really like is that it is simple and extremely performant since in most cases it automatically updates only the React components that need to be re-rendered based on the state that's been modified.
We jumped directly from a flux-like state management to mobx (skipping Redux) and the development time has gone down significantly as well.
The reason I'm asking is that I've been diving into Elixir and Phoenix, and I'm wondering if the difference in speed between those two would obviate the 'need' for React/Vue (or even be a faster solution). I'm a front-end dude, so no 'enemy' of those, but I keep finding myself preferring an Elixir-based (and thus server-side) solution because it's just such a nice language and so convenient to not have to switch for significant logic.
For example, the fact that {} in js is a map/object, where in Elixir it is a tuple (a map would be %{}) keeps tripping me up, and it makes me generally either lean toward mostly server-side with some basic js snippets (Turbolinks style), or alternatively mostly client-side (React/Redux) with a 'dump' api backend in Elixir.
At this point I'd really love to lean toward the server-side, but stories like yours make me wonder about that leaning.
Same here. For us personally, the license made no difference. We know we will never come across any patent issues with Facebook. But the fact that it existed led us to believe that in the long run an alternative would emerge since larger corps would avoid it because of the license.
Now that they got rid of it, I have no such concern investing time in react for the short/mid term term.
Do Vue templates play nicely with Typescript? That's something I love about JSX -- "it's just JavaScript" is an incredibly sublime feature. I know you can use JSX with Vue but I'm skeptical since it's a first-order feature with React.
Ah, that's a bummer. Vue Templates seem wildly regressive to me -- I can't fathom going back to stringly-typed Handlebars wrangling after using JSX/TSX.
After looking into this further it seems like Vue Templates also differentiate between values and components. In React I often write components which can take in either: a good example is text which the consumer might want to format. You can easily write the component so that they pass in a string or a <span /> element.
Vue has a lot of good ideas but the templates are almost a non-starter for me.
You can use slots to pass HTML or Components into child components.
You can have vue render jsx or templates, but in practice you can make interactive components very simply using templates which are foundationally simpler and easier to grasp than JSX.
How so? In my mind templates and JSX are equally complex from a user standpoint. In fact I'd argue that JSX is simpler because you don't have to invent slots -- it's an obvious side effect of using JavaScript to generate your structure.
Just reading about slot and slot-scope makes me think Vue's reputation for simplicity is overblown.
It may seem "obvious" to you after being in the water with JSX for a while, but the free-style abstractions afforded by being 'just' JavaScript, like the one you mention, look incredibly complex for someone approaching an unknown codebase.
I agree JSX is the best part of React. The second best part is dom diffing and incremental screen update. Obviously this second part is only useful if your application needs to update screens it previously rendered. In fact I'd argue that React is only useful if you need to incrementally update complex screens, because simple screens can be re-rendered completely and no one will know the difference. Very few applications need to incrementally update complex screens. If your application doesn't have this need you can use simpler technologies that don't have the same "Care and feed" requirements of React, such as UIBuilder: https://github.com/wisercoder/uibuilder
I'm afraid React is eventually turning into Angular. At some point, I felt that Angular is somebody's PhD work exploring arcane computer science concepts, not a piece of software for practical use.
Wondering the same thing myself. They are very different all the way to their core. Angular is a full-blown framework; React is a view library. Angular's API and documentation are (excessively) large; React's documentation can be easily perused in under a day. React components are just functions (or classes) and thus can be tested with such ease. Angular testing is, last time I checked, way too complex to get up and running.
First, probably was their approach to implicitly require use of Observable objects everywhere.
Second, use of arcane CS lingo and authors writing 10 pages long pages on every known MVC model, FLUX, SCHMUX and etc with weekly regularity.
Third, during transition to Fiber, they went on gigantic increase of complexity by introducing a lot of what can be said to be heuristic rules, and all for non-guaranteed, minor performance gain.
The first point must be cross-over from angular :-) He said he doesn't like angular, that must be why.
Personally, I am super jealous of angular for having observables. I work with React and would love some Rx in our app too, but we aren't using it. Ditto for typescript - our app is mostly untyped javascript with sprinkles of Flow, while angular would have enforced typescript.
React does not require use of Observables in any way.
I also have no idea what your second and third points could be referring to. If you can supply some links as references, I can try to provide some context or explanation, but at the moment you seem to be making up things that don't exist to complain about.
It looks like you might be conflating React with some other parts of the ecosystem that has built up around it. React retains a far simpler API than the heavier JS frameworks, and AFAIK it doesn't need or do any of the things you mentioned there on its own.
The most basic approach for responding to a change in data is to compare the previous and current props in the `componentWillReceiveProps` or `componentDidUpdate` lifecycle methods.
Meanwhile, Redux is the most common state management library used with React apps.
You certainly _can_ use MobX, RxJS, or some other FRP-type library with React, but to claim that "the whole ecosystem is heavily tied to them" is simply wrong, and shows a gross misunderstanding of the React world.
>but to claim that "the whole ecosystem is heavily tied to them" is simply wrong, and shows a gross misunderstanding of the React world.
May be, but this is how it looks from my part of the world, which is Russia or China when I am doing term contracts there from time to time.
Here, the so called "software evangelists", apparently paid or hired by FB, swarm tech events to lecture people on how to do "10 tricks to transform your eCommerce business with Agile management, and FLUX pattern". And they get pretty annoying. My experience with React ends with my interaction with them and doing basic demos for recruitment interviews. I have not yet heard of a FRP-framework-free React site being considered norm for a "serious project" here.
Just like those FB "evangelists" do today, Angular proponents were doing the same 5 years ago with their maxim: "the magic provider/factory/service pattern is the new best thing since a sliced bread" without elaborating much why. That lead to many mentally-infirm developers trying to shove it everywhere, making usage of Angular ecosystem without zealous following of that pattern impossible.
I have impression that the same is happening with FRP-everywhere crowd and React.
I certainly don't claim to know everything that goes on in the React ecosystem (especially outside the US), but I _am_ pretty tuned in with the major trends and discussions that are going on, and I've seen plenty of real-world React applications and codebases. None of that matches anything I've seen thus far.
I have never heard of Facebook paying "software evangelists". I suppose it's possible, but it really doesn't match with what I know about how Facebook develops and uses React.
> There is no explicit dependency on RXJS or its analogs, but the whole ecosystem is heavily tied to on them.
That's flat out untrue. This might be some people's approach but in all my years of writing React apps as a consultant I haven't had to use any of those libraries on a project.
FWIW that problem is usually solved by reorganizing code a bit and passing a callback down.
Hmm, Vue is the one that reminds me of Angular, since it seems to emphasize the ease of constructing views, by its two-way data binding and custom directive syntax inside html.
I enjoyed the "Why Vue.js" video. It communicated to me that Vue is really trying to design an easy path (even for non-programmers) to use React's patterns, by mixing in some old ideas that people are familiar and comfortable with.
Vue data is one-way binding these days. There’s a separate way to do two way binding for forms though (which is really a much more convenient mechanism for forms)
Regardless of React's minor growth in complexity it still pales in comparison to Angular's api from a new learners perspective. After finishing a project in Angular I still feel dumb to it's central concepts. React made sense before I wrote anything.
When it comes to UI need to start thinking past Framework A vs Framework B.
There is already a browser-native compatibility layer known as the Web Components API that allow components rendered by different frameworks to work together, so we won't ever have to be stuck in Framework A or Framework B and can migrate in agile manner (one component at a time) from one to the other or whatever new framework may come next year. I agree Web Components have some major warts and DX issues but libraries like SkateJS and others help smooth those out.
Copying from Readme my WIP project that uses Skate:
"SkateJS allows us to export components rendered by React, Angular 2, 4, Vue, and other modern composition-oriented frameworks as W3C Custom Elements and compose those Custom Elements into higher order Custom Elements with data flowing from parent to descendants and so on.
With SkateJS we can have an Angular 4-rendered Form custom element composing Angular 2-rendered input and selection custom elements, or the other way around with Angular 2-rendered Form custom element composing Angular 5 --and Angular 4-- rendered input and selection custom elements.
SkateJS also provides a Router that is framework agnostic. Only the rendering part of any framework (Angular, React, Preact, Vue, et al) is ever used.
This way we can build SkateJS-based reusable component libraries using any version of Angular (> 2), React, Vue et al and be able to use those components in our SkateJs-based site together, including via composition, and be able to upgrade our app (when a new version of React, Angular or Vue et al comes out) one component at a time, in piecemeal fashion as in iterative agile development, as opposed to having to do it all at once, as in waterfall development, which is almost always an unrealistic approach. This works because our components are essentially all custom elements regardless of rendering library we use (different versions of Angular, React, Preact, Vue, et al)"
Agree, also drawing conclusions form "heard of it would like to learn" on the graph seems a bit far fetching. I would like to learn vue but I do not see opportunities in my job to use it next year.
Huh? OP said the power of the React ecosystem and change in license will keep it on top in 2018 and that if they were starting from scratch they probably would have used React for their website.
OP did not say they would've used React given the choice, they said it would have made some things simpler
Your reading and subtle re-wording of OPs comments misrepresent what OP actually says.
> our stack would be simpler if we chose React.js for the web. We definitely do not regret choosing Vue.js for web, read more in my previous post why we did that, my expectations on Vue.js web domination are becoming the reality
Not necessarily.. I wonder had react not been backed by FB, it certainly would have had a beating in its popularity given lighter and arguably faster alternatives like vue. Remember, performance was one of the main argument React had when compare to Angular. Now since performance is no more a differentiating factor, developers might look into other aspects like better ROI in short and long term..
Just as one anecdotal data point, we didn't choose React for its performance when evaluating tools for our recent projects. (React can still be orders of magnitude slower than localised direct DOM updates on demand, after all, and in cases where performance really matters that might still be what you have to fall back on.)
The game-changer with React is that it presents a declarative way to specify your DOM content, which in turn can significantly reduce the number of cases you have to consider in your rendering and state management code, and it's fast enough to make that work in a lot of real world situations.
Could be for you, but have you wondered if React was say way slower than Angular and heavier, the adoption would have been much much lower?. Agreed, the model that React brought is superior but the catalyst was performance. They even highlighted performance as the main selling point with introducing the virtual dom, where the computation (dom querying) happens not in the dom but in the javascript, which is arguably faster and only differential updates are applied to the actual dom.
In my friend circle everyone wanted/were using Angular.js but it was too heavy for actual production use while react showed much better performance in the benchmarks (almost closer to Dom).
React and Angular are solutions to different problems. I don't think React would have succeeded without adequate performance, but I also don't think it is why React has been successful or the main reason it has displaced some of Angular's "market share"; being fast enough is necessary but not sufficient to do its job.
Not true - Ractive is a library much like vue on the surface that came out _before_ React. It's all about timing, promotion and hitting a feature sweet spot.
MVVM was a thing for like that six month period in 2012 when backbone.js was causing callback hell and React.js hadn't come out yet, MVVM is an attempt to abstract over the callbacks.
- it’s used at FB so all decisions they make are guided by their own practical needs: don’t break backwards ompatibility, don’t break tools, improve tools, create tools where none existed etc. etc. etc.
React team has a very pragmatic approach to development, and it shows.
A good indicator of if a technology is going to explode, is if emerging language users are excited about it, as good ideas tend to trickle down from the more advanced/research-y ecosystems which aren't as constrained by legacy. So for example React was built by a user of OCaml.
ClojureScript early adopted React.js through the Om project in 2013 and there is a growing number of competing React adapters, Clojure rewrites etc. I first saw virtual-dom in ClojureScript in 2012 (eight months before React came out).
Number of ClojureScript projects with traction that are based on vue? Zero, that I am aware of.
Ehhh, I don't think that's really telling in this case. Clojurescript layers plenty on top React, so it's really just a library layer over which cljs devs write entirely different DSLs.
The Vue reactive and dom model is pretty much entirely the same as React, it's just its layout for frontend applications that's wildly different. Even if you wanted the component-file style thing in clojure (or html-templates), you wouldn't need Vue to do it.
I think it's really people's experience. I'm in your camp, I write functional javascript, I learned clojure, I think about writing software in a way where react-redux (and re-frame) fit the paradigm and get out of the way. Vue seems like Backbone v2 after drawing inspiration from Ember and Angular
Speaking as someone who writes ClojureScript themselves, ClojureScript is definitely in the category of technologies that show no sign of explosion whatsoever.
React and Vue are both great technologies, but with Teact the template syntax is optional, and no lisp user wants another syntax...
I picked up ClojureScript at the end of 2013. I was a C++ developer then in a small firm and was tasked to write a web frontend. Outsourcing that project had failed before (2 times iirc), so my boss bet on me to do it. I knew HTML and had written probably < 1000 lines of Javascript code in my life before. Anyway, I needed to write an interactive single page app (basically it was a visualization of simulation results), so I needed Javascript. But it was so frustrating to write Javascript (also, tooling was mediocre back then or I didn't know it). So at the same time, I stumbled over ClojureScript and had a try (I new Scheme before and was especially outraged by JS syntax quirks, so I hoped S-expressions would rescue me). With ClojureScript in 2013 I had a module system that handled dependencies, an emerging library ecosystem that had what I needed for that specific case, I was pretty happy. This was more advanced than what I got with JS (I might not have found the viable options for such stuff with JS, but at least information on them wasn't widely found then).
Last year I had another look at ClojureScript and it felt like a ghost town. This saddens me. There are a few inspiring talks now and then, but nothing I found worth using in a project.
Not sure about the inspiring talks or whatnot, but I've been writing clojure/clojurescript (reagent, re-frame et al.) professionally for a couple of years and there's nothing I can't find that I need in a project. With simple js interoperability, native use of js/react components in reagent and ease of wrapping any vanilla js library, there really is nothing you can't do with clojurescript. You should take a closer look!
I'm really surprised by this assessment. I've been working with ClojureScript for the past three years, and I find the ecosystem is very vibrant. ClojureScript itself has been evolving rapidly. Lately there's been a lot of focus on Js ecosystem integration allowing you to do things such as consuming NPM modules directly. The compiler itself is very efficient doing things like dead code elimination and minification out of the box.
In terms of libraries, I haven't found anything that comes close to reagent/re-frame for building complex UIs.
Meanwhile, hot code reloading with Figwheel works beautifully, and you have a REPL for running code in the browser straight from the editor.
My team is very happy with the results of building ClojureScript based applications. I'd be curious to hear why you feel that there's nothing that's worth putting in a project.
I really enjoy ClojureScript, and haven't found it to be a ghost town at all. Reagent and re-frame + Figwheel are a killer combo. ClojureScript's JS interop is stellar.
I guess compared to the frantic pace of the JS ecosystem, the ClojureScript ecosystem does feel tiny and slow-paced. But I don't mind that.
1) I didn't say that, I said good ideas trickle from research ecosystems to industry ecosystems, because legacy
2) Ruby (1995) showed no signs of explosion whatsoever, first rails had to come out (2005), and then industry had to realize that it was a good idea (Rails 3 is the first version I ever used, that was in 2009?). So that's 10-14 years. ClojureScript is 6. Give it a chance!
I think both of them are awesome and have great communities. Especially seeing as webpack has stabilized.
If you're a startup, it's tempting for many founders to go in headfirst with a Vue or React. In my opinion, it's rarely necessary, and in the end a lot of the stuff has to be thrown out if underlying foundations change. I see it as web development's version of premature optimization.
On the other hand, when I kept all my work in django templates, erb, blade, etc. and just script JS by hand, there's less of a penalty when the data flow changes. When I was using a JS framework, the refactoring was so painful I seriously considered throwing the whole thing out and starting from scratch. Heh, I'd have been better off not buying in so early on.
My plan is after stuff is solid and in production and the product/service/business is moving forward, taking an incremental approach to moving to vue/react/etc.
P.S. kudos to react for removing the patent stuff in v16.
I disagree. Coming from python, my first foray into web frontend was a SPA for mobile. Both my coworkers convinced me to go right to react + redux (after some bumbling first with more "traditional" ajax). After a few weeks of utter bewilderment, I have to say I really enjoy this stack. Some say it's overkill, but the framework really helps me organize things into cognitive chunks, and makes debugging so much easier.
Ever had a class in school which you hated at the time because it felt super hard, but loved in hindsight because of how much you learned? same sort of vibe. Fight through the pain.
I am in the same boat you are. I've tried frameworks before that ended up being a mess later to recover from.
Also, I see Shadow DOM, proper html/js templates and future JS upgrades (modules, etc...) making React totally usesless, or either they will have to uproot themselves all over again to maintain equal performance from native systems.
As soon as I saw that rounded corners were coming to CSS, I stopped all the stupid hacks, I feel like JSX is an immature hack on top of mature tech. Eventually something else will come along and supplant it.
When it comes to UI need to start thinking past Framework A vs Framework B.
There is already a browser-native compatibility layer known as the Web Components API that allow components rendered by different frameworks to work together, so we won't ever have to be stuck in Framework A or Framework B and can migrate in agile manner (one component at a time) from one to the other or whatever new framework may come next year. I agree Web Components have some major warts and DX issues but libraries like SkateJS and others help smooth those out.
Copying from Readme my WIP project that uses Skate:
"SkateJS allows us to export components rendered by React, Angular 2, 4, Vue, and other modern composition-oriented frameworks as W3C Custom Elements and compose those Custom Elements into higher order Custom Elements with data flowing from parent to descendants and so on.
With SkateJS we can have an Angular 4-rendered Form custom element composing Angular 2-rendered input and selection custom elements, or the other way around with Angular 2-rendered Form custom element composing Angular 5 --and Angular 4-- rendered input and selection custom elements.
SkateJS also provides a Router that is framework agnostic. Only the rendering part of any framework (Angular, React, Preact, Vue, et al) is ever used.
This way we can build SkateJS-based reusable component libraries using any version of Angular (> 2), React, Vue et al and be able to use those components in our SkateJs-based site together, including via composition, and be able to upgrade our app (when a new version of React, Angular or Vue et al comes out) one component at a time, in piecemeal fashion as in iterative agile development, as opposed to having to do it all at once, as in waterfall development, which is almost always an unrealistic approach. This works because our components are essentially all custom elements regardless of rendering library we use (different versions of Angular, React, Preact, Vue, et al)"
When it comes to UI need to start thinking past Framework A vs Framework B.
There is already a browser-native compatibility layer known as the Web Components API that allow components rendered by different frameworks to work together, so we won't ever have to be stuck in Framework A or Framework B and can migrate in agile manner (one component at a time) from one to the other or whatever new framework may come next year. I agree Web Components have some major warts and DX issues but libraries like SkateJS and others help smooth those out.
Copying from Readme my WIP project that uses Skate:
"SkateJS allows us to export components rendered by React, Angular 2, 4, Vue, and other modern composition-oriented frameworks as W3C Custom Elements and compose those Custom Elements into higher order Custom Elements with data flowing from parent to descendants and so on.
With SkateJS we can have an Angular 4-rendered Form custom element composing Angular 2-rendered input and selection custom elements, or the other way around with Angular 2-rendered Form custom element composing Angular 5 --and Angular 4-- rendered input and selection custom elements.
SkateJS also provides a Router that is framework agnostic. Only the rendering part of any framework (Angular, React, Preact, Vue, et al) is ever used.
This way we can build SkateJS-based reusable component libraries using any version of Angular (> 2), React, Vue et al and be able to use those components in our SkateJs-based site together, including via composition, and be able to upgrade our app (when a new version of React, Angular or Vue et al comes out) one component at a time, in piecemeal fashion as in iterative agile development, as opposed to having to do it all at once, as in waterfall development, which is almost always an unrealistic approach. This works because our components are essentially all custom elements regardless of rendering library we use (different versions of Angular, React, Preact, Vue, et al)"
Facebook has corrected the licensing issue. Most consider it a non-issue now. And I think Facebook proved with that move that they are willing to play ball.
That might not matter that much. There's still a strong argument for implementing native apps using their own SDKs. There are more developers with experience with them, there is more boilerplate and examples, third party integrations are typically designed for them, and more books and documentation are for them. On the front page of HN today there was a stackshare post about a startup with only three engineers that used a lot of cutting edge tools, but React Native was not one of them.
Weex is not a part of the titular Vue project, but can be said to be the most endorsed one, and one that is the most up to date with Vue upstream development.
One thing I'm noticing about SPAs is that they're often slower to load, but the slowness and loading animations gives me a higher perception of the quality of the application.
The same application loading and doing things instantly as server-side templates feels comparatively cheap and un-modern.
I personally prefer Vue because it is approachable and easy to adopt. I believe that if Vue embraces PWAs in a pragmatic way that performs and is accessible, it will be top for a while.
At the moment, PWA is not a viable replacement for some cases, but it’s about to explode to everyone.
I really don't get the love around vue... I always read the glowing sentiment and go, "Ok, I'm missing something, let me go back to the vue.js docs and see what's good"
Things that are a deal breaker for me:
Template language... You can call it 'separation of concerns' all you want, but just let me generate templates using the language I already know, JSX is great
State management... I cut my teeth with Ember professionally for a few years, and really loved it up until I built a data intensive app. Having state spread across different controllers is great when you have many different routes and pages, but if one page turns in to a photoshop like app, controllers make a terrible state management tool. It doesn't seem overly complicated to me to use redux along with react-redux's connect function to connect regular functions returning JSX to your state object. Looking at Vue.js, it seems like I need to learn Ember-lite + Angular (custom directives).
"Template language... You can call it 'separation of concerns' all you want, but just let me generate templates using the language I already know, JSX is great"
Not everyone knows JSX, so while that argument applies to you, it doesn't apply in general.
They mean javascript; jsx is a very small amount of new syntax and is embedded in normal javascript. Learning a completely separate template language with all of its own constructs for conditionals, iteration, etc. is significantly more work.
There’s not any more to learn vs html than jsx. It’s like 5 relevant constructs that all follow the same form, and the colon. Takes 20 minutes to have it down pat.
v-if is actually a big reason I prefer Vue. Ternary operators in JSX are pretty ugly. The other is that Vuex just feels so perfectly integrated. I've never felt Redux blends in particularly cleanly, though I certainly don't judge people that do prefer it.
I'm aware of that bit, I just think they're an ugly piece of control flow inside JSX, and they're also not a particularly versatile piece of control flow.
Especially for the else-if case - you end up with repetitive conditionals to replicate that.
Exactly! I don't know, but I've always found that disgusting. It turned me off React when I first saw it, and it still does.
Then people use it to defend react, and I'm just like 'Lolwut? Did we spend years learning that SOC is a good thing only to throw it out of the window?'
I'll be the first to admit that any Vue template quickly becomes soup as well, but at least it's only half of the soup.
Is it just younger developers that think React is the best thing since sliced bread?
JSX is a thin XML-like DSL on top of Javascript.[1] Unlike untyped strings with a custom parser of Vue, which require you to write something that’s neither HTML nor Javascript.
You can have as much separation of concern as you like with React.
Ok, so they both let you use something more like what you already know, except neither of them are technically JavaScript or HTML. Glad we established that. I think the understated bikeshed color here is that VueJS allows you to use jade/pug syntax instead of HTML.
It's very well structured, easy to understand, batteries included, lends itself well to maintainability and scale.
When working for a company with staff below me who had very basic understanding of JS (having just done HTML/CSS/JQuery, had no idea what a promise was), there was almost no learning curve with Angular. The hardest part was understanding what a component was, then learning the folder structure.
Angular's seamless use of templating, the built in support for CSS pre-processing and simplicity of uni-directional databinding had the entire team pick it up and be productive almost immediately.
Using decorators to declare inputs/outputs on dumb components is clear, readable and easy to understand.
Class based components are also very clear.
Some say TS is annoying and all power to you, but using types is optional. Personally, TS has allowed me to save on some test cases by virtue of the compiler catching those issues. Plus there is a comfort in quality intellisense.
Vue is cool, it's like a less opinionated Angular. In my opinion, it's strength is its ability to be dropped into any project, giving you client side components and databinding irrespective of your stack. However I have experienced growing pains in larger projects as a result of people over complicating simple solutions.
I am still relatively inexperienced though, and I intend to spend more time with Vue to see if I can't like it more. I'm sure all of my concerns are addressable. So far though, Angular has treated me very kindly, both in large and small scale projects.
There are some things Angular does do far better than React IMO - Angular’s pain points are frustrating to me in terms of how I prefer to code though, largely due to its choice of supporting TS first and TS’s issues with toolchain integration/perf & not very conducive to FP, but it also has less pain in some respects such as when it comes to state.
Having used both React (with Typescript and Redux) and the latest Vue (with es6 and Vuex) I prefer React, and I don't even use React Native.
Vue is better for onboarding people more in tune with "classic" html + js development; and that's where the advantages end as far as I'm concerned. This might be a big win for some people.
The way I reason about it is that React is simple, Vue is easy.
When you take into account Vue's templating language, React's api is small in comparison.
A beginner won't know how to do some common use cases reading React's docs, when Vue might have a something built-in in its templating language (e.g. slots, or the component tag for dynamic components).
Slightly annoyed with Vuex too because of its slightly leaky abstraction.
You have to remember to setup the properties you mutate so the reactivity will detect a change; and also remember not use array indexes arrays cause it can't detect changes otherwise. The array index thing will be fixed in the next version when they drop support for some older IE.
Using Typescript would probably help a bit here, although Typescript being useless for checking Vue templates really feels like a huge chunk of its value is wasted.
Typescript is not currently available in the official blessed boilerplate which greatly affects its uptake in the Vue community.
Anyway, if you already know React, there is zero advantage in investing time in Vue.
Glad to see Mithril mentioned. I like it better than React when comparing the APIs, It just seems simpler. But React obviously has the mind share. I'd love to see Mithril gain momentum.
I especially like the fact that I can easily include it as a script, like Vue, and don't have to have a build chain. That really decreases complexity for smaller projects.
> You have to remember to setup the properties you mutate so the reactivity will detect a change
This is a positive thing imo. It's a declaration of your data schema. You can reference it to remember what kind of data you're working with. This gets rid of unproductive moments like "What was the name of this property again? Is this property an object or an array? Is it nested inside this object or that object?"
176 comments
[ 3.0 ms ] story [ 154 ms ] threadLikely, we can expect something comprehensive for native this year.
I also believe it's a smart strategy to avoid Facebook codebases because they are all meant to somehow benefit FB in some (usually dubious) way.
Also the Vue approach is 1000% cleaner in practice than React, just doesn't have the bandwagon effect going for it
I can say that as you I prefer Vue over React and some of my personal reasons are:
* I like opinionated frameworks
* I don't like to mix Javascript and HTML - I can handle a Vue template to any designer but I would not trust a JSX file to a non-programmer.
* Vue is easier for developer onboarding - with Vue the gap between a junior and a senior developer is way smaller.
React may be better, I don't care, Vue is easier for my development style.
* Vue downscales. If you have a single scripted component in a page, you will get a simple page, with a small amount of Vue added.
This mean, easy way to embedb into iOS/Xamarin.NET.
I have look at react native and NativeScript and both are very hack-ish for my taste.
My “success story” is how Vue helped me to massively improve our user experience in low bandwidth or high latency environments. Our startup is trying to reinvent the ways that companies approach their review process, and one of the things we do is run a workshop on delivering actionable feedback during the review cycle. We have users log into our app during the workshop, and this often happens in conference rooms over congested WiFi. Our MVP used turbolinks, so it felt generally “snappy” during normal use, but could feel sluggish if moderate latency was introduced (such as a congested router).
Since I completed the rewrite to Vue (which took only about two weeks because of how simple it was to pick up, even for a non frontend person like myself), we’ve had multiple launches that both would have likely bombed had we not done the work to move to something less dependent on a tradition client -> server -> client response cycle to render the next “page”.
Either way, I’ve become an advocate for vue. I love single file components, love the documentation, and am very happy with the community libraries. All in all, I’m very bullish for Vue in 2018 as a happy new users.
Have you had any exposure to using vue as a progressive web app that can sync and work offline first?
Have you come across any vue.js offline app experiences?
For us, the reason why we don't necessarily "need" PWA or full offline is that we do have an initial online component that is dynamic, so fully supporting an offline mode (a la, full on iOS or Android app) would change a lot of assumptions & optimizations we've made with how our product works. PWA seems promising, but it still feels slightly early to me. It's not that I don't think it will eventually win, but right now it has just enough complexity with minimal payoff, that I've punted for now (although it's probably closest to what we're looking for).
The current incarnation / wave / interpretation of PWA still seems to be maturing. The js layer definitely brings its challenges and rewards, while browser innovation and evolution continues to better support PWA.
Still.. A bit of this PWA stuff makes me feel like we're going through a cycle from the past.
Syncing ones data and being offline for the majority of time to work on a mobile laptop or pda was normal with dialup, prior to wifi. Tools like Lotus Notes apps ran and synced data for offline use reasonably well including handling conflicts (while not so good at other things).
Offline first syncing is still largely a need inucrative remote industrial operations today and for the majority of countries in the world whom have much less bandwidth access, I'm glad PWA is emerging as a tool along with WebAssembly.
I found a few projects using vue and PWA and will try some things out - want to avoid any assumptions of adding PWA later as it's a key to my problem set.
https://github.com/turbolinks/turbolinks
It still requires a massive payload to be sent across the wire, as well as a full render on the server, so it's not the "king of efficiency", but it definitely improves the end user experience in many ways.
In my case, I wanted an even snappier experience, where a user clicking on a button would trigger an immediate transition, with the "saving" happening behind the scenes. Before, on a slow or bogged down connection, you could see page transitions take second(s), which felt like an eternity when you had to go through our 50+ screens during our workshop. Now, with heavier backgrounding, those transitions are instantaneous, and the end-user doesn't need to wait but a millisecond (draw time) for the next page.
I'm learning Rails and haven't gotten to that stuff yet, but I'm wondering whether I should even waste my time learning them if something like Vue is just superior and just as easy to implement.
Turbolinks is amazing.
Also tutorials for react+mobx.
We jumped directly from a flux-like state management to mobx (skipping Redux) and the development time has gone down significantly as well.
The reason I'm asking is that I've been diving into Elixir and Phoenix, and I'm wondering if the difference in speed between those two would obviate the 'need' for React/Vue (or even be a faster solution). I'm a front-end dude, so no 'enemy' of those, but I keep finding myself preferring an Elixir-based (and thus server-side) solution because it's just such a nice language and so convenient to not have to switch for significant logic.
For example, the fact that {} in js is a map/object, where in Elixir it is a tuple (a map would be %{}) keeps tripping me up, and it makes me generally either lean toward mostly server-side with some basic js snippets (Turbolinks style), or alternatively mostly client-side (React/Redux) with a 'dump' api backend in Elixir.
At this point I'd really love to lean toward the server-side, but stories like yours make me wonder about that leaning.
Now that they got rid of it, I have no such concern investing time in react for the short/mid term term.
After looking into this further it seems like Vue Templates also differentiate between values and components. In React I often write components which can take in either: a good example is text which the consumer might want to format. You can easily write the component so that they pass in a string or a <span /> element.
Vue has a lot of good ideas but the templates are almost a non-starter for me.
Redux is not as easy but you can go with MobX instead for easier state management.
You can have vue render jsx or templates, but in practice you can make interactive components very simply using templates which are foundationally simpler and easier to grasp than JSX.
Just reading about slot and slot-scope makes me think Vue's reputation for simplicity is overblown.
React gets closer to that with each year.
Second, use of arcane CS lingo and authors writing 10 pages long pages on every known MVC model, FLUX, SCHMUX and etc with weekly regularity.
Third, during transition to Fiber, they went on gigantic increase of complexity by introducing a lot of what can be said to be heuristic rules, and all for non-guaranteed, minor performance gain.
2) Please clarify what you mean by this.
3) By all accounts, the fiber codebase is much simpler than the stack codebase, performs similarly and opens up some exciting new possibilities.
Personally, I am super jealous of angular for having observables. I work with React and would love some Rx in our app too, but we aren't using it. Ditto for typescript - our app is mostly untyped javascript with sprinkles of Flow, while angular would have enforced typescript.
React does not require use of Observables in any way.
I also have no idea what your second and third points could be referring to. If you can supply some links as references, I can try to provide some context or explanation, but at the moment you seem to be making up things that don't exist to complain about.
A question "how to do thing A when user changes thing B" on React forums is usually dismissed with "just use MobX/Rxjs/Kefir/Bacon"
The most basic approach for responding to a change in data is to compare the previous and current props in the `componentWillReceiveProps` or `componentDidUpdate` lifecycle methods.
Meanwhile, Redux is the most common state management library used with React apps.
You certainly _can_ use MobX, RxJS, or some other FRP-type library with React, but to claim that "the whole ecosystem is heavily tied to them" is simply wrong, and shows a gross misunderstanding of the React world.
May be, but this is how it looks from my part of the world, which is Russia or China when I am doing term contracts there from time to time.
Here, the so called "software evangelists", apparently paid or hired by FB, swarm tech events to lecture people on how to do "10 tricks to transform your eCommerce business with Agile management, and FLUX pattern". And they get pretty annoying. My experience with React ends with my interaction with them and doing basic demos for recruitment interviews. I have not yet heard of a FRP-framework-free React site being considered norm for a "serious project" here.
Just like those FB "evangelists" do today, Angular proponents were doing the same 5 years ago with their maxim: "the magic provider/factory/service pattern is the new best thing since a sliced bread" without elaborating much why. That lead to many mentally-infirm developers trying to shove it everywhere, making usage of Angular ecosystem without zealous following of that pattern impossible.
I have impression that the same is happening with FRP-everywhere crowd and React.
If this isn't how it is, I am glad.
I have never heard of Facebook paying "software evangelists". I suppose it's possible, but it really doesn't match with what I know about how Facebook develops and uses React.
That's flat out untrue. This might be some people's approach but in all my years of writing React apps as a consultant I haven't had to use any of those libraries on a project.
FWIW that problem is usually solved by reorganizing code a bit and passing a callback down.
I enjoyed the "Why Vue.js" video. It communicated to me that Vue is really trying to design an easy path (even for non-programmers) to use React's patterns, by mixing in some old ideas that people are familiar and comfortable with.
There is already a browser-native compatibility layer known as the Web Components API that allow components rendered by different frameworks to work together, so we won't ever have to be stuck in Framework A or Framework B and can migrate in agile manner (one component at a time) from one to the other or whatever new framework may come next year. I agree Web Components have some major warts and DX issues but libraries like SkateJS and others help smooth those out.
Copying from Readme my WIP project that uses Skate:
"SkateJS allows us to export components rendered by React, Angular 2, 4, Vue, and other modern composition-oriented frameworks as W3C Custom Elements and compose those Custom Elements into higher order Custom Elements with data flowing from parent to descendants and so on.
With SkateJS we can have an Angular 4-rendered Form custom element composing Angular 2-rendered input and selection custom elements, or the other way around with Angular 2-rendered Form custom element composing Angular 5 --and Angular 4-- rendered input and selection custom elements.
SkateJS also provides a Router that is framework agnostic. Only the rendering part of any framework (Angular, React, Preact, Vue, et al) is ever used.
This way we can build SkateJS-based reusable component libraries using any version of Angular (> 2), React, Vue et al and be able to use those components in our SkateJs-based site together, including via composition, and be able to upgrade our app (when a new version of React, Angular or Vue et al comes out) one component at a time, in piecemeal fashion as in iterative agile development, as opposed to having to do it all at once, as in waterfall development, which is almost always an unrealistic approach. This works because our components are essentially all custom elements regardless of rendering library we use (different versions of Angular, React, Preact, Vue, et al)"
Also OP has skin in the game to justify to his team that vue was the correct choice.
Nice as an opinion piece but too many red flags to be considered fair and unbiased.
> Vue.js will be dominating only in the web
OP did not say they would've used React given the choice, they said it would have made some things simpler
Your reading and subtle re-wording of OPs comments misrepresent what OP actually says.
> our stack would be simpler if we chose React.js for the web. We definitely do not regret choosing Vue.js for web, read more in my previous post why we did that, my expectations on Vue.js web domination are becoming the reality
The game-changer with React is that it presents a declarative way to specify your DOM content, which in turn can significantly reduce the number of cases you have to consider in your rendering and state management code, and it's fast enough to make that work in a lot of real world situations.
In my friend circle everyone wanted/were using Angular.js but it was too heavy for actual production use while react showed much better performance in the benchmarks (almost closer to Dom).
MVVM was a thing for like that six month period in 2012 when backbone.js was causing callback hell and React.js hadn't come out yet, MVVM is an attempt to abstract over the callbacks.
React leads the pack in:
- consistently good DX
- it’s used at FB so all decisions they make are guided by their own practical needs: don’t break backwards ompatibility, don’t break tools, improve tools, create tools where none existed etc. etc. etc.
React team has a very pragmatic approach to development, and it shows.
A good indicator of if a technology is going to explode, is if emerging language users are excited about it, as good ideas tend to trickle down from the more advanced/research-y ecosystems which aren't as constrained by legacy. So for example React was built by a user of OCaml.
ClojureScript early adopted React.js through the Om project in 2013 and there is a growing number of competing React adapters, Clojure rewrites etc. I first saw virtual-dom in ClojureScript in 2012 (eight months before React came out).
Number of ClojureScript projects with traction that are based on vue? Zero, that I am aware of.
The Vue reactive and dom model is pretty much entirely the same as React, it's just its layout for frontend applications that's wildly different. Even if you wanted the component-file style thing in clojure (or html-templates), you wouldn't need Vue to do it.
React and Vue are both great technologies, but with Teact the template syntax is optional, and no lisp user wants another syntax...
Last year I had another look at ClojureScript and it felt like a ghost town. This saddens me. There are a few inspiring talks now and then, but nothing I found worth using in a project.
In terms of libraries, I haven't found anything that comes close to reagent/re-frame for building complex UIs.
Meanwhile, hot code reloading with Figwheel works beautifully, and you have a REPL for running code in the browser straight from the editor.
My team is very happy with the results of building ClojureScript based applications. I'd be curious to hear why you feel that there's nothing that's worth putting in a project.
I guess compared to the frantic pace of the JS ecosystem, the ClojureScript ecosystem does feel tiny and slow-paced. But I don't mind that.
2) Ruby (1995) showed no signs of explosion whatsoever, first rails had to come out (2005), and then industry had to realize that it was a good idea (Rails 3 is the first version I ever used, that was in 2009?). So that's 10-14 years. ClojureScript is 6. Give it a chance!
If you're a startup, it's tempting for many founders to go in headfirst with a Vue or React. In my opinion, it's rarely necessary, and in the end a lot of the stuff has to be thrown out if underlying foundations change. I see it as web development's version of premature optimization.
On the other hand, when I kept all my work in django templates, erb, blade, etc. and just script JS by hand, there's less of a penalty when the data flow changes. When I was using a JS framework, the refactoring was so painful I seriously considered throwing the whole thing out and starting from scratch. Heh, I'd have been better off not buying in so early on.
As a stop-gap, I'm using pjax. (https://github.com/defunkt/jquery-pjax)
My plan is after stuff is solid and in production and the product/service/business is moving forward, taking an incremental approach to moving to vue/react/etc.
P.S. kudos to react for removing the patent stuff in v16.
Ever had a class in school which you hated at the time because it felt super hard, but loved in hindsight because of how much you learned? same sort of vibe. Fight through the pain.
Also, I see Shadow DOM, proper html/js templates and future JS upgrades (modules, etc...) making React totally usesless, or either they will have to uproot themselves all over again to maintain equal performance from native systems.
As soon as I saw that rounded corners were coming to CSS, I stopped all the stupid hacks, I feel like JSX is an immature hack on top of mature tech. Eventually something else will come along and supplant it.
I would choose riotjs or vuejs anyday before any facebook's code in my apps.
I wouldn't feel confident picking that as my company's future.
The same application loading and doing things instantly as server-side templates feels comparatively cheap and un-modern.
What is wrong with me?
At the moment, PWA is not a viable replacement for some cases, but it’s about to explode to everyone.
Things that are a deal breaker for me:
Template language... You can call it 'separation of concerns' all you want, but just let me generate templates using the language I already know, JSX is great
State management... I cut my teeth with Ember professionally for a few years, and really loved it up until I built a data intensive app. Having state spread across different controllers is great when you have many different routes and pages, but if one page turns in to a photoshop like app, controllers make a terrible state management tool. It doesn't seem overly complicated to me to use redux along with react-redux's connect function to connect regular functions returning JSX to your state object. Looking at Vue.js, it seems like I need to learn Ember-lite + Angular (custom directives).
> let me generate templates using the language I already know, JSX is great
https://vuejs.org/v2/guide/render-function.html#JSX
> controllers make a terrible state management tool.
I haven't used react-redux but vuex is essentially the same decoupling, and there's very little boilerplate. https://vuex.vuejs.org/en/intro.html
Not everyone knows JSX, so while that argument applies to you, it doesn't apply in general.
v-if is actually a big reason I prefer Vue. Ternary operators in JSX are pretty ugly. The other is that Vuex just feels so perfectly integrated. I've never felt Redux blends in particularly cleanly, though I certainly don't judge people that do prefer it.
All of the following is neither Javascript nor HTML:
etc. etc. etc.Especially for the else-if case - you end up with repetitive conditionals to replicate that.
Exactly! I don't know, but I've always found that disgusting. It turned me off React when I first saw it, and it still does.
Then people use it to defend react, and I'm just like 'Lolwut? Did we spend years learning that SOC is a good thing only to throw it out of the window?'
I'll be the first to admit that any Vue template quickly becomes soup as well, but at least it's only half of the soup.
Is it just younger developers that think React is the best thing since sliced bread?
You can have as much separation of concern as you like with React.
[1] https://reactjs.org/docs/jsx-in-depth.html
^ this.
It directly translates to `React.createElement`. This is also why everything inside {} is pure Javascript including things like proper `this` etc.
When working for a company with staff below me who had very basic understanding of JS (having just done HTML/CSS/JQuery, had no idea what a promise was), there was almost no learning curve with Angular. The hardest part was understanding what a component was, then learning the folder structure.
Angular's seamless use of templating, the built in support for CSS pre-processing and simplicity of uni-directional databinding had the entire team pick it up and be productive almost immediately.
Using decorators to declare inputs/outputs on dumb components is clear, readable and easy to understand.
Class based components are also very clear.
Some say TS is annoying and all power to you, but using types is optional. Personally, TS has allowed me to save on some test cases by virtue of the compiler catching those issues. Plus there is a comfort in quality intellisense.
Vue is cool, it's like a less opinionated Angular. In my opinion, it's strength is its ability to be dropped into any project, giving you client side components and databinding irrespective of your stack. However I have experienced growing pains in larger projects as a result of people over complicating simple solutions.
I am still relatively inexperienced though, and I intend to spend more time with Vue to see if I can't like it more. I'm sure all of my concerns are addressable. So far though, Angular has treated me very kindly, both in large and small scale projects.
Vue is better for onboarding people more in tune with "classic" html + js development; and that's where the advantages end as far as I'm concerned. This might be a big win for some people.
The way I reason about it is that React is simple, Vue is easy. When you take into account Vue's templating language, React's api is small in comparison. A beginner won't know how to do some common use cases reading React's docs, when Vue might have a something built-in in its templating language (e.g. slots, or the component tag for dynamic components).
Slightly annoyed with Vuex too because of its slightly leaky abstraction. You have to remember to setup the properties you mutate so the reactivity will detect a change; and also remember not use array indexes arrays cause it can't detect changes otherwise. The array index thing will be fixed in the next version when they drop support for some older IE. Using Typescript would probably help a bit here, although Typescript being useless for checking Vue templates really feels like a huge chunk of its value is wasted.
Typescript is not currently available in the official blessed boilerplate which greatly affects its uptake in the Vue community.
Anyway, if you already know React, there is zero advantage in investing time in Vue.
That and when you add JSX to mithril, the api just feels so simple and i rarely find myself checking the docs for something.
I especially like the fact that I can easily include it as a script, like Vue, and don't have to have a build chain. That really decreases complexity for smaller projects.
It's certainly common to use React in a larger application that uses a build chain, and that's the recommended approach, but it's not required.
[0] https://raw.githubusercontent.com/reactjs/reactjs.org/master...
https://github.com/styfle/react-server-example-tsx
One of the reasons I picked up React is that views could be type checked at compile time which was not possible with Handlebars a few years ago.
I believe there is work being done to the TS language service to get type checking in other template languages at some point.
[0] https://github.com/NetCoreTemplates/vue-spa
[1] https://github.com/NetFrameworkTemplates/vue-spa-netfx
Vue is also currently our most popular .NET Core 2.0 SPA Template, followed by React.
This is a positive thing imo. It's a declaration of your data schema. You can reference it to remember what kind of data you're working with. This gets rid of unproductive moments like "What was the name of this property again? Is this property an object or an array? Is it nested inside this object or that object?"