Ember in the middle of 2019 — The good, the bad, the ugly & (hopefully?) the future of Ember web development
Well, here we go again. Way too long, brutally honest, definitely subjective, with another laundry list of suggestions. TL;DR at the end.
So, around this time last year I wrote an article, Honest look at Ember in the middle of 2018, and well, it caused quite a stir. It was long, sometimes cold and pessimistic, and in a community at the time insistent on avoiding any criticism, very unusual in its tone. It was read by thousands, clapped and shared by many, but what surprised me the most, pretty much everyone knew what I was talking about. It was good to know the problems I had weren’t just in my imagination, and the pain was real, for a lot of people.
But best of all, it helped fuel the conversation about Ember’s future, and Ember is all better for it now. It even got its own twitter conspiracy theory :), which made me chuckle, but also gave me a pause — being a kid saying Emperor is naked is never a comfortable place to be, and can have real life consequences too. Oh well. Word of warning, there will be some criticism in this article as well — but ultimately, you can only get to solutions by identifying the problems, and being open about them should always be preferable to pretending they don’t exist.
What saddened me a bit last year was that despite explicitly mentioning that no matter the criticism, there is plenty of great about Ember, some people outside the community took that article as a way to reinforce their “Ember is bad” conviction. That article wasn’t that, and this article isn’t that either. There is plenty of awesome about Ember, and there is a reason why plenty of people still love it, stick around, and work hard on fixing its shortcomings. This is a reflection on what should (and hopefully will) get better. Other frameworks have, often unfixable, shortcomings too.
Last year’s article sat unpublished for about a week, so will probably this one, but it’s already past the #EmberJS2019 deadline, and I avoided the subject for as long as I could, partially in a hope that somehow at the last moment, I will be able to write a rags to riches story of an underdog winning the game and getting the girl too. Unfortunately, this can’t be it.
Don’t get me wrong, Ember is in a much better place this year than last year, but, is it enough? Well.
Last year’s TL;DR
Last year, the article ended up in a TL;DR summarizing the changes I considered necessary for Ember to get on par with the rest of the front-end JS frameworks. I will cross out things that are done or at least somewhat close to being usable:
- fix hard problems
— f̶i̶n̶i̶s̶h̶ ̶i̶m̶p̶o̶r̶t̶s̶ ̶f̶r̶o̶m̶ ̶n̶p̶m̶, tree-shaking, code-splitting
— m̶a̶k̶e̶ ̶c̶l̶i̶ ̶r̶e̶b̶u̶i̶l̶d̶s̶ ̶f̶a̶s̶t̶e̶r̶/instant, include and s̶u̶p̶p̶o̶r̶t̶ ̶h̶o̶t̶ ̶r̶e̶l̶o̶a̶d̶i̶n̶g̶
— improve boot and render performance
— i̶m̶p̶r̶o̶v̶e̶ ̶c̶o̶d̶e̶ ̶a̶s̶s̶i̶s̶t̶a̶n̶c̶e̶ ̶a̶n̶d̶ ̶p̶r̶o̶d̶u̶c̶t̶i̶v̶i̶t̶y̶— get rid of EmberObject, nudge addon authors into writing typings, think of the ways to enable WYSIWYG
— make it easier to share single purpose components and their styles
— embrace the JS ecosystem — add Preact component manager, add/document a way to build/consume WebComponents - learning curve & documentation — refactor away controllers, settle on official path forward for mixins, switch to components-services mental model, add detailed performance section and ̶c̶o̶o̶k̶b̶o̶o̶k̶ ̶r̶e̶c̶i̶p̶e̶s̶ ̶f̶o̶r̶ ̶s̶e̶r̶v̶e̶r̶ ̶i̶n̶t̶e̶g̶r̶a̶t̶i̶o̶n̶s̶
- project management — commit to a feature or two with the most impact on community for each release, t̶e̶a̶m̶ ̶u̶p̶ and make 100% sure you deliver. Prioritize bugs better, fix serious ones quickly, and benchmark and improve on time to resolution constantly. Reduce multitasking to a minimum. Talk about your process more, review its outcomes often.
- marketing — pursue other server-side developer communities, improve website design, make Ember Observer a major part of the official website
- communication — b̶e̶t̶t̶e̶r̶ ̶c̶o̶m̶m̶u̶n̶i̶c̶a̶t̶e̶ ̶t̶h̶e̶ ̶p̶l̶a̶n̶s̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶f̶u̶t̶u̶r̶e̶, m̶a̶k̶e̶ ̶p̶r̶o̶g̶r̶e̶s̶s̶ ̶t̶r̶a̶c̶k̶i̶n̶g̶ ̶m̶o̶r̶e̶ ̶d̶i̶s̶c̶o̶v̶e̶r̶a̶b̶l̶e̶/̶p̶u̶b̶l̶i̶c̶.
The good
In the last year, couple of things went really well. First version of painless imports from npm via ember-auto-import landed pretty much instantly after the call for blog posts concluded, which was a sight long unseen in the community. ES6 object model came together nicely at a steady pace, and it’s now possible to write Ember applications in a modern JavaScript or Typescript. With Octane edition, for I think the first time, there was a proper plan, a common goal, a public way to track the progress, and Ember’s chances to make it went from “snowball in hell” to “yeah, this can actually work”. Strike teams were created, community members teamed up together and fixed several long-standing problems, like my all time least favorite Ember annoyance, rebuild & reload times (one of our smaller apps, a fairly standard website went from 10 seconds to ~5 seconds on Windows, from 7 to ~2–3 seconds in a Linux VM with memoization and hot reloading, which is fine even when saving constantly while designing templates, reducing my estimated per minute loss of productivity from 30–50% to 10–15%). Class syntax is a much needed improvement, decorators are great, documentation got better, angle bracket syntax is more likable and modern than curlies, and modifiers are awesome, high fives all around.
Ember is now clearly much closer to a modern, well managed project than it was last year, and the uptick in professionalism is palpable and brought about quite a few significant changes. Much kudos to everyone involved, the progress made is truly incredible.
But.
The bad and the ugly
Unfortunately, Octane isn’t all sunshine and roses just yet, plenty of important areas still didn’t see any improvement at all.
There doesn’t seem to be any improvements in render performance, most emberperf results seem to still be some 10–25% worse in 3.11 beta than in 2.13. Krause’s JS benchmark render performance numbers didn’t improve at all at best, regressed at worst (Ember went from 2.1x slower compared to vanillajs and inferno and ~1.5x compared to react/vue/angular6 with Ember 3.3, to 2.5x vanillajs and ~1.5–2x inferno/lit/svelte/preact/angular/vue/react) with 3.9. The culprit seems to be still the same thing, create row performance gap. Ember is not using fragments, a way to speed up DOM manipulation by 2–3x that’s supported in browsers since IE6 for some reason. Perhaps there is also a way to reduce or postpone and offload the amount of JS work needed while initializing components somehow, even at a cost of caching and higher memory usage, or by using WebWorkers or tricks like inlining or eventual consistency? Trying to render long lists with {{#each}} still locks the main thread completely for hundreds of milliseconds at a time, chunking the work or doing it asynchronously might be needed there. Thankfully, there are some experiments on these fronts lately, so, fingers crossed?
But, alright, even if it’s an extreme step, perhaps for a determined developer, render performance can be hacked around by not using Ember components in performance-heavy places anyway. What can’t be hacked around, is what brings me to my 2019 wish #1:
Bundle size
Plenty of people this year said it in their blog posts before, but, this really bears repeating and should be the Ember’s top priority this year— bundle sizes of Ember apps, with the resulting boot up times of 2 (angular without ivy) — 10–20 (lit, svelte, inferno etc.)x of the rest of JS pack, just aren’t acceptable for anything but dashboards and SaaS, and it’s severely limiting the usability of Ember at large.
One of our simpler projects, a presentation/e-commerce website with a bunch of common enough addons, is at 450K of JS compressed, with Lighthouse performance scores in low double digits, and it would take at least a man-month of work cutting features and rewriting jQuery components to get it to some 380K at best (and yes, embroider still breaks the build).
People still wonder why new developers aren’t picking up Ember. Well, this is a major part of it. Developers like fast. Users like fast, and in the age of instant gratification, if your random website your users found clicking around on Google doesn’t boot under ~5–7 seconds on their cellphone, they are gone. If they even find it that is, as Google likes fast too, and uses boot performance as a signal to rank their results, and users just won’t bother finding your awesome website on page 50 (or 5, for that matter) anyway — one of our customers almost went bankrupt after falling from #2 in their most important search query to #11 before we turned it around. Internet is a cut-throat place for businesses, and every advantage counts.
Dashboards and SaaS apps make up I don’t know, 1%, let’s say 5% of all websites? Tops. For the other 95%, 400K bundles and 15 second boot times just won’t cut it, at all.
In a strange case of developer cognitive dissonance and a modern twist on Aesop’s Fox and the Grapes fable, some people in the community even suggested that it’s ok to box Ember as a niche framework within niche market like that. Well, it isn’t. To be able to stay in the game, Ember needs to be usable for 95% of use cases, not 5%, otherwise it’s just a question of time until companies start to designate their Ember apps as legacy code and stop any investment in the ecosystem, hurting even the people that stay in the process.
There is a reason Intercom doesn’t use Ember for their widget. As far as I understand, ̶T̶w̶i̶t̶c̶h̶ ̶s̶w̶i̶t̶c̶h̶e̶d̶ ̶t̶o̶ ̶R̶e̶a̶c̶t̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶o̶f̶ ̶p̶e̶r̶f̶o̶r̶m̶a̶n̶c̶e̶ ̶t̶o̶o̶ (I’ve been corrected, seems that they switched because of hiring?), and even Netflix studios realized that in process of building a bunch of components in React I assume because of performance initially, they actually gained enough code, tooling and knowledge to use React for everything.
The thing is, companies do not like duplication. Code costs money, and duplicate code costs twice as much. Keeping two frameworks around doesn’t make much business sense, even one framework requires a lot of investment in training, hiring, tooling and processes, two is just stretching it.
Giving even the strongest supporters of Ember hard reasons to not to use it will definitely lead to increased attrition, not to mention it will most certainly stop new users from coming on board too. And ultimately, you cannot keep up with the rest of the pack without developers. After all, to quote a classic, it’s “Developers, developers, developers”, and Paved cow superhighway is a real thing.
And this problem won’t be solved in hardware either — even in 2018, cellphone manufacturers still based their mass market products on abominations like ARM Cortex A53, a 2012 architecture with compute power of a potato. And even as they get more popular, it’s actually worse with the Smart TVs, most volume TV models from e.g. Samsung or LG didn’t even bother with A53 quadcores yet, which means your websites might be getting hits from chips like these even in 2028 and beyond.
This problem can only be solved in software, and with a proper packager still MIA, Ember seems to be at least two years behind the rest of JS pack there.
What surprised me the most about 2019 blog posts so far was a passing mention of how the work on splitting Ember into real RFC 176 modules hasn’t even started yet, which means tree-shaking of the framework itself isn’t going to happen probably for years to come — even after embroider with webpack lands, as the Angular team learned the hard way with their Ivy that’s two years in the making and year behind the schedule already, it won’t be enough — in order to really shave down the framework size, you’ll have to eliminate code from inside of the modules too, and to get that bug-free is anything but trivial.
Easy wins
There are some (relatively) easy wins to be had though — ember-cli needs to be able to build separate bundles for IE11 and modern browsers at the same time, and ultimately, perhaps go the similar way Vue 3.0 will, with separate code paths for people willing to drop IE11 sooner. After all, Windows 7 support ends in January 2020, update to Windows 10 is free, IE11 on Windows 10 isn’t really a thing anymore (the blue “e” icon already points to Edge there, thankfully), and IE11’s market share is at ~1.5% of users outside the US already, which is reaching the level of a rounding error.
Liquid-fire using ember-animated instead of jQuery + Velocity could bring some 20K of savings. Using WebComponents and Preact or Inferno to render components next to Glimmer ones should really be a possibility, only with the access to more quality components jQuery can finally be dropped for good for hopefully everyone.
Bundles could be produced in a format that can better benefit from lazy parsing in V8, perhaps even BinaryAST. Btw., anyone know what happened to binary templates, did it land, will it ever land, is it documented anywhere?
Performance budgets
Ember needs to start thinking in terms of performance budgets. Current recommendation seems to be at < 170KB of initial JS, < 5 seconds on Slow 3G/Moto G4 and > 80 performance score in Lighthouse. The trouble is, with Ember+ ember-data at 150K already, with basic necessities and quality of life addons like e-concurrency, e-decorators, e-simple-auth, e-intl, various template helpers, date and time manipulation etc., you’re not going to get under 200K of JS, and that’s before you wrote a first line of code. Add e-bootstrap or e-paper, animations, bunch of useful addons, and you’re nearing 300K, still with zero lines of custom code.
Until Ember gets competitive in this regard (which probably means <100K for ember + e-data and tree-shaking/code-splitting by default), it just won’t be an option for majority of websites at all. Try to create a public list of what you can cut or replace where, 2% here, 1% there, repeat enough times, and 30% needed could be just about doable at some point. Hope there actually is a plan for this.
Ember could also bundle the apps differently. Next version of facebook.com is using Relay and GraphQL to do declarative code-splitting and data-fetching in parallel to JS parsing. Perhaps ember-data could do something similar — get a simple query language describing a mapping of URL and query parameters to findAll/findRecord/query/queryRecord calls, with components getting their model/data hook or a decorator too, and build time tooling that would coalesce data fetching calls from components into a route map, with just enough JS to be able to fire XHR requests while the rest of the bundles needed for components, helpers, services etc. still lazy-load and parse. The query language wouldn’t have to be particularly comprehensive, even 80% of data available at boot is vastly superior to zero data.
To save on JS parse time some more, perhaps ember-data model files could be turned into build time generated JSON schemas (for servers that don’t provide their own) instead.
Another helpful thing could be JSON:API and ember-data getting some version of request chaining, saving more time on round-trips.
Productivity
Plenty of people want to get rid of controllers, probably thinking that a change like that will simplify Ember enough for the newcomers to be able to pick it up more easily. And yes, it might simplify it, but, it just won’t make much of a difference. Here’s why.
The biggest problems with the learning curve and productivity of Ember are not the concepts like route or controller, or the awkwardness of dealing with query parameters, or even the object model anymore, they aren’t pretty, sure, and should be dealt with, but ultimately, these are things that can be learned. The biggest learning curve of Ember is unfortunately well hidden at first — in an endless barrage of app breaking bugs, in the amount of googling and sifting through GitHub issue comments and Discord channels for glimpses of tribal knowledge required just to get the apps to build and eventually boot. I have honestly never seen anything like that before, and I thought I’ve seen it all.
For me, it got so bad last year that I had to step away from Ember completely. Every time I encountered another weird bug, it felt like I had symptoms of early PTSD, and with the “death by a thousand rebuilds” eating away at the rest of my enthusiasm for Ember each time I had to shuffle boxes around in templates, I just couldn’t do it anymore. But I kept an eye on it, and tried to update my 3.5 app to latest beta recently.
I’m three days in, encountered some 8-10 bugs so far, and the app still doesn’t boot in production because it’s not able to find EmberObject from inside one of the core packages. So, I guess the quality is still an afterthought, then?
I mean, I get it, noone likes to fix bugs. Bug reports are often devoid of any useful information, creating reproductions is pain, and fixing them a hassle.
But for libraries, code quality is not an aspect of code, it’s THE aspect of code.
Make quality THE feature of Ember
After Octane lands, besides the bundle size and perhaps named slots and code completion working in addons and templates, imho there pretty much aren’t any major features left in Ember proper that would do anything significant to the amount of effort required to be successful with it, besides having it work as expected.
Ember really, really needs a plan to deal with the quality already — create a list of all packages required to build and boot a typical app. Aim to zero inbox the PRs first. Set a proper, measurable OKR, let’s say “we’ll lower the number of open issues across core packages by 10, 20% in the next quarter”. Write down your past velocity, estimate the number of people needed to get there, organize a strike team, a bug fixing challenge, get more junior people to create reproductions, label and prioritize the world breaking bugs first. Stop chasing the shiny objects on a horizon for a while, polish up what you have first. Last year, Ember’s main repo had some 200 open issues, after a year, it’s at 190 now. Clearly there aren’t enough resources dedicated to moving the needle on quality yet.
Otherwise, you just won’t sell newcomers on Ember with broken experiences like that, and no amount of Octane hype will be enough to convince them there. Sorry.
Update the world
One thing that went particularly well last year was the ES6 object model. The new class syntax with decorators is awesome, and having a functional code completion for the first time in apps is a breath of fresh air.
But, as I take a look at my bundles, app code is barely a third of the lines there, with the rest coming from the framework and addons, and code assistance for addon code still isn’t a thing. Very few addons added TS typings to their packages yet, there isn’t any central repo for them either, so even if they exist, people just copy/paste them around from app to app. It’s… not great.
Unfortunately, relying on authors manually updating 6000 addons on their own isn’t going to work, not unless you make it as frictionless as possible. Ember now, more than ever, needs an ember-cli-update bot for addons.
I think EmberObserver already has a system that clones all the addon projects from GitHub and runs scripts on them. Perhaps that could be a good place to start, adapting it to fork the addon repo, create a new branch, run at least an ES6 codemod for now, bump the major version to prevent any surprises, commit and post a pull request with a disclaimer about maintainers having to check the results and a git command for them to copy/paste into terminal in order to pick it up without any hassle. GitHub has their command-line client too, so, this could be as simple as a shell script, while saving the community thousands of hours of doing this manually. Waiting for everyone to do it on their own could take years instead and isn’t the way to get there.
Ember is not just Ember
There’s more to developing in Ember than just knowledge of the framework itself, and while Ember’s documentation is reasonably good at this point, ember-cli’s documentation is… well, let’s just say unhelpful.
I still remember the many sleepless nights in a debugger required just to get the basic contours of what e-cli does, and the documentation wasn’t any help at all. Addons export a JS hash, but in reality, their prototype gets merged with some package? Which hook comes from where, gets called when, what is the sequence of what e-cli does? Where should I put breakpoints while debugging builds and rebuilds? How do I get the list of addons, list of files added by an addon, how do I get project configuration, how do I add babel plugins, etc.?
Even after few years, I still feel the only way to get anywhere with ember-cli is pretty much by remembering which addon does something similar to what you want or by doing a code search on EmberObserver and copy/pasting and adapting it, and even then you’ll often find a number of contradictory, sometimes even broken examples that way. The whole experience is just, eh, especially for newcomers.
Documentation needs to feature a high level overview — create diagrams of ember-cli and all its parts, its classes, describe the relationships. List the sequence of events during build and rebuild in a pseudo code, e.g.
- read ember-cli-build.js
- get a list of addons
- instantiate each addon with package X
- for each addon call hookZ()
…
This would go a long way to explain how e-cli works, saving newcomers plenty of time and frustration in a debugger or spelunking the source code. Create a list of common tasks in addons, and add a cookbook with examples on how to do them in an officially sanctioned way.
With embroider coming, documentation should try to explain the relationship between the two—which parts will be replaced by webpack? Will we have to port all addons? Will we have to learn completely new ways to achieve the same goals, will the old way get deprecated at some point, what capabilities will be lost in the process?
How to JSON:API site appeared recently, which has examples on how to do JSON:API integrations between various servers and clients. It’s a pretty good resource for newcomers, and I think it’s done by a member of Ember community, so maybe it could get linked or republished as a part of Ember documentation as well? Warm welcome of developers coming to the front-end world from various server-side only stacks could go a long way.
Don’t do the conference-driven development
(or at least, do it twice a year, Copenhagen is a cool city too)
I’ve been asked several times about what I think about the Octane edition, and I tried to stay away from the discussion completely. But, internally, my biggest problem with the Octane wasn’t actually what was or wasn’t in it, but with the fact that instead of delivering small improvements sooner it seemed a lot as a way to shift community expectations to a day way too far into the future. And, I was about half right in my concerns — in first 6 months after the Octane announcement, besides few select initiatives, there wasn’t much going on with Ember, things were not only not shipping, but it was obvious that they are not even being worked on. That changed couple of weeks or months before the EmberConf, but the end result is that Octane still didn’t ship to this day, and trying to use it for a regular user will still be a bad experience.
I really wish the approach got different this time — choose a theme (themes) or issue each quarter, and slice and dice it until you can produce a tracking issue with small enough tasks that more individuals can pick up in parallel. Create strike teams, and dedicate a bunch of hours to it each week or month, instead of trying to hack it together last minute before a yearly conference. Best case, you’ll get more people involved and more fully shipped features out of it faster, worst case, you’ll fail fast, and you won’t confuse users for years as with routable components and module unification (2016 — ✝ 2019, R.I.P.). Don’t rely on individuals heroing the features through every time. After five years of rebuild & reload misery, it was fixed in some 2 months, by 5–6 separate people each doing a different part. Please do more of that.
Build the next level in productivity
At one interview a while back, I got asked a question — why Ember? And honestly, I struggled with the answer. Why indeed? It’s kind of like the others, but worse in many respects, can’t be the Ember’s selling point.
And in my opinion, that why should be productivity. Ember should sell itself as a productivity powerhouse — developing apps should be faster, easier and more joyful than in competing frameworks.
Companies understand productivity. Angular got from nothing to x times Ember’s usage not because of its likability or ease of use, but mostly because of top to bottom decisions — using it at scale is productive, and its team is clearly hard at work making it better. But Ember can also be pretty productive, and thanks to its syntax and magic, it definitely can win in likability over Angular too. And developers understand joy.
However, taking a look at my time with Ember, the biggest drags on productivity come from four areas — bugs, gaps in code assistance, lack of more advanced components, and — pushing pixels around in templates.
Being used to desktop RADs like Borland C++ Builder/Delphi, Visual Studio or Lotus back in the day, one thing that always amazed me about web development was just how terrible the whole experience is — things that were trivial for non-hypertext documents in MS Office in 1992 still require absurd articles like 13 ways to vertical center in 2018 now, and noone seems to even notice.
Web developers seem to take a lot of pride in a knowledge of largely superfluous HTML document formatting technologies like CSS, wasting their education, talents and creativity on chasing boxes 2 pixels to the right, no, 1 to the left, 3 from the top, instead of delivering an actual value that can have real impact on the world around them. Sure, you can get pre-made designs from designers or more junior developers, but that workflow disintegrates the minute you cut them into hbs files, and doesn’t really work in small teams or on hobby apps, where you just don’t get the benefit of someone else doing your templates for you anyway. Designing apps should be much easier. So how easy can it be?
At some point in my past, by a random chance, I got to develop applications in IBM Lotus Notes/Domino for a while. Our customers were a bunch of large multinationals, banks, telecoms, construction and engineering, automotive or medical research companies, with hundreds of thousands employees around the world.
But my favorite customer was a smallish (couple hundred employees) Swiss/Canadian/Aussie engineering company, where we got to automate their every process — CRM, project management, document management, CAD, workflows, sales, HR, QA, you name it, completely paperless, instant and custom tailored to decades worth of business experience. They designed factories, plenty of them in developing world, and it was obvious that with the amount of automation they had, and despite Swiss engineers’ salaries being pretty much double the rest of the first world countries, they were able to build whole factories cheaper and months faster than the competition. And the knock-on effect of that was immense — thousands of people found employment sooner, lifting their families up from poverty, and their products were delivered to millions of customers, transforming whole regions.
And it was all made possible by easy to create software. Lotus Notes, despite being a fairly bad email client and its retro looks, was an insanely productive development platform that integrated everything — a rock-solid NoSQL database server, Java/JavaScript/VB app server, web server, mail server, LDAP user and document rights management, clustering and offline replication. It included everything a business app could need in a single package, at it was pretty much headache-free — you could set the whole company up in about 15 minutes, start developing instantly after that, and I think I saw around three bugs in it over several years. At its peak, it was used by some 120 million people, and plenty of them started developing in it for the first time as well — I saw apps developed by electrical and mechanical engineers, IT support, project managers and interns, and they delivered real value to their companies too. It was very democratizing, and it’s estimated that 10 million apps were developed for it. To put that into perspective, Apple and Google app stores have around 2 million apps each even now.
And at the core of it was an easy-to-use GUI designer:
You created a form, dropped a few text fields, pickers or other components on it, created a bunch of computed fields using simple formulas, used a basic SQL-like query language to get the data from the server, showed a table or a document, defined a bunch of buttons and actions, and that was pretty much it. It was simple and effective, GUI or data fetching/storage were never a concern, and anyone could do it. Out of these simple building blocks you could build pretty much any complex business application you wanted, delivering incredible amounts of value in the process.
This thing spoiled me, and to this day I die just a little inside every time I have to write yet another line of pointless CSS. I’m just amazed that with all the resources thrown at the web platform, people still write HTML & CSS in a text editor the same way they did 25 years ago. What a waste of human potential.
Thankfully though, there is a light at the end of that tunnel. From design tools like Sketch or Figma, which can either use or export HTML and even React components, and editors like Pinegrow and Webflow, website builders like Wix, Squarespace, Mobirise, to tools like Framer X, which let you edit React components visually, and with the advent of utility class CSS frameworks like Tailwind or with Bootstrap 4 getting a decent enough utility class story of its own, web WYSIWYGs are now becoming not only practical, but a major time-saver, and the tides are finally turning.
And Ember, given that Handlebars is just a thin superset of HTML, is in a prime position to get a top-notch WYSIWYG story and the developer productivity boost that comes with it too.
So how could it happen in Ember? Well, probably the most fully featured desktop WYSIWYG editor I’ve seen so far is Pinegrow. It’s a NW.js app for Mac, Windows & Linux, written in JavaScript, supports SASS, LESS and various CSS frameworks including Foundation and Bootstrap 3 & 4 (Tailwind should be easy enough to add by adapting the Bootstrap 4 plugin), syncs with VS Code, Atom, IntelliJ etc., has nice GUIs for everything from layout, including flex and grid, to styling, it understands components, and especially with Bootstrap 4 utility classes, you can design pretty much the whole website without writing more than a few lines of custom CSS, and thanks to drag&dropping and seeing what you are designing instantly, at a much faster pace and in higher quality than in a text editor alone.
Its plugins are in fairly basic JS, with their API and some jQuery, which means you could make it communicate with e.g. ember-language-server or Typescript without too much trouble, so probably the only parts missing are using a Glimmer parser instead of HTML one to create and transform the HTML/component tree, a way to track and manipulate block selection, and faster (< 200-300ms) rebuilds (to get there, e-cli could for example do more smaller bundles for routes, models, components, templates etc. in development). Once it’s possible to use Typescript for code completion in hbs templates, that infrastructure could be adapted to create panels with a list of Glimmer component properties too, making Ember even easier to use in a more RAD way.
If you wanted to go fully open-source, e.g. GrapeJS seems to provide a nice enough place to start.
And, if you want to go a step further, you could get GUIs for generating API servers and declaring data fetching queries too, perhaps similar to Rails’ graphiti gem’s Vandal UI or GraphiQL, and you can have a fully flexible, Ember + JSON:API/GraphQL based low(er)-code development platform with a WYSIWYG for design and no per request costs as with the Backend-as-a-Service providers like Firebase.
Magic.
Showing off a well-integrated developer workflow like this could really turn heads and finally answer the why of Ember even for the people outside the ecosystem, not to mention save Ember’s adopters plenty of time and costs and freeing their developers to create better features with real business value instead of messing with the design, layout, CSS and data fetching/storage.
When creating software, tools really matter. WYSIWYG revolution is coming to web development, and Ember could be at the forefront of it again.
TL;DR
- improve bundle sizes — finish embroider, build separate bundles for modern browsers/IE11, have an option to cut IE11 legacy code completely, try to use lessons from other frameworks to reduce the framework weight and do declarative code-splitting and data fetching — create a simple query language used to fire data requests sooner and help lazy-load dependencies, rewrite liquid-fire without jQuery and velocity, enable/document using Preact or Inferno and WebComponents for users to be able to drop jQuery completely
- make quality THE feature of Ember—aim to zero inbox the PRs first, categorize issues by severity, and set meaningful OKRs to lower the number of issues across the packages required to build and boot the apps
- create an ember-cli-update bot and update all the addons at least with the ES6 codemod for now
- improve ember-cli documentation, create an overview of parts, a class diagram, describe the sequence of events during build and rebuild in pseudo-code, add a cookbook with the recipes for common tasks, explain the relationship between e-cli and embroider and the changes coming better, republish/link How to JSON:API
- set smaller and more easily achievable goals each quarter, and do more to split them into tasks and tracking issues that can be picked up by more people in parallel
- get the app development productivity to the next level with WYSIWYG
P.S.
Sorry for the criticism, I know it’s sometimes hard to read. It’s hard to write too, but in the end, I still believe an open discussion about problems and solutions can only be beneficial to everyone. I also still believe Ember’s community has every bit of skill needed to fix everything mentioned, but as I said before, good ideas of Ember don’t mean much without planning, discipline and proper execution. I sincerely hope this is the last year I have to write anything but praise about it, and that this is the year Ember emerges with the productivity and developer experiences no other framework comes close to. It’s entirely within reach.
