Alternatives to Ampersand.js

Stitch’s 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.

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.

At FundsCorner, when we set out to pick up the front-end tech stack (around Dec 2017), we drove our decision based on the following considerations:

(1) We were clear that we will NOT have a hybrid app. We will start with Responsive Web & once there is traction, we will rollout our Android App. However, we wanted to ensure that the users have a consistent experience on both the Web & the App. So, the front-end framework must also have a material design component library which we can choose from.

(2) Before joining FundsCorner as a CTO, I had already worked with Angular. I enjoyed working with Angular, but I felt that I must choose something that will provide us with the fastest time from Concept to Reality.

(3) I am strong proponent of segregating HTML & JavaScript. I.e. I was not for writing or generating HTML through JavaScript. Because, this will mean that the Front-end developers I have to hire will always be very strong on JavaScript alongside HTML5 & CSS. I was looking for a Framework that was on JavaScript but not HEAVY on JavaScript.

(3) The first iteration of the web app was to be done by myself. But I was clear that when someone takes up the mantle, they will be able to come up the curve fast.

In the end, Vue.js and Vuetify satisfied all the above criteria with aplomb! When I did our first POC on Vue.js I could not believe that front-end development could be this fast. The documentation was par excellence and all the required essentials that come along with the Framework (viz. Routing, Store, Validations) etc. were available from the same community! It was also a breeze to integrate with other JavaScript libraries (such as Amazon Cognito).

By picking Vuetify, we were able to provide a consistent UI experience between our Web App and Native App, besides making the UI development ultra blazing fast!

In the end, we were able to rollout our Web App in record 6 weeks (that included the end to end Loan Origination flow, Loans management system & Customer engagement module). www.jeyabalaji.com

Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

Enough biz talk, onto tech. The challenges were:

• Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
• Update API and back end services to handle and enforce plan limits.
• Update the UI to kindly state plan limits are in effect on some part of the UI.
• Update the pricing page to reflect all changes.
• Keep the actual processing backend, storage and API's as untouched as possible.

In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
2. The Vue.js frontend reads these from the vuex store on login.
3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

Hope this helps anyone building out their SaaS and is in a similar situation.

The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.

Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.

#JavascriptUiLibraries #Libraries #JavascriptMvcFrameworks #TemplatingLanguagesExtensions

We are in the middle of a change of the stack on the front end. So we used Backbone.js with Marionette. Then we also created our own implementation of a Flux kind of flow. We call it eb-flux. We have worked with Marionette for a long time. Then at some point we start evolving and end up having a kind of Redux.js-style architecture, but with Marionette.

But then maybe one and a half years ago, we started moving into React and that's why we created the Eventbrite design system. It's a really nice project that probably could be open sourced. It's a library of components for our React components.

With the help of that library, we are building our new stack with React and sometimes Redux when it's necessary.

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.

I found Heroku to be a great option to get ExpressJS up and running with very little hustle. The free tier is great, but I'd recommend to set up a cronjob to visit your site every few minutes so that the server stays awake. Netlify was the option to host the front-end because doing the server side rendering on #Heroku would have taken a little more time than I'd like to. For the moment pre-rendering the app with prerender-spa-plugin is enough to help with #seo. Puppeteer was my choice over other options because it made it easier to scrape websites made on ASP.NET which is what I needed in this case. And Vue.js is my top choice at the moment because it's really beginner friendly and it has a lot of the features I like about Angular 2 and React. vuex is a must in most of the app I build.

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.

The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.

Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.

#JavascriptUiLibraries #Libraries #JavascriptMvcFrameworks #TemplatingLanguagesExtensions

We are in the middle of a change of the stack on the front end. So we used Backbone.js with Marionette. Then we also created our own implementation of a Flux kind of flow. We call it eb-flux. We have worked with Marionette for a long time. Then at some point we start evolving and end up having a kind of Redux.js-style architecture, but with Marionette.

But then maybe one and a half years ago, we started moving into React and that's why we created the Eventbrite design system. It's a really nice project that probably could be open sourced. It's a library of components for our React components.

With the help of that library, we are building our new stack with React and sometimes Redux when it's necessary.