Vue.js

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.

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.

So, i am preparing to adopt NativeScript.

For years my hybrid projects used Apache Cordova.

"Let's avoid to maintain two teams and double the deliver velocity".

It was good for a few years, we had those september issues, (i.e. apple broke some backward compatibility) , but for the last years, things seems to be losing the grip faster.

Last breaking changes, for instance, seems to have a workaround, however that growing feeling that simple things can not rely on so fragile webviews keeps growing faster and faster.

I've tested nativescript not only on it's "helloworld", but also on how do they respond on issues.

I got tweed support. I opened an github issue and got answers on less than 10 hours (yes i did it on another timezone and very close to a weekend). I saw the faulty docs get corrected in two days.

The bad news is i only can adopt nativescript on newer projects, since there is no budget to revamp the current solutions.

The good news is i can keep coding on Vue.js , without vou router, but that's ok. I've already exchanged vanilla html for real native app with background magic enabled, the router can be easily reproduced.

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.