Just curious - why emberjs and handlebars libs are used? What do they do so special behind the scenes?

(Anton) #1

Looking to the forum from outside, I see very few busy elements and a very easy design, no matter which page:
the header, the menu, the table, and just a few types of updatable fields.

Could someone hint me to better understand why the whole templating language and that emberjs framework is in use?

I’m curious because [I’ve read somewhere here] they both are slow and all devs are waiting for updates with the hope the speed will increase considerably.

Is the main purpose of these libs to allow for easy templating and plugin writing?
If not, then what is the purpose of using both of them?

Currently, there are really few places where the data should be updated dynamically - and it’s so easy to do it in just pure JS with JQuery.

I am not criticizing any decisions, but just coming from PHP + JS/JQuery with 10+ years of experience and have built tens of small and medium websites but never used any JS frameworks, and instant page reload was always much much faster than using such frameworks, so I’m just asking why with the hope to better understand the intention of developers.

To compare with what I’m used to seeing with PHP made by my collegues: 20-40ms server side + no or little processing time client side, so it’s just super-fast and nobody never moaned about the speed of page load and rendering time.

I believe the same would be easily reachable with Ruby + Jquery, but there might be some drawbacks if the team decided to use additional heavy JS libs. Plus, having no ember would make entry point for potential plugin developers less requiring.

Not trying to be unkind! Please do not get me wrong. Just curious and want to know explanations behind the decisions. Thank you.

How to add a loading page, some like Gmail?
(Régis Hanol) #2

You might be interested in reading @eviltrout’s post about it :wink:


(Anton) #3

Oh that’s great - I wanted to read a dedicated topic on it. Thank you!

UPD. After reading it - now I’m curious why page reload is still so slow? What’s currently making it slow?

For example, if I edit a category caption - it takes up to 4 seconds to reload a page. What is more, I usually see the old page before it is reloaded, but with the updated category name, for as long as 2 seconds! - and then I wait for another 1 to 2 seconds for it to reload. Altogether, the experience is nowhere near smooth, even though I understand that renaming category happens once in a blue moon.

I have never experienced such with any forums. So if Emberjs is so nice and fast, and if there are few components on a category page - why it is slow? I expect it to load in, say, half a second, but it never does so.

(Robin Ward) #4

Whenever people tell me “Discourse’s UX seems so simple, why do you need something like Ember when you could just use jQuery?” it’s actually a compliment because it means we’ve hidden a lot of complexity in a simple looking interface. It is easy to look at it and say, well there are only 10 things on the screen, but not realize all the options and user levels and general configurability we allow.

If you tried to code something like our post stream, with all its features using just plain jQuery selectors, you would have a ridiculous amount of difficult to maintain code. I’m sure of it!

Client side rendering is about a lot more than dynamically updating the interface (although that is a very useful thing to do.) It is about contacting the server a lot less, and about being able to render the same thing in multiple ways.

Now: about page loads. Editing categories is one of the few things that will trigger your browser to refresh. We made this decision early on as categories do not change frequently and it was easy to assume they’d be constantly cached. We can probably improve this, but it is a low priority now as it doesn’t happen frequently.

You should not be seeing 4s load times for pages though. I would check your server set up, as typically it should be much faster than that. I see those kind of load times in development though, but here on meta.discourse.org it is generally much faster.

(Jeff Atwood) #5

This is a very, very rare event – editing a category title. And only admins can do it. This is not something we spend any time optimizing at all for that reason.

Can you pick something more common to time, something typical users do frequently, like creating a new reply?

Also, what is your computer’s CPU speed, and what browser? Since everything is done in the client in JavaScript, we are sensitive to local speed of browser JavaScript. Luckily most people’s computers are obscenely fast these days… and iPhone 4s -> iPhone 5 -> iPhone 5s is 2x, 2x, 2x faster in each step, total of 6x faster.

Another example, here are Sunspider JavaScript benchmarks from my computer in 2007:

Notice the fastest browser with a fast computer completed SunSpider in 5.4 seconds in 2007.

I just ran SunSpider on my computer in Chrome and it took 153 milliseconds. That is a 35x improvement in 7 years.