I am lucky that at the Open Education Consortium, I can work with technology of my choosing. For Open Education Week site, I decided to experiment with Ember.js. It was my first production Ember app and I learned some valuable lessons.
Open Education Week site enables educators to submit their events and resources. Visitors can then browse them. I used WordPress in previous years, and it worked fine to a point. It didn’t feel right when l I wanted to create more complex browsing interfaces.
Example of that would be: Show me all resources for colleges, that are in Spanish and have the following keywords in it. WordPress can do it, but it requires a lot of different taxonomies and custom queries.
I decided to build a thin Django API layer on top of existing data.
I tried using WP REST API, but it was hard to adopt. If I wanted to do more complex lookups, I still had to write complex WP_Query lookups. So that still wouldn’t help me on server side.
Good things about developing the site with Ember.js
Tooling is great
OEW is an Ember 2.3 application, written with ember-cli. This meant that I didn’t have to fight with grunt/gulp/etc. to get it to work. It just feels right, and it gives you things like real time reloading of CSS.
Components make things easy
It’s easy to make new components in Ember, that almost behave as Web Components. One example of that is my custom OEmbed component. I could reuse both in grid view and inside interactive map popup. (Demo)
Site feels fast
Once the page loads, the only requests you have to make are to the API. My other WordPress sites load fast, but requre refresh for every click. Single page app is fast.
Community of people that hang out on Slack and IRC is incredible and helpful. I just wished that it would also extend to discussion forums. Real time nature of Slack and IRC just don’t make it easy to Google previous discussions on the same topic.
Not so good things
Site is slower to load
Redirects and prerender.io
People rename website URLs all the time. This means that my API, has to keep history of all slug renames. The problem is then – how to communicate it to Google? Google parses JS apps, but doesn’t follow redirects.
I’m currently running preprender.io to solve some of these problems. It works, but it requires extra work via meta headers.
As far as I understand, ember-data assumes that I will want to query objects by their ID. If I want to retrieve them by slug, I have to make a query and then return first item of matching results. This works, but it means that records don’t get retrieved from cache.
That is just one approach, but others did’t seem much better. When I Googled: “Ember.js query by slug”, I got a lot of different threads and discussions with varying approaches. The problem is that a lot of them are from 2013. How do I know if this is still the right approach in 2016?
It’s still early in addon ecosystem
When `ember install [addon-name]` just works, it feels magical. The problem I had is that a lot addons at this point assume good knowledge of Ember. I wish they would bundle demo applications and have more documentation. It reminds me a lot about Django’s ecosystem about 6 years ago. Then we got Read the docs and more mature plugins and things go a lot easier.
Is this site ambitious enough?
Ember’s tagline is: “A framework for creating ambitious web applications”. The ambitious part is often quoted, when people want to use Ember.js only in part. It’s rarely explained what ambitious means.
Fastboot will fix most of my problems, but it’s still a few months away. The rest of my problems should go away as the community grows.
Would I build this site again with Ember.js? I think I would, because it gives me a much better foundation than a WordPress theme.