Backbone.js vs Vue.js: What are the differences?
Backbone.js and Vue.js are both open source tools. It seems that Vue.js with 143K GitHub stars and 20.7K forks on GitHub has more adoption than Backbone.js with 27.5K GitHub stars and 5.7K GitHub forks.
9GAG, Sellsuki, and esa are some of the popular companies that use Vue.js, whereas Backbone.js is used by Uber Technologies, Pinterest, and reddit. Vue.js has a broader approval, being mentioned in 849 company stacks & 1219 developers stacks; compared to Backbone.js, which is listed in 1066 company stacks and 218 developer stacks.
It was easier to find people who've worked on React than Vue. Angular did not have this problem, but seemed way too bloated compared to React. Angular also brings in restrictions working within their MVC framework. React on the other hand only handles the view/rendering part and rest of the control is left to the developers. React has a very active community, support and has lots of ready-to-use plugins/libraries available.
The key takeaways:
Both frameworks can do the job quite well for us. This might be true for the majority of utility web apps being built out there as well, so there was no "wrong" decision here.
Vue is often cited as easier to learn and code on. But only in case your engineers never worked with either Vue or React and start learning them from scratch. In our case, we knew we'll be hiring engineers who already have experience in the framework we'll select - so it was not a big argument for Vue.
We're building our engineering team in Ukraine and realised we have 3(!) times more engineers with React experience on the market than having Vue experience.
Mobile - React Native, despite being a different framework, still shares a lot with React and it's just easier for React developers to start using React Native in days.
The strongest points for our decision:
React community is larger, means more/faster answers to your questions and existing components.
Way more experienced React engineers on the market.
React + React Native is a great combo if you're building web and mobile clients of the same app.
Svelte 3 is exacly what I'm looking for that Vue is not made for.
It has a iterable dom just like angular but very low overhead.
This is going to be used with the application.
for old/ lite devices . ie. * android tv, * micro linux, * possibly text based web browser for ascci and/or linux framebuffer * android go devices * android One devices
Our whole Vue.js frontend stack (incl. SSR) consists of the following tools:
- Vue Styleguidist as our style guide and pool of developed Vue.js components
- Vuetify as Material Component Framework (for fast app development)
- TypeScript as programming language
- Apollo / GraphQL (incl. GraphiQL) for data access layer (https://apollo.vuejs.org/)
- ESLint, TSLint and Prettier for coding style and code analyzes
- Jest as testing framework
- Google Fonts and Font Awesome for typography and icon toolkit
- NativeScript-Vue for mobile development
The main reason we have chosen Vue.js over React and AngularJS is related to the following artifacts:
- Empowered HTML. Vue.js has many similar approaches with Angular. This helps to optimize HTML blocks handling with the use of different components.
- Detailed documentation. Vue.js has very good documentation which can fasten learning curve for developers.
- Adaptability. It provides a rapid switching period from other frameworks. It has similarities with Angular and React in terms of design and architecture.
- Awesome integration. Vue.js can be used for both building single-page applications and more difficult web interfaces of apps. Smaller interactive parts can be easily integrated into the existing infrastructure with no negative effect on the entire system.
- Large scaling. Vue.js can help to develop pretty large reusable templates.
- Tiny size. Vue.js weights around 20KB keeping its speed and flexibility. It allows reaching much better performance in comparison to other frameworks.
I've an eCommerce platform building using Laravel, MySQL and jQuery. It's working good and if anyone become interested, I just deploy the entire source cod e in environment / Hosting. This is not a good model of course. Because everyone ask for small or large amount of change and I had to do this. Imagine when there will be 100 separate deploy and I had to manage 100 separate source. So How do I make my system architecture so that I'll have a core / base source code. To make any any change / update on specific deployment, it will be theme / plugin / extension based . Also if I introduce an API layer then I could handle the Web, Mobile App and POS as well ? Is the API should be part of source code or a individual single API and all the deployment will use that API ?
When deciding on a front end framework to build my bitcoin faucet project, I knew I needed something battle hardened, dependedable, but also feature filled and ready to go out of the box.
While I've written some smaller apps with ng2+, I've never gone full tilt with it so I knew there were still some things to learn, and most importantly: how to do them properly, such as proper component architecture and breaking old habbits from ng1.
I didn't opt for React in this case, simply due to the need to stack more and more things on top of it to do what I'd need it to do. I wanted a framework that was going to take over routing and execution of complex UI controls, and keep items outside of a component's scope updated and react to events. This framework needed a comprehensive event emission system, data acquisition and handling, bi-directional data binding, state, and a series of things that you'd need to install separately for React to match up to what's already in the box with Angular.
I opted to stick to Angular instead of Vue for the fact that Angular also already has it's entire build system ready to go and comprehensivly built to deliver the tiniest version of it's deliverable. I was hosting this thing in a google cloud instance, so I needed to make sure the app stayed as small as possible, and could automatically trim out the cruft. This is where Angular's built in Tree Shaking took precedence for me.
Vue is more than capable of handling everything I'd need, and it was something I took serious considerion of. For instance, Vue poweres Cointiply, another bitcoin faucet application that's highly reactive and high componentized just like I wanted.
But I'd still need to learn Vue, I'd still need to configure it's build system, and I still wanted to use SCSS and TypeScript.
So Angular it was. ng8 is a great platform for building very complex user interfaces, and has many of the problems you'd inevitably face integrating a user interface to an application already figured out, and complete with a best practice recommendation.
React and Vue, given enough time and energy, are super capable platforms. No one can deny that. Angular's "A-Z Batteries Included" approach to the whole development process is what made it especially enticing this time.
When first used Angular, the documentation was horrible and also the construct of Angular super academic and hard to learn (back in 2014). When evaluating React it was way easier getting stated even though its html in js (jsx) approach was very different. After some time we really started to like the co-location and component based model. If you architect well, you will have a component completely in one file including js/html/css.
We solely focus on one technology for frontend development. The reason for that is, that offering customers excellent services we need to be up to date on all developments of the framework but also its community and vast amount of packages. Reading blogs, newsletters, podcasts and so on. You will realistically only be able to be really good at one, so thats for us: React!
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is Backbone.js?
What is Vue.js?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions