Skip to main content

Mobomo webinars-now on demand! | learn more.

mobomo management

We are excited to announce expansion and growth of Mobomo's executive team:

Ken Fang, formerly CEO, will now serve as President of the company. Since joining in 2010, Ken has led Mobomo from a small startup to a company with over $5M in annual revenue, a more than tripled staff, consecutively high rankings by Inc. 5000, over 120 product launches, and an increasingly glowing client roster. In Ken's new role, he will be focused on high-level company strategy, corporate partnerships, and sales.

Brian Lacey will be assuming Ken's responsibilities as CEO. Brian joined Mobomo in 2011 as a Project Manager, and because of his passion for UX design, was quickly promoted to Creative Director. Within a short period of time, Brian was soon appointed COO, and under his tenure, Mobomo successfully built out well-defined design, development, and quality assurance capabilities. He also spearheaded the founding of the Buenos Aires office and helped acquire Exceptual Technologies, among other operational expansions.

Jesse Vizcaino will be assuming Brian's responsibilities as COO. In 2012, Jesse launched his Mobomo career as a Project Manager and quickly rose to Director. In his various roles, he has been instrumental in guiding Mobomo’s strategic direction, streamlining operations, and signing flagship customers such as the District of Columbia Retirement Board and the National Library of Medicine.

Please join us in congratulating Ken, Brian, and Jesse: we’re excited to see the great things they’ll accomplish in their new roles, and wish them all the best.

Categories
Author

workfromhome
Sticking to a schedule, writing out your daily goals, and keeping yourself motivated are crucial to a healthy and effective remote position. Here are a few tips from a seasoned remote veteran:

1. Sticky Notes

Write down your tasks. The physical act of writing down, crossing out, and throwing away a sticky note is amazing! Scientifically speaking, this is more than just writing on a piece of paper. It’s a way to calm your mind, focus on the task at hand, and see through a project vs. aimlessly wandering through your day.

2. Breaks

Know that busy does not equate to productivity. If you’re feeling burned out at 10 am after an hour of research - TAKE A BREAK. Go for a walk, grab a coffee, or give someone a call. Step back from your computer and let your mind recharge. Some of the best musicians work in 90 min intervals and are consistent about 15-20 minute breaks.

3. Routine

Stick to a schedule. Wake up at the same time, exercise, eat breakfast, journal, and most importantly SHOWER. Just because you work from home doesn’t mean you should roll out of bed and go straight to working. Developing the habit of routine will help you work at optimal times and have a sense of accomplishment at the end of the day.

4. #standup updates

This is a strategy @Intridea uses for most projects and day to day operations. It’s a way of building accountability and awareness with our peers in regards to individual to-do lists. Working remotely can often feel like a silo and keeping everyone informed of your “work list” not only helps you to stay on task, but keeps others from derailing you with “emergency, last minute” requests.

5. Plan the Night Before

Create tomorrow’s to-do list the night before; it’s at the forefront of your mind and writing them down will keep you from dwelling on them throughout the night. Empty your brain and save valuable morning time by utilizing those last 15 minutes of your day to set tomorrow up for success.

6. Know When to Stop

Fight the urge to check work email after a certain time. Make it a point to shut down and be present with your family and friends. Traditional employees have the luxury of separating home life from work life, you however will need to be intentional with your personal time and designated “work” hours.

7. Social Media fasting

Block out times in the day for social media and honor your schedule. Facebook and Twitter can easily destroy productivity and suck hours away from your day! Know yourself and know when you work best - avoid these distractors and use them as rewards for getting stuff done vs. wasting your valuable time and energy on it.

Got any remote working hacks? Share them with us on Twitter!

Categories
Author

shink
If you’re reasonably up-to-date with front-end app development then there’s a good chance you’ve heard the buzz flying around about ECMAScript 6. For those unfamiliar, ECMAScript 6, also known as Harmony, is the next major version of JavaScript programming language. In this post, I’ll utilize new ECMAScript 6 features to reduce and improve readability of code in a sample AngularJS application.

