Challenges with ember
There are several challenges with ember moving forward. However, we are just evaluating alternatives and whether it will be worth continuing with it after upgradng to latest and patching fixes or change it with other, more modular and lightweight UI library/framework.
Before mentioning the problems, I'd like to inform that currently there are no good alternatives to ember data which is state of the art state management and data fetching solution for JSONAPI. Even though we don't have many problems with JSONAPI that we won't have with other solutions like GraphQL, we have to evaluate its limitations, unpopularity, lack of maintainence and libraries along with it. Lack of tooling for JSONAPI for other frameworks should also be seen as a potential problem in future as compared to other popular API patterns. Hence, if we switch to a different API format, ember data does not remain the best way to load and manage state, and we have more framework agnostic solutions like apollo client with us, which also work on mobile clients like Android and iOS.
However, that is a separate discussion, and for this one, we'll assume that JSONAPI is the way we are moving forward, since anyway GraphQL solutions in python are not great, even though they are better than flask-rest-jsonapi which we are curently using. Making ember data best in class solution to deal. Alas, I think that's the only thing ember has going for itself.
Note: At any point, we should not move forward with replacing ember unless we have every use case's alternative as good as it is in ember or better under current scenario.
Not as good alternatives:
- Orbit.js - Orchestrate your data
- Vuex ORM | Vuex ORM
- GitHub - redux-json-api/redux-json-api: Redux actions, action creators and reducers to make life with JSON APIs a breeze.
Challenges
Not being one of the top 3 frameworks
Today resume driven development is a thing. Angular, React or Vue are top frameworks with most developers and hence,
- also have most tooling and support.
- Issues get fixed faster as they have more sponsors and comapnies backing them.
Even if issues get fixed in core ember, they pile up in 3rd party packages where they haven't been solved in years - Packages get deprecated or rarely updated as even the people who worked on them move to other popular frameworks
- Plugins are not so straightforward that we can run our own versions of them or implement them in custom way
It is also difficult to learn. It has much steeper learning curve than even react. And most people who come across open event frontend have to learn it for the first time
Way of doing things
Ember reinvents everything
And hence, curbs transferrable knowledge, and also has become very large.
Browser APIs
From events (which it now deprecated), to runtime and tick system and other components which browser already has. Which makes it feel like a VM running on top of browser from which we can run our code. We don't run ember, ember runs us.
Web as a platform is not going anywhere. React, Vue, Angular, Ember will die, web will remain. There's a tradeoff in learning component systems like React and Vue since Platform alternatives like Custom Elements are not there yet and you still need routing, SSR and state management. So, I can understand using libraries for stuff that browser does not provide and learn a new thing. But why learn an entirely new ecosystem to replace APIs already there in browser? setTimeout will remain forever, ember tick may not.
Bundling
Everyone either uses webpack or rollup, they have thousands of plugins, and reporting capabilities. Ember reinvents bundling and uses broccoli. A dev using react, vue, angular, svelte, aurelia, moon, literally any other framework knows webpack. It has transferrable knowledge. When someone encounters a webpack bug, they may require expertise in it to fix it (which is not easy to come), but now they can fix any webpack build independent of framework being used. In comparison, I am yet to find a bundle analyzer and async lazy loader plugin for broccoli. I want to see the distribution of vendor JS compoenents and split them by routes or lazy load them? How do I do that? In webpack and rollup, I just change that to dynamic import. In react and vue both, routers support async components and route based chunking so that JS is only loaded when I go to that endpoint. It might not even be present or possible in ember. Or maybe it is, and some ember guru points me out to it. The point is that is is far easier to find webpack guru than ember broccoli guru. It is even easier to write your own plugin for rollup and anyone can use it, be they from react or vue. If someone tries to write a broccoli plugin, they will only benefit ember, and hence don't do it.
Small hookable surface area
As mentioned previously, you don't call ember, ember calls you. You write code in small hooks which ember provides. So you beg for it to get a little more control. For example. ember simple auth redirect after login is still not working because it provides you callbacks in a manner where it is not sufficient to load data required before transitioning to new route. A feature which is as simple as appending ?next=/events/wqe4334e/cfs in login URL and routing after login is complete. I recently had to write an entire partial JS parser to replace the environment dynamically in docker container using environment variables just because how ember env works. It is hardcoded in the JS and you can't change it's behaviour until that feature is added in ember core.
Given that none of these features are present in other libraries, you either have to write your own solutions or use another library, but at least you have flexibility to do what you want. And it is closer to the metal.
However these problems are somewhat still there in frameworks like Next and Nuxt, but they still don't force you to use one solution, they just mostly provide routing, SSR and auto configuration of state management, which are the problems I mentioned do not have solution on native web platform. How you want to deal with environments and auth redirection is on you.
Components
Changes
Let's play a game. Open ember docs and switch the version and see how the way of writing components changes drastically every 3-4 minor versions. Imagine trying to teach someone on how to write ember components. Is it arrow syntax? curly bracket syntax? It's a mix of both? All stars and versions must align for you to find what is good and what isn't. Ember changes its syntax drastically across versions. Even though it is good that they are making it better and using ES classes and decorator and getters, it still causes massive incomplete and buggy refactoring everytime it has to be updated. It is not a good experience. Try to find last time Vue or React changed its syntax. React only added hooks and Vue is doing same with composition API. Syntax remains same. The last time AngularJS became Angular, they lost most of their customers.
Code Locality
I make a change in template, and I want to add a computed property. Now, I need to search through the entire thing to find which JS file to edit? And then there are disjoint routes and controllers and components. Everyone agreed on the pattern of local logic and UI since advent of AngularJS and React. Vue follows the same pattern. Template/Rendering logic sits together with state, props and data logic:
component('speaker-info', {
props: {
firstName: String,
lastName: String,
featured: Boolean,
avatar: String,
github: String
},
data: _ => ({
followers: null,
following: null,
loading: true
}),
computed: {
fullName() {
return this.firstName + ' ' + this.lastName
}
},
async mounted() {
const {followers, following} = await fetch(this.github);
this.followers = followers;
this.following = following;
this.loading = false;
},
template: `
<div :class="{ featured_speaker: featured }">
{{ fullName }}
<img src="{{avatar}}" />
<Loader v-if="loading" />
<div v-else>
Followers: {{followers}}
Following: {{following}}
</div>
</div>
`
})SSR
Since we use SSR in production, many of the bugs reported are not reproduced locally since they are SSR specific. However, this is preventable if we ask developers to also use fastboot locally, but it is not just a simple config switch like in other frameworks (or maybe I'm wrong. I did not find any)
Esoteric Syntax
Which is better?
<div v-if="(isAdmin || isCoorganizer) && hasSpeakers"></div>{#if _and(hasSpeakers _or(isAdmin isCoorganizers))}
<div></div>
{#endif }I don't even know if the last one is correct to be honest with you.
Conclusion
Due to aforementioned reasons, it becomes difficult for us to move at a fast pace because we keep fighting the framework, refactoring while upgrading to latest and fixing issues in core rather our own.
We'll see in next few months whether upgrading to latest and fixing some long standing issues improves our pace of adding new features or it is limiting us in the process
Some very good points there @iamareebjamal . I'm finding myself agreeing with a lot of them. 😅But we do develop and run a fairly large ember app in multiple production envs at work, so from that perspective, my thoughts:
JSONAPI, though good in concept is painful to work with due to its state of tooling. But ember-data isn't only for JSON-API. It can work with any API that returns a json response out of the box (supporting ember-data's relationships would need some additional serializers/adapters written though). At work, we do not use JSON-API exactly for the reasons mentioned by areeb. It's easier building the api for us and our clients than just for ember-data.
Critical issues get fixed in core ember quite fast generally from what I have seen. But like you pointed out, third party libraries are a whole different story. What we do at work is, tend to keep third party apps to a minimum, and try to only use packages that are in active development with a lot of issues being raised and closed frequently (meaning the package is being used by a lot and the maintainers are also interested in maintaining it)
Ember addons are structured weirdly and and aren't the most easiest to learn, but I'd say it's not too hard to take a third party plugin and modify it either.
Broccoli 🥦- have spent many nights trying to fix build issues when I try to modify the build flow even a little bit. Many people who find web pack hard have never worked with Broccoli before. Broccoli is even crazier a lot of times. 😛. As for bundle analysis, I use https://github.com/kaliber5/ember-cli-bundle-analyzer
- Dynamic imports - you still can't do for routes/components but you can do for 3rd party libraries import via ember-auto-import plugin.
Code splitting/chunking - not supported now. But best hope for a better ember build system is https://github.com/embroider-build/embroider which is currently being actively worked upon by ember core devs. So should see the light of day very soon. I have tried it out locally on small projects. Works nicely. Gets rid of Broccoli completely and uses webpack.
Ember simple auth redirect after login, I have done what you're looking for. Maybe let's discuss more on that see why it may not be working. Any PR/file I could look at?
What did you want to replace dynamically in the environment?
Components syntax. Yes the whole ember octane thing with the angle bracket syntax has been a bit messy to say the least. But I think they're going in the right direction. Also, through the syntax changes may look drastic, there is backward compatibility between minor versions. Old syntaxes still work giving time to gradually migrate over. Vue and react have not changed syntaxes drastically because ember has been there for longer and it has a lot of legacy syntaxes and ideologies to shed compared to react or vue. But ember is trying to stay in the new. But will that be enough to keep ember alive, only time will tell.
Code locality - agree with you. No comments.
SSR - fastboot is not as easy as other SSR implementations in vue/react. Needs more configuration. But it's possible to get it to work properly with time. And all devs should always test code locally with SSR enabled. Which should be fairly easy as the ember Dev tolling comes with support for it. Just an env variable to control it.
Syntax - no arguments. It's a pain to work with. I look at react and vue template conditional Syntax and ability to use normal JavaScript in templates longingly every time I need to write a condition in a template in ember.
- Go through our list of addons, see if we really need something. if not remove it.
- Upgrade to 3.15
- Use ember-auto-import. Use dynamic imports for third parts imports where ever possible to reduce asset size.
- Switch to glimmer components and angle-bracket syntax. That brings us more in line with the latest js-style components and less of ember specific esoteric style of writing components. (We're still stuck with weird template syntaxes such as ifs and unless though)
- Embroider seems to be right around the corner. currently in beta stage. That would solve our build system woes bringing in webpack which most devs would be familiar with.
- Checkout if moving away from JSON API would make things easier on the API (and better usability within android apps) front. We will need to also write an adapter for ember-data to resolve relationships correctly if we're moving away from JSON API.
Ember simple auth redirect after login
What did you want to replace dynamically in the environment?
node scripts/fastboot-server.js. Maybe if you can take a look at it, it'd be great
Let's say I have built a docker image for frontend, now I need to define API_HOST, GOOGLE_API_KEY in environment variables and it should run using those options. There is no option for that currently. A docker image built for api.eventyay.com will only work for that. It diminishes the use of docker images of frontend as everyone has to build their own image again. I solved it recently but the solution was to implement a partial JS parser and it is very crude - fossasia/open-event-frontend#3736 fossasia/open-event-frontend#3542
@iamareebjamal checkout fossasia/open-event-frontend#3825 for this
- Admin can choose
Promoted Eventsfrom the Admin Event Dashboard. - Bugs related to Session/Speaker Addition/Editing have been fixed.
- Addition of AgeGroup for Attendee Form.
- User are now redirected to CFS page after login, Also many of the fastboot crashes have been handled.
- Access Code link has been fixed.
And many more bug fixes!
