I’ve always been amazed at how much Ember can make me accomplish. I created my first SPA with its version 1.13. Since then, I deployed a few Angular and React applications. Ember remains my favorite.
😏
The all-features out of the box with the Component, Data, and Router boundaries is a fantastic thing. Moreover, ember-cli makes the build process so easy that you only have to focus on the development of your features. Even if — most of — other frameworks require configurations before shipping Web applications, their success is unquestionable compare to Ember.
I articulate my wishes within two categories:
- strategic, mostly to grow the Emberistas community
- practical, to improve the development experience
Let’s dive into the strategic ones.
An efficient website
My first concern with Ember is to win the clients, companies, and developers’ trust. People are more informed of the Web technologies landscape than ever. Hence, I struggle to explain that Ember fits more than another framework when the situation is appropriate. I struggle because I fight against beliefs. Unfortunately, I fight against the trendy-hipster-effect. Not the engineering issue.
😤
That said, I wish a modern website with consistent guidelines which promotes that Ember is a viable option.
Comparatives and benchmarks
My second concern relates the position in general of Ember within the frontend ecosystem. I can’t stand to keep reading benchmarks or comparatives of Ember and React.
It’s like comparing a tool with a factory; a brick with the Great Wall of China; a ball of wool with a Prada’s creation. That having been said, it would make sense to focus on GlimmerJS and React; or, Ember and React+React-dom+React-router+React-redux.
🙌
Ember and its community should be proud of all the contribution they have done so far in the SPA’s ecosystem. The features, the performance, the development experience, and the philosophy have inspired others (when is not plagiarized). Put into this perspective, it would convince new developers and reassure the Emberistas.
I wish features comparatives and benchmark performance with other frameworks on the website.
Ember is worldwide
My last concern is the presence of Ember in the world. The Asian and Indian markets abound of development companies and potential contributors. Things there are changing blazingly fast. What do they do? Guess, Angular, React, or Vue. They would use Ember for their projects if they knew that it exists. They hardly know about it.
That said, I wish a multilingual website — including the “get started”.
Now, I want to address a few practical issues.
Lazyloading source code
For general public web applications, I choose Angular. For only one reason: its lazyloading module system. Even for mobile-oriented web applications, I pick Angular for the same reason. The size of the applications’ source is a critical issue. Especially for large ones and low data bandwidth usage. Ember has to provide a Just Work™ answer.
Embroider is promising. I have to tell you that I am sooo excited about this initiative! That said, my wish is to get lazyloaded source code applications based on routes, add-ons, or whatever.
Scoped (S)CSS
If you are a utils CSS oriented integrator, the paragraph below won’t interest you.
Set apart the pure abstracted components, does anyone create components without styling it? No, it can’t be. Styling an application is an essential task throughout the development process. It directly contributes to the success of projects. Design web applications with a scope-style system should require no effort.
Even if ember-css-modules is a great add-on, I think developers should rely on Ember only. My wish is to get a native scoped-style system, which Just Works™.
Static pages rendering
Ember might be an attractive option for simple websites which follow the ideas of the JAMstack. Ember-cli should provide a way to generate all the routes. Unfortunately, prember requires developers to configure the routes to render.
I wish we can render all the routes in static files with no configuration using one command line such as:
ember render -env production
Full support of Typescript
Typescript is inevitable when talking about robust web applications development. It may engage the developers’ support.
I wish developers of add-ons and Ember applications use by default Typescript with no configuration on ember-cli.
New Ember developers have to assimilate many concepts before developing with ease. The documentation may introduce each layer distinctly, additionally, to a whole.
Documentation on fundamental layers
Ember is the genius composition of libraries*. It ties them up altogether to empowers each underlying layer of SPAs:
- Component GlimmerJS
- Templating Handlebars for the templating
- Router Router.js
- State management Ember-data
- Build pipeline Ember-cli
I wish the documentation answers what Ember is made of? to let developers the opportunity to implement all or part of the stack to their projects.
(*) If that was not wholly true at the beginning. Now, certain parts of Ember have become independent libraries. Also, Ember Octane goes one step further.
That’s all for me. Thanks to the core team and the community for participating in this great adventure.
Let’s make Ember better, all together.
Oldest comments (0)