Our sample application is a simple baseball card auction app that serves as a platform for users to sell rather valuable baseball cards and consists of three Controllers (BaseballCardsCtrl, BaseModalCtrl, and ConfirmModalCtrl) and three Services (UserService, CardService, and NotificationService).

Block-scoped bindings and arrow functions

The very first thing our application needs to do is fetch the current user’s profile, so we’ll start by taking a look at the getUserInfo function of our UserService which is responsible for retrieving the user’s information.

function getUserInfo() {     if (user) {         return $q.when(user);     } else {         let handleSuccess = (response) => {             user = response.data;              return user;         };          let handleError = (error) => {             NotificationService.logError('Unable to retrieve user info', error);              return null;         };          return $http.get('/dist/data/get_user_info_response.json').then(handleSuccess, handleError);     } } 

This function uses two of the new features of ECMAScript 6, namely block-scoped bindings, and arrow, or lambda functions. The handleSuccess and handleError functions above are declared using the let keyword, which restricts them to only being accessible by code in the same block; in this case, the else block of our if-else statement. This increases the overall readability of our code by moving variable or function declarations and assignments into the block where they’re intended to be used. Both handlers make use of arrow functions which provide a shorthand, expressive syntax for defining functions. In addition to providing a more compact syntax for defining functions, arrow functions also lexically bind the “this” keyword value, eliminating the need to manually bind object context when registering event handlers and such.

Generators and paused execution

Next, let’s take a look at an excerpt from our BaseballCardsCtrl that uses the UserService’s getUserInfo and CardService’s getCards methods to retrieve and store a reference to the user’s profile and baseball card data.

var it;  initialize();  function initialize() {     vm.notifications = NotificationService.getNotifications();      it = fetchData();      it.next(); }  function *fetchData() {     vm.user = yield getUserInfo();      vm.cards = yield getCards(vm.user); }  function getUserInfo() {     UserService.getUserInfo().then((user) => { it.next(user); }); }  function getCards(user) {     CardService.getCards(user).then((cards) => { it.next(cards); }); } 

The most interesting thing to note about the above code is the *fetchData function declaration. The function name is prefixed with an asterisk which is a new, special naming convention that results in the function returning a Generator object, another new feature of ECMAScript 6.

Generators are special Iterators that can pause their execution when the yield keyword is encountered. The ability to pause function execution allows us to control the order of asynchronous operations without need to use a series of nested callbacks. In our initialize function above, we store a reference to the Generator object on which we immediately invoke it’s next method to instruct *fetchData to begin executing its function body. The *fetchData function calls getUserInfo then pauses due to the presence of the yield keyword. The getUserInfo function is responsible for registering a callback function to be executed once the user’s information is retrieved from the server. Once the user’s information is retrieved, the callback invokes the Generator’s next function with the user data, which is returned by the first yield statement in *fetchData. The *fetchData function then releases the pause allowing execution to continue and the getCards function to be invoked with the necessary user data.

Object destructuring and string templates

Now that our application has been wired up to retrieve the necessary user and baseball card data, it needs a way to allow our user to actually sell his cards. The following snippet is from our CardService.

function sellCard(card, index) {     return $http.get('/dist/data/sell_card_response.json').then(handleSuccess, handleError);      function handleError(error) {         NotificationService.logError('Unable to sell card', error);          return null;     }      function handleSuccess() {         var { year, firstName, lastName, value } = card,             dollars = $filter('currency')(value);          cards.splice(index, 1);          UserService.updateBalance(value);          NotificationService.logSuccess(`Sold ${year} ${firstName} ${lastName} for ${dollars}`);          return card;     } } 

