Feed powered byStream Blue Logo Copy 5Created with Sketch.
Vue.js

Vue.js

Application and Data / Libraries / Javascript UI Libraries

Decision at Codecov about Jest, vuex, Python, Vue.js

Avatar of hootener
CTO at Codecov ·
JestJest
vuexvuex
PythonPython
Vue.jsVue.js

We chose Vue.js at Codecov to replace a front end that was based mostly on server side rendered Python templates, and was getting fairly long in the tooth. The move to Vue.js allowed us to take a more component driven approach to our front end, providing greater flexibility and reuse when creating new pages and refactoring old ones. Another bonus was how easily we could integrate Axios with VueJS for making AJAX calls within Vue.js components and their associated vuex stores. We were also able to easily integrate Vue.js with the Jest testing framework, which allowed to provide test coverage for a front end where none previously existed.

The move to Vue.js has allowed us to be more agile in our front end development by further decoupling our front end from our back end. Additionally, by fully embracing a component-driven approach, we're able to more easily isolate and test functionality, leading to a more readible, maintainable, and extensible front end codebase.

10 upvotes·3.4K views

Decision at Codecov about Visual Studio Code, Vue.js, CoffeeScript, JavaScript, TypeScript

Avatar of hootener
CTO at Codecov ·
Visual Studio CodeVisual Studio Code
Vue.jsVue.js
CoffeeScriptCoffeeScript
JavaScriptJavaScript
TypeScriptTypeScript

We chose TypeScript at Codecov when undergoing a recent rewrite of a legacy front end. Our previous front end was a mishmash of vanilla JavaScript and CoffeeScript , and was expanded upon haphazardly as the need arose. Without a unifying set of paradigms and patterns, the CoffeeScript and JavaScript setup was proving hard to maintain and expand upon by an engineering team. During a move to Vue.js , we decided to also make the move to TypeScript. Integrating TypeScript and Vue.js is fairly well understood at this point, so the setup wasn't all that difficult, and we felt that the benefits of incorporating TypeScript would outweigh the required time to set it up and get our engineering team up to speed.

Choosing to add TypeScript has given us one more layer to rely on to help enforce code quality, good standards, and best practices within our engineering organization. One of the biggest benefits for us as an engineering team has been how well our IDEs and editors (e.g., Visual Studio Code ) integrate with and understand TypeScript . This allows developers to catch many more errors at development time instead of relying on run time. The end result is safer (from a type perspective) code and a more efficient coding experience that helps to catch and remove errors with less developer effort.

9 upvotes·21.4K views

Decision at Redash about Vue.js, React, Angular 2, AngularJS

Avatar of arikfr
Vue.jsVue.js
ReactReact
Angular 2Angular 2
AngularJSAngularJS

When Redash was created 5 years ago we chose AngularJS as our frontend framework, but as AngularJS was replaced by Angular 2 we had to make a new choice. We decided that we won't migrate to Angular, but to either React or Vue.js. Eventually we decided to migrate to React for the following reasons:

  1. Many in our community are already using React internally and will be able to contribute.
  2. Using react2angular we can do the migration gradually over time instead of having to invest in a big rewrite while halting feature development.

So far the gradual strategy pays off and in the last 3 major releases we already shipped React code in the Angular.js application.

8 upvotes·11.2K views

Decision at Loanlink Gmbh about HTML5, Vue.js, Google Drive, MailChimp, Zapier, Trello, GitHub, React, Node.js, .NET, AngularJS, Rails

Avatar of bananatron
Product Engineer at Loanlink.de ·
HTML5HTML5
Vue.jsVue.js
Google DriveGoogle Drive
MailChimpMailChimp
ZapierZapier
TrelloTrello
GitHubGitHub
ReactReact
Node.jsNode.js
.NET.NET
AngularJSAngularJS
RailsRails

When starting a new company and building a new product w/ limited engineering we chose to optimize for expertise and rapid development, landing on Rails API, w/ AngularJS on the front.

The reality is that we're building a CRUD app, so we considered going w/ vanilla Rails MVC to optimize velocity early on (it may not be sexy, but it gets the job done). Instead, we opted to split the codebase to allow for a richer front-end experience, focus on skill specificity when hiring, and give us the flexibility to be consumed by multiple clients in the future.

