I have been working on a very huge application, and which I want to convert to ember. I have started with Ember CLI with PODs and able to create my own components.
My concern at the moment is the size of the application. Our old app only templates html file are more than 20mb, and so far I have covered 10 to 12 modules and my production JS file size is 850kb +. I need to create at least 200 modules.
I know I can reduce the size by using components and then reusing them, for a module I create using component it increases the size by 25kb to 35kb in production js Now if I multiply 30kb to 150 I got estimated 6mb of a file. This is a rough estimate (as there are much more complex modules which might cross over 100kb for each). Including vendor.js of 1mb and then CSS and other jquery + external library; my initial loading size will cross 8mb (again an assumption)
Here are some of the screenshots from the existing application
We already have started developing backend in Laravel and used Simple Auth for login, Ember Data for data communication and PODs for managing files in Ember CLI
I need to know how can I lazy load some of the stuff, as 8mb of JS files is a huge negative where this application will be used as they have low internet speed. Also my app require dynamic tabs for each link, keeping its state and content kept in memory until tab is closed or form is saved. So is that possible in Ember?
Am I on right path? Is Ember my right choice for this application? Shall I create separate app for my complex modules? like order form and production report? What are my options…
The bigger the application is, the more benefit you get from using Ember.js and the conventions of the ecosystem, from Ember CLI’s project structure and build pipeline, to addons.
What think that will help you in the future is lazy loaded Ember.js engines.
At the moment there is an ember-engines addon that starts implementing the Engines RFC but it does not support lazy loading yet.
Contributors are working very hard on it, though.
As a stopgap measure, you can split up your application into several Ember.js applications, and then make your web server deliver the right one for each part of the website. This has the disadvantage that going from one Ember.js app to another has to boot up again, so you have to consider the impact.
As for strategies to help with reducing project size, I suggest extracting things into components and putting them into addons, whether separate or in-repo. You can have private packages on npm, you might want to take advantage of that.
It’s not the first time someones mention ember-engines and its lazy loading capability as a solution to huge huge applications. @locks did a good job framing the concept for an alternative while waiting for an official/stable ember-engines version to drop.
Eight months ago we faced a very similar issue. Encouraged by the -incorrect- belief that ember-engines was going to drop very soon (the RFC was opened in 2014) we adopted @locks solution (proposed by someone else at the time) and separated our huge code base into multiple Ember.js apps and add-ons.
However, we’ve encountered limitations with this alternative. While it allowed us to grow our product by shipping gigantic features encapsulated into their respective apps (and therefore small network footprint) it turned out to be a maintenance trap!
Every time the team decides to update to a new version of Ember.js, ember-cli or ember-data all the projects need to be touched. The core team has admitted the transition to Ember 2.0 could have been smoother (a lot of deprecations where communicated at a very late stage). The vast network of complex apps and add-ons we’ve created will need to be refactored if ever we decide to move to ember-engines when it’s out.
The time we’ve saved at the beginning by adopting this approach, segmenting our products into individual apps, extracting shared components into add-ons and, ultimately, not spending enough time on actually reducing our product’s footprint is all going to be lost for maintenance and refactor purposes.
A better strategy could be to consider ember-cli-lazy-load from the get-go.
@swaggaguru great feedback, that was and is in my mind. As our app codebase is crossing 60mb (only the one we wrote, not including any vendor or external libraries) having 20mb + in html and then 2, 3 mb JS files. I was thinking to break it in different apps even before @locks suggested it. as there is another requirement of tabs where each page will have its own tab… still not having hope for this
I thought to build different apps for each module, but I always feel that it will be like firing bullet in my leg right before we start developing it. For the database part, I liked how ember data is fetching only what is required for different sections. There should be a lazy loading of somekind or else ember will not be able to work for us. In-fact I came up with these following options
Create separate app for each page, its a duel welded sword - a bullet in leg - or this
Lazy Load (not yet supported out of the box) - Find it before doing anything
Look for alternate (React - Angular … a long list)
make it 8/10mb js file and wait / hope for lazy load to come soon
Server side rendering options… ()
I tried to use ember-cli-lazy-load but it seemed it didnt worked. I will create a blank application tomorrow to try this again.
The bigger the application is, the more benefit you get from using Ember.js
This is at best an unsupported claim, and at worst an inversion of reality.
Sure, apps need to talk about futures. But can we just STFU about all kinds of amazing stuff that’s right around the corner? Especially since, you know, it isn’t?
I would seriously reconsider the decision to port this app to Ember, which you chose because…why?
@Bob_Myers the thing is, as I told, we already have started developing the API in PHP / Laravel, It is a requirement now as we will also provide SASS to other companies, planning to build mobile applications as well and so on.
Saying this, I know we have to break the code of Frontend and Backend. Using PHP for backend; Now for front end, which framework is suitable for me? Or create a separate PHP Applicaiton which will use the API? Isnt there any JS framework which supports lazy loading at the moment?
True that, I am going to stick with what I am doing. Using Ember CLI and building the application. Hoping that I do follow best approaches for components, mixins, helpers to reduce the app size as much possible. And I will be happy if my app comes down to 2/3 mb… which I doubt at the moment.
So what if my final JS is less than 4 mb, shall I keep using ember?
)