The majority of this code looks similar to what you’ve seen in other AngularJS applications with one exception, the first line within the nested handleSuccess method. This particular line uses what’s called Object Destructuring, another one of our new ECMAScript 6 features. Object Destructuring provides a shorthand syntax for declaring one or more variables with their values being initialized as property values of a target object. This is only a very basic example of how one might use Object Destructuring to consolidate multiple variable declarations into a single statement; it does support more complex mappings to nested object properties as well.

Another difference you may have noticed is our use of a string template to build a success message to be used as a “successful sale” notification. Traditionally, this would have been accomplished by concatenating multiple string literals with variables, but now we can achieve the same result using much more concise, readable syntax using variable interpolation with template strings.

Classes and prototypal inheritance

One requirement of our application is to prompt our users to confirm that they would like to proceed, after clicking a button to sell a particular baseball card. For this demo we use the UI-Bootstrap modal for our confirmation prompt. In real world applications there is often the need to utilize many different modals that implement a common subset of functions to handle repetitive tasks such as closing the modal when the user clicks a Cancel button. Implementing these functions for each modal leads to redundant code. Fortunately, ECMAScript 6 introduces a new way to approach prototypal inheritance in JavaScript using a more concise, readable syntax.

function BaseModalCtrl($modalInstance) {     'use strict';      var vm = this;      vm.dismiss = $modalInstance.dismiss;     vm.close = $modalInstance.close; } 

First we define an ordinary constructor function that creates dismiss and close members that reference the $modalInstance service’s dismiss and close methods. Admittedly, there’s nothing new or interesting to see here but in our next code excerpt, we will see how we can easily extend this functionality when we create our ConfirmModalCtrl.

class ConfirmModalCtrl extends BaseModalCtrl {     constructor(data, $modalInstance) {         super($modalInstance);          this.data = data;     } } 

While this feature isn't a new concept in JavaScript language, it does provide syntactic sugar, and achieve prototypal inheritance using a more concise, intuitive syntax. ECMAScript 6 classes and inheritance offer a standardized way to define JavaScript class constructors, public and private members, and make superclass methods calls. Of course, this is all possible today using native ECMAScript 5 code, but the syntax is not as elegant or intuitive. We now have an easy, readable way to extend functionality and eliminate code redundancy in our JavaScript classes.

Structure through modules

Lastly, let’s learn how to import various application components and register them with AngularJS. Historically, JavaScript has lacked a native way to structure applications and manage component dependencies. However while AngularJS does have its own dependency injection mechanism, it does not support importing external dependencies and requires components be available from within the current scope before registering with Angular.

ECMAScript aims to provide a native, standardized way to handle importing external dependencies with the introduction of modules. Lets take a look at how we can utilize the new module syntax to import external file dependencies and register our different components with Angular.

 import BaseballCardsCtrl from './controllers/baseball_cards.ctrl.js';      import ConfirmModalCtrl from './controllers/confirm_modal.ctrl.js';      import UserService from './services/user.service.js';      import CardService from './services/card.service.js';      import NotificationService from './services/notification.service.js';   angular.module('demo', ['ui.bootstrap'])   .controller('ConfirmModalCtrl', ConfirmModalCtrl)   .controller('BaseballCardsCtrl', BaseballCardsCtrl)   .service('UserService', UserService)   .service('CardService', CardService)   .service('NotificationService', NotificationService); 

As you can see in our above example, ECMAScript 6 modules introduce the new import keyword, allowing you to reference application components defined in external files. Here, we import each of our AngularJS application components (BaseballCardsCtrl, ConfirmModalCtrl, UserService, CardService, and NotificationService) and register them with our demo application. Each of our components uses an export statement, another new keyword in ECMAScript 6, to selectively make internal components available for import and use in other files..

 export default NotificationService;    function NotificationService($log, $timeout) {   ...   } 

The import and export statements support different syntax giving you flexibility over how components are referenced throughout your application. Note: We’ve only used the most basic, as it fulfills our application’s current needs.

Conclusion

