Ember.js 2018 – Plays Well With Others
This is written in response to the call for #emberjs2018 blog posts.
I am a sole proprietor developer doing work for a variety of small-to medium-sized clients and also building side projects for kicks using mostly Ruby on Rails and Ember, as well as Elixir, Elm and React.
I often have the feeling that Ember is predominantly being used by and geared towards larger corporations and not so much by freelance randos such as myself.
As a loner weirdo in the wilds of the Nova Scotian hinterlands I don’t necessarily know that this opinion provides a general glimpse into the experience of using Ember at a smaller scale, but eh, maybe…
It would be great if Ember was dead simple to integrate into other projects
It would be great if Ember was dead simple to integrate into other projects, in the same way that it’s a cinch to sprinkle a little React into Rails using webpacker and react-rails
I had heard of but avoided projects such as Backbone, Batman, Angular, et al until 2014, when I saw Brandon Hays give a talk at RailsConf. He spoke about the joy and ease of sprinkling Ember into Rails. Brandon and his talk were funny and inspiring and he seemed passionate enough about Ember that it seemed worth a look.
I took a look and decided that it was time to go beyond the javascript and jQuery spaghetti code I was writing that I knew to be very poor and unmaintainable compared with the elegant Rails backend code I was writing. Unfortunately it was around the exact same time that I started learning Ember that Ember changed dramatically.
No longer was it really easily possible to sprinkle a little Ember into a Rails project. Now it seemed the gist was that you were intended to build large monolithic applications entirely in Ember, driven by Ember Cli. So I went with that, using Ember to build some substantial new projects and I loved it.
I still have a substantial number of legacy Rails projects, and am continuing to build new projects that don’t necessarily require a single page application approach – they just need sprinkles of interactivity here and there.
And so when I need those sprinkles, I’ve felt compelled to turn to Elm or React. I love Elm, and find React very functional for these purposes – largely a less spagetti-like replacement for jquery and vanilla js.
Getting Elm and React running in a Rails project is dead simple –– with the help of Webpacker, react-rails, etc. It’s a natural for users of backend frameworks to work with a javascript library that is easy to integrate and I find it unfortunate that Ember is a pain in the ass. I have tried ember-cli-rails –– my personal experience with this project was negative – and have looked at ember-islands but on the surface it looks like more complication than I am willing to negotiate. Both of these projects may in fact be awesome and it may just be a failure on my part to use them to their best advantage –– this is just my experience.
When Glimmer came out it was being billed as a way for Ember to compete with React. I checked it out but was never really able to find a use for it. I just want something brain dead easy to integrate into a larger project.
The inability to easily work with Ember in small doses has been a constant frustration – I love Ember and know Ember well and would love the ability to choose to work with it everywhere without needing to learn Elm, React, Vue, etc.
But as it stands, I need to constantly evaluate if a new feature feels large enough to be its own Ember application and series of addons that I will need to keep updated, setup up a lightning deploy, etc etc etc –– it’s a lot of work to get up and running and in most cases it doesn’t feel worth it so I just reach for Elm or React instead, and leave Ember to the bigger projects.
It seems to me that this ease of integration into other existing frameworks and languages that people are using is likely one of the reasons that other projects have been attracting great numbers of developers and seeing widespread usage. I think that Ember’s numbers could benefit from being more available and visible in the wide community like this.
It would be great if it were easy to import other libraries into Ember
In the same way that it’s a great deal of work to integrate Ember into backend projects, it can also be unclear and difficult to integrate other libraries into Ember.
I recently for example was looking at improving the UI of a Cordova app and took another at Onsen. As Webpacker has easy support for React, Elm and Vue out of the box, so Onsen has easy support for the major libraries – but Ember is nowhere to be seen.
And often in these cases, someone will have started on an unofficial library for Ember, but it either doesn’t work, isn’t clear if it’s abandoned, or how to get it working, etc. And you can’t find any walkthroughs either, leading you to believe that maybe it’s too much of a pain to bother with.
It would be nice if it was possible to simply include other libraries easily from npm.
Ember Data is fine, but GraphQL is also awesome
I’ve read people complaining about Ember Data. I mostly think it’s fine although there have been lots of confusing things about working with it over the years. That said, I moved an entire application from Ember Data with JSON-API to GraphQL using ember apollo client and it was a very good experience that allowed me to finally and effortlessly fix a lot fof longstanding bugs and feature requests in our application. That said, I didn’t feel compelled to migrate all of my apps. They’re both pretty good. But I would love to see Ember remain open-minded about emerging new trends such as this.
Building PWAs or native apps in Ember could be better
I’ve used ember-cordova and Corber and been grateful for the great work done by Alex Blom and others to make it possible to deploy Ember apps to the App Store and Android store.
That said, Apple seems to be cracking down on Cordova, and I’ve had apps rejected seemingly by an automated code review system that wanted actual native components to be used.
I’ve been hearing a lot of hype about PWAs but literally every time I have followed what seem like straightforward instructions to get an Ember app working as a PWA I have given up in frustration without ever successfully seeing getting one working offline and feeling like a native app.
It would be interesting to have something similar to React Native and/or an easy official path towards getting PWAs working.
Errors and debugging in Ember are hell
I absolutely love developing in Ember when things are going well, but the second something goes wrong it’s an unbelievable drag to figure out why. Stack traces in Ruby on Rails instantly get to the heart of the problem pointing me to the exact line of code that I have written that’s causing an error; with Ember, I stare at the stack trace and fail to see anything of use – no reference at all to the code that I’ve written whatsoever. And in some cases I can’t even figure out how to reproduce the error.
I love the way that Elm debugs my code as I write it, and that it’s virtually impossible for a runtime error to make it into production. I recently had to write a public-facing application involving possibly a larger number of users then I am generally dealing with as well as e-commerce and had been burned by error reporting and debugging in Ember on another similar project, I opted instead this time for Elm.
I’ve heard a lot of hype about TypeScript but when I look into it I fail to grasp its great benefits. If it makes the Ember experience safer and more debuggable, more Elm-like then I’m all for it. But it needs to be easy to integrate – I attempted to integrate TypeScript into an ember app recently and gave up without ever really getting it working –– I found it baffling and was unclear even if I had got it working how it could be used to effect the sort of change that I was looking for.
Minor implementation details, meh
I don’t really care about controllers going away, they have been and continue to be just fine. Using pods is just fine – it would be nice if the official “module unification” landed to make something like pods official but a bit meh. For me these and other details are mostly irrelevant. Ember works great for me and if it changes a bit, hopefully for the better, that’s fine. That said, what others have been focusing on in these #emberjs2018 blog posts have been great and lots of good ideas. Like the great talk Jamie White gave at emberconf 2018 talking about combining better test experience with better a11y – awesome –– look forward to seeing these kinds of details continue to get better and emerge in Ember as time goers by.
I think the marketing is brilliant
It appears some are complaining about the marketing and the Tomster. I think Ember’s marketing is brilliant and probably one of the reasons I was attracted to the framework in the first place. It’s friendly, fun and approachable. I see no need to “grow up” or starting doing “mature” or more “adult” marketing. In my mind, the utterly generic marketing of most software libraries is a sign of lack of time, imagination or funds, not an indication of maturity. The friendly graphic design and illustrations are awesome, as are Zoey and the Tomster in all of their weird and wonderful incarnations.
I love Ember and hope to see it continue to evolve and thrive
Learning and using Ember has been a great boon for me, my projects and my clients. The great work done by all of the core, learning, and documentation team members as well as Leah and others on the conferences and all of the amazing work done by the larger community has been amazing and laudable. Thanks too, to all of the contributors of these blog posts –– I’ve been reading and agree with most of what everybody is writing. It seems a great democratic way to look at new ideas to keep Ember moving foward. I hope to see Ember continue to grow and thrive over the coming years and continue to stay current with emerging technologies and new ideas in web development.
I am available for Ember consulting work – get in touch to learn more.