Alternatives to Ampersand.js logo

Alternatives to Ampersand.js

AngularJS, Vue.js, Backbone.js, Angular 2, and Ember.js are the most popular alternatives and competitors to Ampersand.js.
15
19
+ 1
31

What is Ampersand.js and what are its top alternatives?

We <3 Backbone.js at &yet. It’s brilliantly simple and solves many common problems in developing clientside applications. But we missed the focused simplicity of tiny modules in node-land. We wanted something similar in style and philosophy, but that fully embraced tiny modules, npm, and browserify. Ampersand.js is a well-defined approach to combining (get it?) a series of intentionally tiny modules.
Ampersand.js is a tool in the Javascript MVC Frameworks category of a tech stack.
Ampersand.js is an open source tool with 816 GitHub stars and 51 GitHub forks. Here’s a link to Ampersand.js's open source repository on GitHub

Ampersand.js alternatives & related posts

AngularJS logo

AngularJS

22.5K
14.9K
5.2K
22.5K
14.9K
+ 1
5.2K
Superheroic JavaScript MVW Framework
AngularJS logo
AngularJS
VS
Ampersand.js logo
Ampersand.js

related AngularJS posts

Jake Stein
Jake Stein
CEO at Stitch · | 15 upvotes · 152.6K views
atStitchStitch
AngularJS
AngularJS
React
React
CoffeeScript
CoffeeScript
JavaScript
JavaScript
ES6
ES6

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.

See more
Arik Fraimovich
Arik Fraimovich
AngularJS
AngularJS
Angular 2
Angular 2
React
React
Vue.js
Vue.js

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.

See more

related Vue.js posts

Jeyabalaji Subramanian
Jeyabalaji Subramanian
CTO at FundsCorner · | 21 upvotes · 203.8K views
atFundsCornerFundsCorner
JavaScript
JavaScript
HTML5
HTML5
Vue.js
Vue.js
Vuetify
Vuetify
Amazon Cognito
Amazon Cognito

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

See more
Tim Nolet
Tim Nolet
Founder, Engineer & Dishwasher at Checkly · | 20 upvotes · 523.6K views
atChecklyHQChecklyHQ
Heroku
Heroku
Docker
Docker
GitHub
GitHub
Node.js
Node.js
hapi
hapi
Vue.js
Vue.js
AWS Lambda
AWS Lambda
Amazon S3
Amazon S3
PostgreSQL
PostgreSQL
Knex.js
Knex.js
vuex
vuex

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.

See more
Backbone.js logo

Backbone.js

4.8K
1.4K
674
4.8K
1.4K
+ 1
674
Give your JS App some Backbone with Models, Views, Collections, and Events
Backbone.js logo
Backbone.js
VS
Ampersand.js logo
Ampersand.js

related Backbone.js posts

Dan Robinson
Dan Robinson
at Heap, Inc. · | 18 upvotes · 179.6K views
atHeapHeap
jQuery
jQuery
Backbone.js
Backbone.js
Marionette
Marionette
TypeScript
TypeScript
React
React
MobX
MobX
#JavascriptUiLibraries
#Libraries
#JavascriptMvcFrameworks
#TemplatingLanguagesExtensions

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

See more
Marcos Iglesias
Marcos Iglesias
Sr. Software Engineer at Eventbrite · | 13 upvotes · 103.2K views
atEventbrite-0Eventbrite-0
Backbone.js
Backbone.js
Marionette
Marionette
Flux
Flux
Redux
Redux
React
React

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.

See more

related Angular 2 posts

Arik Fraimovich
Arik Fraimovich
AngularJS
AngularJS
Angular 2
Angular 2
React
React
Vue.js
Vue.js

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.

See more
Heroku
Heroku
Netlify
Netlify
Vue.js
Vue.js
Angular 2
Angular 2
React
React
ExpressJS
ExpressJS
vuex
vuex
Puppeteer
Puppeteer
ASP.NET
ASP.NET
#Heroku
#Seo

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.

See more

related Aurelia posts

Adam Rabinovitch
Adam Rabinovitch
Global Technical Recruiting Lead & Engineering Evangelist at Beamery · | 5 upvotes · 97.4K views
atBeameryBeamery
AngularJS
AngularJS
React
React
Angular 2
Angular 2
Vue.js
Vue.js
Aurelia
Aurelia
Polymer
Polymer
#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.

See more
KnockoutJS logo

KnockoutJS

159
124
0
159
124
+ 1
0
Knockout makes it easier to create rich, responsive UIs with JavaScript
    Be the first to leave a pro
    KnockoutJS logo
    KnockoutJS
    VS
    Ampersand.js logo
    Ampersand.js
    Marionette logo

    Marionette

    140
    98
    79
    140
    98
    + 1
    79
    Backbone application code with robust views and architecture solutions
    Marionette logo
    Marionette
    VS
    Ampersand.js logo
    Ampersand.js

    related Marionette posts

    Dan Robinson
    Dan Robinson
    at Heap, Inc. · | 18 upvotes · 179.6K views
    atHeapHeap
    jQuery
    jQuery
    Backbone.js
    Backbone.js
    Marionette
    Marionette
    TypeScript
    TypeScript
    React
    React
    MobX
    MobX
    #JavascriptUiLibraries
    #Libraries
    #JavascriptMvcFrameworks
    #TemplatingLanguagesExtensions

    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

    See more
    Marcos Iglesias
    Marcos Iglesias
    Sr. Software Engineer at Eventbrite · | 13 upvotes · 103.2K views
    atEventbrite-0Eventbrite-0
    Backbone.js
    Backbone.js
    Marionette
    Marionette
    Flux
    Flux
    Redux
    Redux
    React
    React

    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.

    See more