ECMAScript 6 is still in draft mode and its specification isn’t expected to be officially published until later this year. For this reason, modern browsers currently have varying or incomplete support for many of the new language features. Fortunately though, there are quite a few tools to integrate support for ECMAScript 6 into your workflows and translate the code to ECMAScript 5 compatible syntax. As the release of the new ECMAScript 6 specification approaches, its new features are being integrated into more and more applications.

JavaScript is one of the most popular and widely used programming languages today; it’s not going anywhere any time soon and as it continues to evolve, so should our applications to harness it’s full potential and expressiveness. Our sample application uses one subset of the new features available in ECMAScript 6; there’s a lot more to it than what we’ve seen in this short example. For more complete information on ECMAScript 6 and how to integrate support for it in your workflow, check out the following resources.

Application

 

 

Resources

 

 

Categories
Author

working from home
Working remote is great; autonomy, flexibility, work/life balance, you name it! However, while the benefits severely outweigh the costs, working from home does present its own set of challenges. Below are the findings of a veteran to remote working.

1. You get to work from home, but you shouldn’t always.

Working remote is the freedom to work from anywhere. Often times we get fixated on remote equaling home office, but it so much more than that! Perhaps you enjoy working out in the sun, or maybe a little structure at a co-working space is your thing? Whatever it is - the point is you get to choose and that’s a beautiful thing.

Some of my best connections, ideas, and productivity have occurred outside the home office, so just because you can work from your kitchen, doesn’t mean you always should.

2. Autonomy is amazing, but also requires intentional discipline.

When describing my job, I often equate it to being your own boss w/o the usual entrepreneurial stressors. However, while there’s tons of freedom, with that freedom comes great responsibility (Spiderman plug). Sticking to a schedule, writing out your daily goals, and keeping yourself motivated are crucial to a healthy and effective work life. If you’re someone who thrives under constant supervision, be wary of remote jobs, this may not be for you. Self motivation and discipline are key to success in this arena.

3. Effective communication is a requirement, not a nice to have.

With the subtraction of body language, tone of voice, and physical proximity, the written word, emoticons, and timely responses become crucial. This is why utilizing GIFs, emoticons, and #status updates are important. If you think you’re being redundant, you’re probably doing just the right amount. Never underestimate the importance of emotional intelligence in the virtual world.
Think you can hack it? Intridea is hiring! :) Learn more about our AngularJS Engineer position.

Categories
Author

As a UX designer, improving the end user experience is my passion. When an interface or interaction seems confusing, I often find myself asking “What would I tell the user if I was there?” And immediately picture myself as a bystander, brainstorming every possible solution.

When you eat and breath this on a daily basis, it can quickly spill into the analog world. Suddenly, you have a heightened awareness of places and things where designers have built with the user in mind. And it’s in those instances, you can almost sense the designer looking over your shoulder, giving you a helping hand.

My first observation of this was the gas pump. We’ve all experienced “gas cap confusion” or the internal debate as to which side that dang cap is on! No matter how long you’ve been driving your car, this situation occurs more often than we’d like to admit. If you know where to look though, there’s a bit of user experience design making life a little easier. For years auto manufacturers have included a tiny arrow next to the gas pump icon indicating which side it's on.

GasPump

It’s such a simple touch. Just a tiny little arrow. But if you know about it, it can save you a world of frustration when heading to the pump.

Which got me thinking, are there other ways to simplify daily life via user experience design? And so began my pursuit and practice of Guerilla UX.

When we moved into our house, a point of frequent confusion was our garage doors, or more specifically the control panels that opened them. There’s a garage door on the left and another on the right, but with the panels stacked vertically (poor user interface design) it was impossible to remember! With a bit of Guerilla UX though, determining which pad opened which door was quickly resolved. Arrows now clearly indicate the side the control panels open.

GarageDoor