We also considered .NET core or Node.js for the API layer, and React on the front-end, but our experiences dealing with mature Node APIs and the rapid-fire changes that comes with state management in React-land put us off, given our level of experience with those tools.

We're using GitHub and Trello to track issues and projects, and a plethora of other tools to help the operational team, like Zapier, MailChimp, Google Drive with some basic Vue.js & HTML5 apps for smaller internal-facing web projects.

6 upvotes·11.6K views

Decision about Yarn, Redux.js, React, jQuery, vuex, Vue.js, MongoDB, Redis, PostgreSQL, Sidekiq, Rails, Font-awesome, Bulma.io

Avatar of cyrusstoller
YarnYarn
Redux.jsRedux.js
ReactReact
jQueryjQuery
vuexvuex
Vue.jsVue.js
MongoDBMongoDB
RedisRedis
PostgreSQLPostgreSQL
SidekiqSidekiq
RailsRails
#Font-awesome
#Bulma.io

I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.

On the front-end I'm using Vue.js and vuex in combination with #Turbolinks. In effect, I want to render most pages on the server side without key interactions being managed by Vue.js . This is the first project I'm working on where I've explicitly decided not to include jQuery . I have found React and Redux.js more confusing to setup. I appreciate the opinionated approach from the Vue.js community and that things just work together the way that I'd expect. To manage my javascript dependencies, I'm using Yarn .

For CSS frameworks, I'm using #Bulma.io. I really appreciate it's minimal nature and that there are no hard javascript dependencies. And to add a little spice, I'm using #font-awesome.

5 upvotes·1.2K views

Decision about nginx, Webpack, Vue.js, Framework7, npm, MySQL, Ubuntu, Node.js, Lenovo, HapiJS, Framework7, Plaid

Avatar of mbplautz
nginxnginx
WebpackWebpack
Vue.jsVue.js
Framework7Framework7
npmnpm
MySQLMySQL
UbuntuUbuntu
Node.jsNode.js
#Lenovo
#HapiJS
#Framework7
#Plaid

I just designed, developed, and deployed my own budgeting app, dailybudget.cc, which allows me to automate my budgeting the way I have always done it, in a way that I could never fully capture with other budgeting apps, such as Mint, EveryDollar, or YNAB. I spent 4 years from the time I first had the idea to the time I actually sat down to design it and start development. During this time I evaluated many other budgeting app solutions, and had even architected a prototype that I never ended up using. But boy, have technologies come much further in 4 years.

Though my first prototype used Java and Tomcat, I completely abandoned those 4 years later in favor of Node.js technologies, which I have found are equally as stable, more flexible (for better or for worse), and capable of significantly more rapid development. Since what I have deployed now is in beta and is primarily for limited user use, I favored rapid development over slower development where I would write more automated unit tests. I chose to build the app as a HTML5 web application (rather than native iOS or Android, for now), and I used a separated API backend/Web frontend model. My target platform for use with the app is mobile handheld touch devices, though it can work on any laptop or desktop with a touchscreen. Given these design targets, many of the technologies I chose were because of familiarity with them as well as a strong online community, and some technologies I chose that I had to learn anew, because they appeared to fit my needs.

My entire app runs on a #lenovo IdeaCentre desktop on my home network, on which I have installed Ubuntu 18.04. Ubuntu is something I have switched to after a long time of use and familiarity with RedHat Enterprise Linux and CentOS, because the online support for Ubuntu is now tremendous, and there is so much documentation and examples online of how to configure and use Ubuntu; not to mention I have not been thrilled with the direction new releases of CentOS. Ubuntu is also a good environment for development - it is so easy to follow the many online examples. Lastly, I may migrate my app and configuration to Amazon AWS, which also uses Ubuntu for its EC2 Linux VMs, so having Ubuntu now is helpful for that prospect.

The API backend uses Node.js, with #HapiJS as the API server framework and MySQL as my persistence database. HapiJS is something I have had familiarity with and is just a phenomenal framework to plug into and configure, especially if you use it for a route-based API. #Mysql has a great online community. I could've used PostgreSQL too, but I am more familiar with MySQL. Also, if I migrate to Amazon AWS, Amazon's RDS uses MySQL. I use npm as a one-stop-shop package manager and environment manager.

