Feed powered byStream Blue Logo Copy 5
AngularJS

AngularJS

Application and Data / Languages & Frameworks / Javascript MVC Frameworks

Decision at The New York Times about Kafka, Node.js, GraphQL, Apollo, React, PHP, MySQL, AngularJS

Avatar of nsrockwell
CTO at NY Times
KafkaKafka
Node.jsNode.js
GraphQLGraphQL
ApolloApollo
ReactReact
PHPPHP
MySQLMySQL
AngularJSAngularJS

When I joined NYT there was already broad dissatisfaction with the LAMP (AngularJS MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

17 upvotes2 comments42.4K views

Decision at Stitch about ES6, JavaScript, CoffeeScript, React, AngularJS

Avatar of jakestein
CEO at Stitch
ES6ES6
JavaScriptJavaScript
CoffeeScriptCoffeeScript
ReactReact
AngularJSAngularJS

Stitch鈥檚 frontend is used to configure data sources and destinations and monitor the status of each. Although we have been using AngularJS since its early days, we recently introduced React components into our front end, which many of our developers find easier to work with. We started using CoffeeScript when it was one of the few options for a more expressive alternative to vanilla JavaScript, but today we opt to instead write new code in ES6, which we feel is a more mature alternative.

16 upvotes2 comments7.5K 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.

10 upvotes17.5K views

Decision at Algolia about MobX, Redux.js, AngularJS, React

Avatar of proudlygeek
MobXMobX
Redux.jsRedux.js
AngularJSAngularJS
ReactReact

We started rebuilding our dashboard components using React from AngularJS over 3 years ago and, in order to have predictable client-side state management we introduced Redux.js inside our stack because of the popularity it gained inside the JavaScript community; that said, the number of lines of codes needed to implement even the simplest form was unnecessarily high, from a simple form to a more complex component like our team management page.

By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.

8 upvotes2 comments6.1K views

Decision about Apache Cordova, redux-saga, React Native, AngularJS, Redux.js, React, JavascriptMvcFrameworks

Avatar of aharonamir
Apache CordovaApache Cordova
redux-sagaredux-saga
React NativeReact Native
AngularJSAngularJS
Redux.jsRedux.js
ReactReact
#JavascriptMvcFrameworks

We had contemplated a long time which #JavascriptMvcFrameworks to use, React and React Native vs AngularJS and Apache Cordova in both web and mobile. Eventually we chose react over angular since it was quicker to learn, less code for simple apps and quicker integration of third party javascript modules. for the full MVC we added Redux.js for state management and redux-saga for async calls and logic. since we also have mobile app along with the web, we can shere logic and model between web and mobile.

7 upvotes10.7K 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 upvotes42.1K 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鈥檛 scale nicely. Features clash with each other. Isolation doesn鈥檛 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 upvotes2.7K views

Decision about Spring-Boot, AngularJS, Apache Maven, Vault, GitLab, Sonatype Nexus, SonarQube, OpenShift, Docker, DeploymentWorkflow

Avatar of go-faustino
Spring-BootSpring-Boot
AngularJSAngularJS
Apache MavenApache Maven
VaultVault
GitLabGitLab
Sonatype NexusSonatype Nexus
SonarQubeSonarQube
OpenShiftOpenShift
DockerDocker
#DeploymentWorkflow

We use Docker for our #DeploymentWorkflow along with OpenShift SonarQube Sonatype Nexus GitLab Vault Apache Maven AngularJS Spring-Boot

1 upvote10.1K views