Another place with some added UX love is my printer. It’s a common hurdle; which side of the paper will the printer print on? And it’s of special concern when printing on special paper or making labels! Pre-UX, I’d always make a mark at the bottom of a plain sheet of paper and print a test page to avoid wasted time and paper. My Guerilla solution? A simple label with an arrow showing which direction to load the paper and a smiley face to indicate the top as well as what side it will print on. Tada!

Printer

These are just a few places I’ve added Guerilla UX to my daily life, but I have a feeling other designers (and non-designers) may use a bit of Guerilla UX to make their lives easier too.

Got some good examples? Tweet them to us with the hashtag #GuerillaUX and we’ll share the best ones!

Categories
Author

tidal
With "The ruler’s back” kicking off one of Jay-Z's greatest albums to date and the recent (re)launch of his streaming service Tidal, my hopes of a Jay-Z disruption were extremely high.

With claims to revolutionize streaming and pay artists what they deserve, Tidal depicted the utopian ideal of edgy design, quality, and fairness. I was pumped to check it out, not merely as an H.O.V. fan, but as a UX/UI junkie craving to experience music streaming in a new way. With creds for shaping one of the most popular music genres, you'd think Tidal would bleed the Jay-Z innovation as well. Yet, what I discovered was anything but revolutionary.


The interface is the same grid layout we’ve all come to know (and love) from our other player, cough Spotify. Not that there is a problem with the way big “S” handles their layout, in my opinion, it does some pretty amazing things, especially in regards with how it handles an incredible library of content.

Tidal
I just expected more with Tidal, especially coming from J-HOVA, someone who’s built his career by straying from the beaten path. I wanted something that would blow my mind, something that made me NEED Tidal, but it just wasn’t there.

There were glimpses of what Tidal could have been, with slick transitions that make sense to a user and don’t remove them from the moment.


There were literally two instances when this level of detail was applied. And the look of the app is super sharp, black on black with pops of neon blue that scream for you to click.

Tidal2
Also, there’s no denying that Tidal has a very trendy look, but it’s the details that make a truly immersive and engaging experience. Unfortunately, with Tidal's design inconsistencies and jarring page transitions, it was difficult to convince myself I needed this new platform for music streaming. And with a price tag of $19.99 for premium membership, Tidal, missed the boat (pun intended) on this user.

Tidal 3
Let me clarify though, this is in no way a put down to the team of incredible designers who obviously spent countless nights away from their families. This is merely my take on a, now, very traditional service from someone who has made a name for themselves by rising above, not floating amongst his peers.

What are your thoughts? Would you make the switch from Spotify to Tidal? Let us know.

Categories
Tags
Author

AngularJS editor

When it comes to learning your editor, most of us avoid it like the plague. It’s time consuming, opinions run rampant, and quite frankly, we’ve got better things to do!

Yet this avoidance isn't effective (and we know it). Simple tasks such as performing “find and replace” become much more difficult when we don't understand how our editor operates...

So why do we still refuse to eat our vegetables? For a few reasons:

It’s overwhelming.

Reviewing an editor, like emacs (or vim, or sublime text) is overwhelming. Not only can the editor accomplish many tasks, but there are multiple ways of doing them! For instance, when performing a “find and replace” on a file in emacs, you can use a regular expression (now you have two problems) or a keyboard macro. All these options can quickly lead you down a rabbit hole and wondering (three hours later) “what did I just do with my time?!”

Getting sidetracked by editor holy wars

When asking a co-worker for advice, if that co-worker doesn't use your editor of choice the discussion can devolve into: "Emacs is awful. You should use Vim and do it this way." Then instead of learning your editor, the conversation continues into the merits of one editor versus another, when both could do the job adequately. Avoid this at all costs.

Deadlines

We have work to do. When working on a bugfix or a feature with a tight deadline, you can't afford to spend time learning your editor. But then, not learning your editor makes your text editing less efficient, which makes development work take longer than it should. Soooo...

A Better Approach

