Ember js as a web development framework.
Open Event on the frontend side uses a framework called Ember-js, and it is very necessary to understand it, if one has to contribute to the frontend, otherwise it will be extremely hard considering how big and complex ember can actually be, this is a collection of quick facts I’ve collected about ember.js, knowing this might also aid you in contributing to open-event even faster!
Ember.js is a very opinionated web framework that uses a lot of the new ES6/ES7 features that provides a MVC workflow for devs to create websites in a more organized way, and introduces many new concepts, into designing user interfaces.
Ember.js is better to create webapps, as it is to create a blog for example. Since it uses the MVC perspective of creating user interfaces. Another point I can mention is that ember.js is very non-intuitive, it has a big learning curve, and that means, editing ember.js webapps has an investment cost for every person that wants to edit them.
This is independently if they already have knowledge of JavaScript, HTML, CSS, the reason is, ember.js has its own internal language, so if you read the output of the code it generates, you’re obliged to learn how the entire system works. It works not very differently from a node.js application converted into web (browserify), the HTML code the user agent downloads is very small, it downloads two javascript files, one just defines functions with all your user data, (your routes, templates, compiled handlebars files), and another one that controls the other, it has the virtual machine interpreter, and boots the website up so to say. And that’s mainly one of the reasons why big websites that use ember.js take so much to load. Because every time you enter the website you download the entire website in a single javascript file, (of course once it is cached this should be done quicker, so the first time will usually last very long compared to others), it isn’t surprising because most modern web frameworks actually do this.
I think it’s very important to know some details about how this specific framework works.
As for the user side (the developer) is pretty much wonderful. You have an application.hbs file where your main app (the main user interface) is there, and you can just use commands to generate routes, when you add routes and they’re not assigned to any parent, they’re added as “children” of the main app.
Before we get lost in the new Jargon, let me explain quickly what a route is, when you’re visiting a website you have in your URL a path of the website to whatever current file you’re looking, every new URL you visit might get added on your history if you have it enabled, and you’re allowed to go back and forth in history!
Every address is also a part of the website, a website is traditionally organized as a file system structure, there are directories, and there are files, which you can download. You can have subdirectores in directories, and nest and organize things according to what you think it’s important.
When you load an ember.js with a different url, say you’re on the main page “scheme://host:port/” and then you click on settings “/settings”, what usually happens is that your browser will be redirected to “scheme://host:port/settings” and will usually reload a new page, in ember.js you actually download the same page no matter which url you visit, but ember.js notices which route are you seeing and provides the right interface for that, and when you click on a link from the same website you don’t actually reload the website, the site manipulates the history so that the history thinks, you’re visiting another part of the website, and you actually do. This is done with the history api[1]
So when you add routes, you can see it as some sort of “subdirectories” on your ember.js web application. We also have components, and a component is a part of the application you can reuse through your website, like a template (a controller template, not an HTML template), there are also HTML templates as well, these are the handlebar files, ember.js compiles these into its own bytecode, when they’re loaded, they’re loaded by the virtual machine in ember.js.
There are many rules in ember in how to do things, and things are organized very specific according to some guidelines, that means ember projects won’t be the best in getting people involved many quickly, but hopefully it will reduce the number of errors, or bad practices, if people stick to the guidelines ember provides.
Resources
http://emberjs.jsbin.com/?html,css,js,output
[1] http://html5doctor.com/history-api/