The Rock & Roll with Ember band - Aad Versteden
04 December 2020
The "Rock & Roll with Ember band" interview series introduces readers of the similarly titled book. They tell us about how they got acquainted with the framework, how they learned it, what they use it for, and a few other questions. I hope you enjoy reading them as much as I did.
Could you introduce yourself in a few sentences?
I'm Aad Versteden, co-founder and CEO of redpencil.io. We do semantic web consultancy and try our best to keep the web an open space. Most of what we do is open source, we support standards, and we try not to rely too much on software from "Big Tech".
A lot of what we do is accidentally in gov tech, probably because they care a bit more about the sovereignty of people on the interwebs. Most of our backend work is semantic.works, which heavily pushes for Ember.js in the frontend.
Which part of the world are you from?
Belgium, Europe. It's a tiny country, most of our devs are in the northern part, some work from abroad.
When and how did your Ember journey begin? How did you learn about the framework?
Somewhere before Ember 1.0 and Ember CLI. I had a great discussion with Yoran Brondsema about frameworks and his analysis made a lot of sense at the time.
I must admit that it was a big gamble, we did not know how things would play out. I assumed the bet was safe either case, because web components were supposed to become a really big and supported thing. The assumption was that we'd be able to integrate many frameworks in the future in either case.
Turns out web components did not become a thing, and that Ember.js started paving a way for continued upgrades. It has rarely ever left us behind and it was a good choice.
How did reading the Rock & Roll with Ember book help you? Can you recall something that you learned from it?
RaRwE mostly helps me for getting new people on board. It's one of the first things they read in their introductory month. Depending on their interests, they then learn more backend stuff or (almost always) build some pet project of their own. We support them with questions (much like the Ember Discord help channel would do). Questions are asked regarding style, but so far they've always been able to find their way into building their own Ember.js app after reading the book.
RaRwE also helps me quite a bit when getting people introduced. Supporting people in their introduction to Ember.js is now limited to our own style-guides and integration with semantic.works. It's a whole lot of fun!
I only read the book after learning Ember.js ages ago. I'm not sure the topic following topic is still in the book, but there used to be a topic about publishing an addon. That has taught me to publish Ember.js addons. A whole lot of what we do in the company now is share code between applications using Ember addons. That was great.
What Ember feature/RFC/etc. are you most excited about?
There is a bunch to be mega excited about. I am sometimes afraid of the momentum the community can create and the handoff from single genius to community. Some features may not land, and I'm excited about many!
ember-animated is a bit of a missed opportunity in my book. It works great, but the community is just not involved enough. It would be great if that landed where it should rightfully be.
In terms of customers and production apps, I've been super excited about Embroider. If it could give us tree shaking, that would solve a justified comment (criticizing that piece of Ember's architecture) I see passing by from time to time.
The biggest change, even though it's not in RFC anymore, is clearly Octane. I'd say my favorite is tracked properties, but the whole approach of using native classes, native getters, decorators, modifiers, etc is an enormous step forward.
I'm also very excited about the way Ember Data moves forward. We have done some experiments which allowed us to remove proxy classes and it is a much simpler programming model to reason about, especially with computed (or tracked) properties.
Lastly, I'm very glad to see work like @use being executed. This sort of thing is a first step towards being able to make computed properties work together with asynchronous state. Although specific solutions might still change, this could have an effect similar to what ember-concurrency gave us.
Haters gonna hate and I agree when people say that the Ember community could be larger. Sometimes I feel like projects aren't able to mature because creators don't get sufficient support from the community. But oh my, there are great things around the corner and much of it is happening fast! It seems like Ember.js is a great foundation for innovators that want to have an impact.
Other than reading the book, how did you learn to “speak" Ember?
We wrote quite a few applications, and I also helped a lot of people. We sometimes had to dive into the source of Ember libraries to understand stuff in the old days. RFCs are interesting to read from time to time. The Discord channel too.
I think building applications is the easiest way overall.
Is there something you’d like to see covered or explained in more detail in the book?
- Async behaviour, combined with computed properties is an important topic to understand.
- The same goes for when to expect proxy objects (the fact that you don't always receive the same thing doesn't help, so it's important to have a solid understanding before you try to test it).
- If the topic doesn't exist anymore: how to create addons. It's very simple, but it will likely steer people towards sharing more code.
- Based on the work with @use, I think topics on integrating external libraries would be nice too.
Are there any (side-)projects that you’ve built in Ember? What is it (are they) about?
Yeah, this got out of hand quickly, with many of them having landed in production.
Chronologically, I've been involved with https://bigdataeurope.eu, where we had a few front-end apps. We also wrote software for the European Commission on these platforms. We also built a hiring site and various documentation sites on Ember.js, even some PWAs.
More recently, there's an editor built in Ember.js, at https://say-editor.com. The idea is that your documents can contain bindings to real information. You could build a meeting minutes system on top of it, which shows you the actions from the previous meeting, and in which you can create new actions for people inside of the document. You can extract them later (not 98% accuracy with Machine Learning, 100% accuracy by expressing your intention). We use it for constructing legislation, extracting information from it, and automatically filling in and submitting the necessary forms to ensure the legislation passes all legal checks. It's not fully polished, and some things should improve, but the potential is enormous. Building this sort of thing is a great challenge, and it's interesting to see where it brings us in general. It's all open source, but it has won prestigious corporate awards, too. :P
There's also an integration with SOLID which we've been working on called ember-solid-store. It's been a PoC that succeeded better than expected which is roughly an alternative to Ember Data, operating similarly to what FireBase used to do. Only this time, the data is not stored in some corporate silo but the user is in control. Super easy to set up, but do ping for docs.
Aside all these things, we build an interface through which Flemish local governments (cities and villages) communicate with the Flemish Government for all sorts of things, like subsidies and forms to ensure their legislation is valid. We also publish all of that information in a way that is machine-readable. So you can use a lot of the data as if it were a database.
We've also been able to steer the platform through which the Flemish Government makes their decisions. They use an Ember.js app for their agenda's and for finding related legislation. Happy to have had this during this COVID era :P.
Were there any challenges or stumbling blocks while you were building your app?
Ember Data is both awesome and terrible. It is a great abstraction most of the time, but suddenly receiving a proxy object, not being obvious whether that is up to date or not, and newer people doing their best to make computed properties and these promises work together. It's a challenge, both to explain, as well as to debug.
That may sound like it's a diss at Ember Data, but I don't think it should be. It seems there's a gap between promises and computed properties in that they somewhat live in separate worlds. This has been solved for the view layer, making you falsely believe that it will never be a problem. However, it will be a problem, and you have to think about it.
Same goes for bidirectional relationships and polymorphic relationships. Ember Data does a great job, but the abstractions it offers can only do so much, and that is sometimes lacking.
Discussions with Chris Thoburn at last EmberFest show that there's a solid path forward for Ember Data, and the fact that we'll have @use Resource will at least provide a mindset of thinking about async data in a more abvious way. The community is getting somewhere with this, but it's the biggest pain-point from my point-of-view.
How much time do you have to work on that project?
The amount of work is too much to do the implementation myself. I get to overview some of them, and I can dispatch even the overview of much of the development to some of the greatest colleagues you'll find.
What do you like to do in your free time?
The open source project semantic.works tries to help break the barriers of information silo's in organizations. I enjoy working on that too. Anything that pushes our world in a positive direction is fun to do.
I'm also involved in IPFSsearch, a project to allow searching across the InterPlanetary FileSystem. IPFS is a distributed network that can make websites (or similar content) addressed through P2P interactions. You could set up a NetFlix clone without a CDN. Your users are the CDN! I'm taking the lead of that organization. Current frontend of that is also written in Ember.js but that may change.
We recently started caring about food forests. An alternative way of growing crops, much more resilient to short-term weather changes (like a drought in the spring) which also captures much more CO2. You simulate the edge of a forest and can grow 100s of different species of crops on it. Interesting stuff!
The efforts of crops are (sadly for nature) offset by my interest in cars (and similar vehicles) which somehow refuses to die. When time permits, I enjoy some time on the race-track.
Automation, AI, and manufacturing (3D printing) are also things I dip my toes in from time to time. Ensuring we know what is going on in the space, and toying around with the technology. Sometimes you can even build useful stuff!
Not the activity I spend most of my time on, but time spent with the family is, as can be expected, the best time.
If people would like to follow you (or your project), where can they do so?
Hah, we're looking at various platforms to disseminate aside from the Big Tech companies. Until we find our way here is where I can be found:
Code for some of the projects I've talked about:
Is there something else you’d like to say?
Thank you for writing writing Rock & Roll with Ember, and for keeping the spirit up in the community. Also thank you for the great training sessions you've given at our company in the past. I hope this project can stick around for longer, and I hope your effects on the community will persist.
If you've read the book, and would like to give a similar interview, please drop me a line at email@example.com.
If you'd like to join the Rock & Roll with Ember band, check out the book of the same name to learn Ember (and be part of a band).Share on Twitter