Despite all these variables though, learning your editor is worth it. You just have to get strategic. Here’s my suggestion: while doing your everyday work, keep a notepad with an ongoing “need to learn” list for your editor. Then, when you find yourself wanting to perform a particular task (search across project files) and don't know how to do it, you can come back to it later vs. stopping everything to figure it out right then and there.

Then once a week, for thirty minutes, take one item on your list and look up how do it. For the coming week, keep in your mind (or a post-it note on your monitor) how to perform this task in your editor, and use it when necessary. This will help you remember the task and how to do it. Next week, you can cross off another item on your list.

This approach requires a small time commitment each week and avoids going down the rabbit hole of configuring your editor during your normal work day.

Categories
Author

angular

This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea's support by Michael Bleigh!

If you follow the front-end world even a little bit, you've probably seen the internet explode over the massively incompatible rewrite that is AngularJS 2.0. Some think the Angular team has lost their marbles. I'm not so sure.

Angular is dominating the story for modern front-end frameworks right now. Even if it's not your personal favorite, you have to admire its meteoric rise. It's a rare case of a library achieving massive adoption from both the startup and enterprise set in a very short timeframe (it took Rails years to get buy-in from bigger businesses). The Angular team is sitting on top of the world, and what do they decide to do? Rewrite the whole thing from scratch.

Advice Dog

Are. They. Insane? Rewrites-as-new-versions have horror stories right out in the open! Python 3.0 was released nearly six years ago and still has a puny fraction of code being written for it. Enterprise developers have only just convinced their bosses to let them build with modern web tech, and now they have to sell them on either a massive rewrite of existing code or an 18-month support death clock. The hubris of the Angular team is unmatched since the times of Marie Antoinette!

Disapproving Zoidberg

Except, that's not what's really going on. The Angular team isn't squandering their community goodwill out of sheer capriciousness. Instead they're doing something risky: they're pro-actively disrupting their own product before it's rendered irrelevant by external competition.

But Michael, I hear you thinking, you just talked about how dominant AngularJS is. Shouldn't they be taking steps to reinforce their leading position rather than putting the whole project in jeopardy?

That's certainly an approach they could take, but I believe it would ultimately lead to Angular falling by the wayside two to three years from now.

The Innovator's Dilemma

An oft-referenced issue in the tech world is the Innovator's Dilemma, as described in a 1997 book by Clayton Christensen. Wikipedia summarizes it thusly: "successful companies can put too much emphasis on customers' current needs, and fail to adopt new technology or business models that will meet customers' unstated or future needs...such companies will eventually fall behind."

I'll admit that I hadn't been following the progress of the Angular 2.0 design docs very closely. I had heard with interest about the new persistence layer, but hadn't done much other investigating. Today I spent a bit of time perusing some of the content, and the real purpose of the rewrite started to make sense to me.

AngularJS 2.0 is a concerted effort to make sure that Angular remains relevant in the coming front-end world dominated by Web Components.

Sea Change Is Coming

I've written before about how Web Components are revolutionary. I strongly believe that in a few years they will become the dominant paradigm for front-end development. Web Components are not, however, in direct competition with modern front-end frameworks like Angular, Ember, or React. Instead, they are a new set of foundational technologies that will enable radically different and more powerful ways of building applications in the browser.

How is this related to Angular 2.0? The evidence is plain. As I browse through the design docs, I see at least six that reference Web Components directly or allude to related subjects. The Angular team is taking everything they've learned about building an application framework and building a brand new one for the Web Components world.

This is a brave and risky decision, but one that I think has a greater chance to protect Angular's market leadership than threaten it. There is not (yet) an accepted set of best practices for using Web Components to build applications. Polymer works at a lower level than an application framework; in fact, it's quite likely that application frameworks will emerge that are built on top of Polymer.

If Angular 2.0 arrives on the scene as the first comprehensive application framework for Web Components, and it's also good at that job, it could see massive adoption, and not just from the existing Angular userbase.

What's Next?

