I’m from China and found Discourse awesome. A huge thank to the community.
Just a quick one,when I click on a topic there’s always a loading spinner spinning on a blank page prior to the content of the topic being rendered. Is it possible to set up Discourse to display the loading spinner on the current page which is a list of topics, in this case, rather than a blank page?There are 2 reasons that I’m raising this, firstly,for instance, it takes around 1 second to load the content of a topic, users can still keep reading something from the current list during this period. A blank page is just a waste of time.Secondly it will make the UI more fluid by not using a blank page.
This is not about speed.When I click on something,the loading spinner on a blank page lasts for 1 or 2 seconds and blocks the UI, you can do nothing during this period. It is really a big pain point.
I know that it takes sometime to render a new page.But can we improve it like:
1.If backend does the majority of the job(say,2 seconds): Do not tear down the current page after sending the request.Do it asynchronously.The user is still able to scroll up and down or even click on a new link during this period.Once the result is ready,update the content of current page.
2.If it takes backend 1 second to query the data and frontend another 1 second to do something like converting the data to a view,then probably the frontend has to be blocked for 1 second. But still, can we please do not tear down the current page so that the user can still keep reading it.Once the new content is ready we should always be able to update the view like a snap.So it is not about choose a generic placeholder or overlay.
That is how fast we are able to get the data shipped from the server. we have no choice but to display that circle while client is rendering (and tearing down the old page).
Looks like client side is too thick and there are some performance issues.I have no idea about how EmberJs works. But is it possible to make the ‘tear down’ as the second last step so that we can have the old page longer?
That would require some major ember re-architecture as far as I can tell, plus it would feel like stuff is not responding to click for arbitrary amounts of time which would be a negative.
People can tolerant 1 or 2 seconds for a new page. Most of them will wait for a while and won’t click for arbitrary amounts of time.So I still think it’s better to keep the old page longer.
Ideally it would be good that we can resolve the performance issue.Blocking the UI for more than 1 and half seconds is really annoying.
How fast is your client computer? What CPU, and browser? That affects JS speed a lot, which is bound by single core clockspeed and architecture. Adding 8 cores will not do anything for you in JavaScript.
We are making a bet with Discourse that client JS speeds will become extremely fast over time, and that mobile devices will reach desktop speeds at JavaScript. This is mostly coming true on iOS, but on Android … notsomuch
I’m using Firefox 42.0, inter® Core™ i5-323-M CPU@2.60GHz
This is the first day since I heard of Discourse, so forgive my ignorance,seems to me that EmberJs is very slow at rendering complicated DOM. It is absolutely right to bet that client JS speeds will become extremely fast, but it may be prudent not to bet on EmberJs, or at least use some ‘adaptors’ to encapsulate it so that it can replaced with some other frameworks without too much effort when required.
Ah the i5-3230M? That should be fast enough. I was mostly checking to see if you had a CPU from 2010 or earlier – or an Intel Atom or other very slow CPU.
We don’t get many (any?) complaints about desktop speed, it is mostly an issue on Android these days due to the JS perf penalty and general slowness of CPUs relative to iOS.