The Web frontend uses a combination of Framework7 and Vue.js. I cannot evangelize Framework7 enough! It is a fantasic tool by @nolimits4web (GitHub) that is really easy to use, really well thought out, and really performant. Framework7 simulates the native iOS or Android (Google Material) experiences, all using HTML5 constructs (HTML+CSS+JS). Vue.js is another very fantastic binding and frontend framework which has a good online community and is well documented and easy to use. I had to choose between VueJS and ReactJS, and ultimately chose VueJS over ReactJS because it seemed to favor more rapid development with less ramp-up time, whereas I understood ReactJS to be more of an enterprise level framework (though still good for smaller projects like mine). When using Framework7 with VueJS, NodeJS is used along with Webpack to transpile my code into browser-friendly JavaScript, HTML, etc. Webpack was nice to use because it has a hot-deploy development mode to enable rapid development without me having stop, recompile, and start my server (this was one of several reasons against using Java with Tomcat). I had no familiarity with Framework7, VueJS, or Webpack prior to this project.

I use nginx as my web server and have the API running behind a reverse proxy, and all of the web frontent content hosted as static content.

I use the plaid API to sync my bank transactions to my database. This is another fantastic framework (though not free beyond development use) that it turns out is extremely easy to use for the complex job that it solves.

4 upvotes·1.7K views

Decision at Beamery about Polymer, Aurelia, Vue.js, Angular 2, React, AngularJS, Hiring

Avatar of adamrabinovitch
Senior Technical Recruiter & Engineering Evangelist at Beamery ·
PolymerPolymer
AureliaAurelia
Vue.jsVue.js
Angular 2Angular 2
ReactReact
AngularJSAngularJS
#Hiring

At Beamery we had a large, AngularJS app, built over several years. Our clients were happy, but we were not. We had several problems: Building new features was slow. AngularJS doesn’t scale nicely. Features clash with each other. Isolation doesn’t come as standard, you have to work hard to keep features separate. It takes time to get it right. #Hiring was hard, for all the reasons listed above. The app was slower than it needed to be because AngularJS was never built for speed. We wanted to render half a million contacts, and Angular was fighting us all the way.

As time went by it become harder to find developers who would willingly choose AngularJS over React Angular 2 , Vue.js , Aurelia or Polymer .

So we faced a choice. We could throw it all away and start again, we could upgrade to Angular 5, or the awesome option - we could use micro frontends. We chose the awesome option.

2 upvotes·328 views

Decision at mkdev about Vue.js

Avatar of Fodoj
Cloud and DevOps Consultant ·
Vue.jsVue.js

We chose Vue.js as our new and primary JavaScript framework . We had spaghetti of jQuery code before and we needed something very simple to use, something that won't force us to start using too many new tools and something we could write small independent components with ease. Vue.js ticked all these boxes.

2 upvotes·141 views

Decision about Vue.js

Avatar of fraigo
Vue.jsVue.js

I worked with both Vue.js and React. Some of the advantages I found using Vue over React:

  • The component model can be developed separating domain-specific aspects (component markup (template), logic (Javascript/typescript/babel), and style (css). In React, using JSX, sometimes you are mixing this concepts in the same code, and difficult for a designer, for example, to work on components without having JS/JSX experience.
  • I found Vue better suitable to create component-based and static content web pages without compromising SEO content optimization. In React, basically I need to start with an empty-content page dinamically created.
  • Vue Property declaration is very straightforward with types and defaults. Also in React has some improvements, for example, propagating properties inside child components
  • About additional tools, both Vue and React has the most commonly used tools (front-end frameworks, state management, resource loading)
2 upvotes·139 views

Decision at car2go about Vue.js, React, Angular 2, Web, Frontend

Avatar of codeofsumit
Head of Developer Relations at car2go ·
Vue.jsVue.js
ReactReact
Angular 2Angular 2
#Web
#Frontend

How car2go Chose a #frontend Framework between Angular 2 , React and Vue.js. We needed a #web framework that we switch to for all our current and future projects, internally and customer facing. This is the process how we went about it and how we decided.

1 upvote·198 views