There's no doubt that the recent firestorm will tarnish Angular's reputation a bit. Someone who is researching which framework to use today might see the uproar and decide to turn elsewhere. Open source projects are just as vulnerable to brand perception as companies, and I think the Angular team needs to get out in front of it. Firmly establish the basis and need for change while reassuring developers that 1.X users won't be abandoned wholesale. Acknowledge that incompatibility is a massive pain and demonstrate awesome new stuff that makes the pain worth it.

It's an exciting time to be building apps in the browser, but it's also a turbulent one. Angular has done a great job of introducing a huge audience to sophisticated front-end development, but the last couple years are just a warm-up act to the true front-end revolution. Angular 2.0 seems a bit crazy now. Looking at the bigger picture, however, it might just be crazy like a fox.

Update: Two Roads Diverged

Since I finished writing this post, two interesting and relevant bits of content have been published. Tom Dale wrote about The Road To Ember 2.0. The Ember team is taking a gradual, migration-focused approach to integrating new technologies like Web Components, DOM-based templating, and other new tech. They call this "Stability Without Stagnation." Henrik Joretag of Ampersand wrote to Optimize for change. It's the only constant about how they are taking the "lots of little modules" instead of an all-in framework approach.

These are both smart, valid, and potentially wildly successful approaches. The fact that there are different teams of smart people building software to make the front-end better, and that those teams have different and directly conflicting philosophies is fantastic.

Maintaining large, popular open source projects is really damn hard. It's even harder when that project is a framework, because they are so deeply intertwined with users' application code. If you move forward gradually, you risk stagnation. If you move forward in great leaps, you risk leaving behind those who don't have the time and energy to leap with you. Like most things, it's not a question of good and bad, it's a question of risk and reward, of tradeoffs.

It seems we're all cursed to live in interesting times.

Categories
Author

work_fam_parents_baby

There are few things more exciting than witnessing a client’s success, and today Mobomo is very excited. Our client, Pacify Health, has just landed $1.1 million in funding! Pacify is a startup which seeks to connect new parents with pediatric professionals (nurses, dietitians, and lactation consultants) through an on-demand, 24/7 videoconferencing platform.

The app will be a portal for only the best service providers, and available on a very affordable subscription basis. And, parents can rest knowing that they're not only connected to highly vetted professionals at an affordable rate, but all of their (and their child’s) private information is highly secured.

This week, investors gave their stamp of approval: Pacify received its million (plus) dollar funding from D.C. accelerator, Acceleprise, as well as a number of area angel investors. The official app will launch in the beginning of April, rolling out to D.C., Maryland, and Virginia to start.

We’re proud to have built the Pacify app which helped in their fundraising, and—as a company passionate about mobile health—excited to see this product take off. Congrats Pacify! Cheers to this success and many, many more.

Categories
Author

web components This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea's support by Michael Bleigh!

The next release of Polymer, 0.8, is going to be a doozy. It's the first release on the "heading towards production" track and it's going to have some pretty massive differences from previous versions. So what exactly is new, and what's changing?

Note: This data was gathered primarily from reading the Polymer 0.8 Primer which is very, very extensive. I'm just hitting the highlights. Also note that any of this could change before the final release is cut.

A Tale of Three Polymers

Three Polymigos

One of the biggest changes in 0.8 is that there is no longer a single Polymer library. Instead, it's been broken into the three "layers" of polymer-micro, polymer-mini, and polymer. Why the change?

Remember, Polymer is really just a layer on top of the Web Components standards. Web Components are meant to be inter-operable with each other regardless of things like which framework was used to build them. Creating lighter-weight versions of Polymer makes it an easier choice for authors of reusable components by being less of an install burden. So which library should you use when?

  • polymer-micro has only a bare layer of sugar on top of the raw DOM APIs and a few niceties. You don't get any DOM template stamping facilities, so this is really meant for reusable elements with little to no DOM interaction (e.g. core-ajax).
  • polymer-mini layers some DOM control on top of micro and lets you do template stamping (but not template binding). Also gives you access to <content> and the new lightDOM and localDOM properties.
  • polymer is the closest thing to 0.5 (but still quite a bit different). It adds on attribute and property observation, template data binding, layout attributes, and more. This is what you're going to want to use if you're building a Polymer application.

Things You Can't Do Anymore

When you first look at 0.8 you may be a bit surprised. There's actually many things from 0.5 that are gone, vanished, kaput. It all has to do with production readiness. Polymer 0.8 is built to be lean, mean, and a foundation for shipping production code. Some of the more expensive (computationally and/or filesize-wise) features have been nixed. Watch the Polymer State of the Union talk for more detail there.

  • Elements can't inherit from custom elements anymore, only native. It's marked as a todo, but it's unclear if it's a before-0.8-launches todo.
  • Template binding is substantially less powerful than it was in Polymer 0.5, as is property observation. Everything's more explicit, and more is expected to happen in JS vs declared in templates.
  • Polymer will no longer ship with a spec-complete Shadow DOM polyfill. This was one of the biggest performance bottlenecks in non-Chrome browsers. The new polyfill implementation will be "Shady DOM" (details TBD).
  • Property observation does a bit less magic, you'll have to manually debounce some things.

Things That Are Different

In addition to removing some of the heavier features, there are also lots of structural changes to how you build custom elements. Here's a non-comprehensive list:

  • <polymer-element> is gone. Now you use the Polymer JS function to register your element, and the new dom-module element to specify templates.
  • You use the is property to declare the element name in a Polymer registration, e.g. Polymer({is: 'my-element'}).
  • Attribute bindings now work based on dash-case instead of camel-case (i.e. <my-element first-name="{{name}}"> binds to the firstName property. I am super happy about this, camel-case attributes are hideous.
  • You should now use the lightDOM and localDOM APIs to manipulate element DOM so that they are maintained properly.

Here, Bite Down on This

Hold on to your butts.

I'm not going to lie, if you're building stuff with Polymer the transition to 0.8 is going to hurt, bad. There's very little that won't need to be rewritten significantly (if not from scratch). That being said, this is a totally necessary transition.

As Matt McNulty said in his Polymer State of the Union, Polymer started as an experiment, and with 0.8 that experiment is over. It's time for Polymer to transition from a fun future-facing toy that we can dream about into a serious, performance-oriented tool we can use to ship real code.

By focusing on performance and footprint, the Polymer team is laying a practical foundation upon which much can be built. And yes, the changes are pretty drastic, but they're throwing them at us all at once. The plan is for the API to change minimally between 0.8 and 1.0, so (fingers crossed) this will be the biggest rewrite you ever have to do for Polymer.

Lingering Questions

I've been drinking the Web Components Kool-Aid since Polymer was first announced at Google I/O in 2013. The encapsulation and composability of custom elements is revolutionary for web apps. As we start looking at the road to production-ready Web Components, however, I still have a few questions:

  1. How will module loading shake out? With Mozilla backing away from HTML Imports and ES6 gaining popularity, it seems like there's a growing rift in how to do this properly. This is a key issue that needs to be sorted out; you shouldn't need a build step to do basic module loading for a web app.
  2. The DOM is big and unwieldy. Can we incorporate some of the gains of Virtual DOM tech into Polymer and/or the Web Components specs themselves? The concept of "Local DOM" or "Shadow DOM" gives us a clean encapsulation point, maybe soon we can get some of the benefits of React and its kin.
  3. When are Apple and Microsoft going to get fully on board with Web Components? The true promise of Polymer can't be realized until we have native browser support for the standards in all browsers.

Questions aside, I'm excited for Polymer 0.8 and we will continue to champion Web Components here at Divshot. Latest estimates put 0.8 landing sometime in March; I can't wait!

Categories
Author
Subscribe to General