Atwood continues to cry that Dicsource is too big to fail.
-
The State of JavaScript on Android in 2015 is... poor
For several years now we’ve tracked the fact that, over time from 2012 onward, Android JavaScript performance has become wildly divergent from iOS JavaScript performance. And not in a good way. To give you an idea of how divergent it has become, try: http://emberperf.eviltrout.com Complex list...
Meanwhile people circlejerk how Apple is #1.
Well this isnt news but yea.
-
Hard to say, some of it would possibly be under "let's present a better minimal rendered experience for ancient devices".
Atwood considering that some users have different configurations than he does and being understanding about low cost devices? No, this cannot be...
This would mean Discourse is positioning itself as more of a "premium" solution (read: devices that run JavaScript at near desktop speeds) than an "everyperson" solution (read: zillions of cheap Android devices with 2012 era specs), given the worldwide share of iOS and Apple.
Not super happy with that, but it might be the only viable way forward.
...whew, good to know he's back to normal.
-
Its funny because theres Flarum a modern php forum thats basically a discourse clone that doesn't require a server farm to run and it has none of the issues on mobile. http://discuss.flarum.org/
Hint: They don't use ember fucking js. Instead they basically wrote their own "framework" to do the job they needed in a clean fashion.
But hey, let's blame the device for not being to handle the hundred thousand line framework written in JS made for lazyass developers. Also lets write layers of abstraction on top of that. Your device is shit if it cant handle a yo dawg joke gone wrong.I wouldn't be surprised if Apple's secret is a bullshit detector that immediate purges sections of stupid JS from being executed.
-
I think quite a lot of people have looked at Discourse and thought: some interesting ideas here, but god the implementation sucks. I bet I can steal all the good parts and build something with 20% of the CPU load...
-
The thing I don't understand is who the hell thought that Ember + RoR would be a good idea. It's a clientside MVVM on top of a serverside MVC FFS, OMG WTF (and various other initialisms).
Oh, right, they wanted their cake and eat it too. They need an MVC to present something readable to web crawlers (and even with bots these days handling AJAX decently there's no way they'd handle this mess), but still want to be all hip and cool with all the clientside MVVM stuff.
I didn't read into Flarum's source code, but what I'd do, if I wanted a semblance of graceful degradation at least, is have a serverside MVC framework that can work completely on its own, but have a minimal JS framework as well that can re-route requests and basically tell the backend "ok, I need this page, do your stuff but don't render the HTML, just give me the JSON I need to render the templates on the client".
Wait, actually, that is what I did, and it works pretty well. Huh.
-
I can help but wonder if he tried to offload most of the server work to the browser. Just write a back end that's mostly a rest service that serves up data and let the browser do the html work. You can then use the rest to plug into as many front ends as possible
I toyed with this idea for a brief period but quickly learned javascript is a fucking hornets nest and I would rather drink lead based paint than stick my hand into it.
It's a rather novel idea but I suppose this proves that its a fucking terrible idea when executed.
-
This would mean Discourse is positioning itself as more of a "premium" solution (read: devices that run JavaScript at near desktop speeds) than an "everyperson" solution (read: zillions of cheap Android devices with 2012 era specs), given the worldwide share of iOS and Apple.
Wow. Move along plebs, this isn't the forum for you!
"Premium" in this case should refer to a well written, polished product. NOT a product you can only run using a premium device. A prime example of
What a prick.
-
Humm... seems he is complaining the javascript engine performance on Android device with multi-core CPU is poorer than what he'd like to see. I have no problem on that complaint though (I'm a WinPhone user
).
-
@him said:
Anyway, I agree, the 2013 me said "surely the state of JavaScript performance will improve on Android by 2016". Sorry 2013 me, things didn't turn out that way
or in other words
[quote=""]
3 year old devices shouldn't be allowed to use the internet
[/quote]
-
@@wood said:
To give you an idea of how divergent it has become, try:
- http://emberperf.eviltrout.com
- Complex list
- Ember 1.11
Sure, that sounds fun!http://i.imgur.com/ZKRpg15.png
1.3 minute loading times? Yep, that's what I've come to expect from discodevs.http://i.imgur.com/UFpRyyB.png
We're really off to a great start, aren't we?..http://i.imgur.com/tcRSC9U.png
Surface Pro 2, running the test on IE11, and it's slower than a iPhone 5.
Clearly, the surface pro 2 is just an elaborate android phone in disguise.
-
Let's just marvel in the brilliance of creating a website that's iOS compatible only... A fucking forum at that..
And it crashes constantly on that one platform.
-
So he still finds it fucking acceptable that performance sucks that bad on a FLAGSHIP HIGH SPEC Android phone, let alone a cheaper one?
It's clearly not his software's fault for being an over complicated heap of steaming donkey turd.Isn't this a Discodev benchmark? Is it not possible the benchmark is optimised for iOS?
Here's the test on an i7 Macbook Pro:
Ember Version: 1.11.3 User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 .--------------------------------------------------------------------------. | Ember Performance Suite - Results | |--------------------------------------------------------------------------| | Name | Speed | Error | Samples | Mean | |---------------------------------|-------------|--------|---------|-------| | Baseline: Render List | 443.48 | 2.71 | 153 | 2.25 | | Baseline: Handlebars List | 495.31 | 3 | 422 | 2.02 | | Ember.get | 1069853.8 | 0.95 | 92 | 0 | | Ember.set | 321437.1 | 1.21 | 94 | 0 | | Ember.set (primed) | 345715.57 | 1.04 | 95 | 0 | | Ember.get (primed) | 1114639.89 | 1.1 | 94 | 0 | | Ember.run | 200503.31 | 3.41 | 80 | 0 | | Ember.LinkView.create | 181908.45 | 3.98 | 66 | 0 | | Ember.Component.create | 422574.1 | 3.82 | 88 | 0 | | Baseline: Object initialization | 65448184.43 | 1.1 | 95 | 0 | | Ember.Object.create | 348883.22 | 1.1 | 89 | 0 | | Render List | 23.73 | 102.47 | 35 | 42.14 | | Render List (Unbound) | 70.29 | 10.66 | 326 | 14.23 | | Render Complex List | 14.39 | 66.29 | 65 | 69.51 | | Render Complex List (HTML) | 13.59 | 37.02 | 156 | 73.59 | | Render Simple Ember List | 106.62 | 5.38 | 646 | 9.38 | | Render List with link-to | 17.02 | 58.73 | 94 | 58.77 | | Render link-to | 246.15 | 114.62 | 16 | 4.06 | '--------------------------------------------------------------------------'
-
A fucking forum at that..
Exactly, sharing text was literally the first thing people used the internet for, and now Android phones are too slow for it?!
-
why not copy the nicely formatted output
-
Didn't see the tab. I'll fix it.
-
.-------------------------------------------------------------------------.
| Ember Performance Suite - Results |
|-------------------------------------------------------------------------|
| Name | Speed | Error | Samples | Mean |
|---------------------------------|------------|-------|---------|--------|
| Baseline: Render List | 155.2 | 1.34 | 106 | 6.44 |
| Baseline: Handlebars List | 136.64 | 3 | 477 | 7.32 |
| Ember.get | 60385.59 | 0.57 | 97 | 0 |
| Ember.set | 48825.34 | 0.64 | 95 | 0 |
| Ember.set (primed) | 49184.28 | 0.47 | 96 | 0 |
| Ember.get (primed) | 61669.61 | 0.63 | 94 | 0 |
| Ember.run | 37297.86 | 0.59 | 95 | 0 |
| Ember.LinkView.create | 13245.76 | 0.66 | 95 | 0 |
| Ember.Component.create | 16054.35 | 0.58 | 97 | 0 |
| Baseline: Object initialization | 7721800.57 | 1.11 | 93 | 0 |
| Ember.Object.create | 168955.27 | 0.83 | 91 | 0 |
| Render List | 4.46 | 5.38 | 52 | 224.1 |
| Render List (Unbound) | 11.89 | 2.94 | 39 | 84.1 |
| Render Complex List | 2.47 | 7.58 | 31 | 405.48 |
| Render Complex List (HTML) | 2.18 | 8.09 | 27 | 459.04 |
| Render Simple Ember List | 15.8 | 2.96 | 25 | 63.28 |
| Render List with link-to | 3.05 | 4.6 | 37 | 328.14 |
| Render link-to | 171.98 | 3 | 205 | 5.81 |
'-------------------------------------------------------------------------'Ipad air, ios 9, chrome
-
Oh, sure. You ignore the guy who posted a screenshot, and then fuck it up yourself (I saw the edit) but I am the
for copying it from the HTML version? 
-
the screenshot was readable :p
the html you copied was all lopsided, which was hard to read..
-
-
Who uses Chrome on iOS?
-
ios 9: the test won't run in safari, but works fine in chrome.. MEDIOCRE!
-
I am 100% against using any sort of JavaScript "Framework" because of how bad the user experience is with large downloads and slow page load times. IMO JavaScript should be used purely for adding and removing CSS classes on HTML elements 90% of the time, and the other 10% of the time stuff like games or dynamically updating content. That's unreasonable for some people, but it's the standard I hold myself to when doing any sort of web development.
-
-
-
Plenty of places use it without causing the performance to suck like Discourse does.
Discourse is an overcomplicated horror bolted together by incompetent fools who listen to King Jeff™ and his ideals about what's acceptable performance because Discourse is intended to IMPROVE THE INTERNET IN TEN YEARS NOT NOW LOLZ.
-
Who uses Safari on iOS 9...
Oh, wait...
-
I wouldn't be surprised if Apple's secret is a bullshit detector that immediate purges sections of stupid JS from being executed.
Also, control over the hardware which means there's not even a slight need to emulate a universal architecture in software. Yeah, yeah, jit, whatever. Dalvik still sucks.
-
-
>This would mean Discourse is positioning itself as more of a "premium" solution (read: devices that run JavaScript at near desktop speeds) than an "everyperson" solution (read: zillions of cheap Android devices with 2012 era specs), given the worldwide share of iOS and Apple.
...whew, good to know he's back to normal.
LOL. Gotta love a web app targeting a market based on hardware. No doubt the VCs will love this strategy.
-
I can help but wonder if he tried to offload most of the server work to the browser.
I doubt it, but I'm not going to rule out that he did and it was just a spectacular failure. HINT: our cootie storms aren't on our browsers.
-
iOS compatible only
As long as you don't attempt searching from anywhere but the very top of pages, can't access the "quote reply" button on some highlights, can't get good highlights in some cases, and (new!) don't want to go back and edit the middle of a post in progress unless you're ready to delete everything you've typed since, unless you're lucky enough to touch where the cursor is exactly.
-
BUY STOCK IN ANDROID
The State of JavaScript on Android in 2015 is... poor
According to figures released [Feb 2015] by Kantar Worldpanel ComTech, iOS accounted for 47.7 percent of all smartphones sold in December 2014 in the U.S. That’s just a notch above Android’s 47.6 percent. The larger phones helped them a lot. Of course I’ve been saying that for years… I’d expect...
I'd expect Apple to dominate over time in the US, particularly given how amazing the latest devices have been.
Heh:
https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889/19Remember we send down half the data on all Android devices.
But do you really need to send all the data that you're sending?
-
@delfinom said:
I wouldn't be surprised if Apple's secret is a bullshit detector that immediate purges sections of stupid JS from being executed.
Also, control over the hardware which means there's not even a slight need to emulate a universal architecture in software. Yeah, yeah, jit, whatever. Dalvik still sucks.
Eh? JS isn't even a universal architecture, its byte code is whatever the fuck whoever the fucks parser wants to generate. Almost all VM languages convert JS to native assembly optimized instructions. On that note, Microsoft, Mozilla, Google and others are working on Webassembly which is meant to be that crossplatform architecture byte code.
Dalvik itself is dead and replaced with ART. But Dalvik has little to do with Chrome which is still C++ based even on Android.
-
BUY STOCK IN ANDROID
The State of JavaScript on Android in 2015 is... poor
According to figures released [Feb 2015] by Kantar Worldpanel ComTech, iOS accounted for 47.7 percent of all smartphones sold in December 2014 in the U.S. That’s just a notch above Android’s 47.6 percent. The larger phones helped them a lot. Of course I’ve been saying that for years… I’d expect...
I'd expect Apple to dominate over time in the US, particularly given how amazing the latest devices have been.
Heh:
https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889/19Remember we send down half the data on all Android devices.
But do you really need to send all the data that you're sending?
He probably thinks Apple's new "stylus" is a revolutionary ground breaking concept, fuck you if every other manufacturer has had styluses for the last 20 years, this can be used as an anal dildo!
-
I think quite a lot of people have looked at Discourse and thought: some interesting ideas here, but god the implementation sucks. I bet I can steal all the good parts and build something with 20% of the CPU load...
Isn't that exactly how you started your own forum-solution as well?
fuck you if every other manufacturer has had styluses for the last 20 years,
There is a minor bug report by a person using an android phone with a stylus... it was used by Jeff and co to showcase how bad and unimportant our bugreports are
Filed Under: Just saying
-
It's a rather novel idea but I suppose this proves that its a fucking terrible idea when executed.
A lot of sites have been doing that just fine for ages. Gmail is the classic example.
-
2015 Moto E. This isn't an ancient phone by anybody's standards, but apparently it isn't premium enough for Discourse.
-
But do you really need to send all the data that you're sending?
Of course they need it all. How else would they be able to load the nextpagebatch of posts if they don't know what all the posts in the topic are?!
-
-
Discourse on mobile is still a perfectly functional option...
... for a phone repair technician who needs a rapid batery-drain app.
-
@DogsB said:
It's a rather novel idea but I suppose this proves that its a fucking terrible idea when executed.
A lot of sites have been doing that just fine for ages. Gmail is the classic example.
Gmail is notable for the fact that its UX has been getting steadily worse over time. The initial version was clean and easy to use, once you'd wrapped your head around its major points of difference from its contemporaries (mandatory threaded view, labels instead of folders, message dedupe between Inbox and Sent, etc). They bikeshedded it for a while with color changes and whatnot. Then the Everything Is A Phone brain worms arrived, and today's Gmail web interface is a total rat king. The latest contacts manager, in particular, is an abortion.
-
Gmail is notable for the fact that its UX has been getting steadily worse over time.
Well yes, but that's not what we were talking about. We were talking about performance.
-
I am 100% against using any sort of JavaScript "Framework" because of how bad the user experience is with large downloads and slow page load times. IMO JavaScript should be used purely for adding and removing CSS classes on HTML elements 90% of the time, and the other 10% of the time stuff like games or dynamically updating content. That's unreasonable for some people, but it's the standard I hold myself to when doing any sort of web development.
+1. I use a [url="http://materializecss.com/"]JS framework[/url] for the websites I build, but it's extremely lightweight and is basically used only for some light page modification and other UI stuff. Strangely enough, I've never had any issues on any mobile device when using a site built with this. Even old ones...
If you try to offload your rendering to crappy Javascript, don't be surprised when it fails spectacularly.LOL. Gotta love a web app targeting a market based on hardware. No doubt the VCs will love this strategy.
XD but it's a web app, so at least it's universal!!!!
Gmail is notable for the fact that its UX has been getting steadily worse over time. The initial version was clean and easy to use, once you'd wrapped your head around its major points of difference from its contemporaries (mandatory threaded view, labels instead of folders, message dedupe between Inbox and Sent, etc). They bikeshedded it for a while with color changes and whatnot. Then the Everything Is A Phone brain worms arrived, and today's Gmail web interface is a total rat king. The latest contacts manager, in particular, is an abortion.
I actually like the latest UI version.............
-
There's just way too damn many heavy JavaScript frameworks duct-taped together, and poorly-taped-together at that. Even on my 4.0 GHz quad-core i5 with 16 GB RAM and a GeForce GTX 460, client-side Discourse performance is terrible. Opening new tabs in a Discourse instance freezes my entire system for seconds at a time. And this is a system that can run Crysis at max graphics settings!
Does Android suck? Possibly. But you know what sucks even worse? Discourse. Combine the two and you get a terrible experience.
-
FWIW, I've found discourse mobile to be acceptable, performance wise. At least compared to my desktop/laptop. I'm not operating on a cheap low-end device, mind you (Nexus 6, Moto X 2013, Nexus 7 2013), but it's not terribly crappy. The network performance hit and terrible bugs are much worse IMO.
Also, I don't even understand the whole point of mobile mode. Why the hell is that still a thing? Responsive design has been around for... a while now... and using a different "mobile" mode is a bad idea for many reasons. Just take the desktop mode you have, make it responsive, and make sure everything works. Much better solution...
-
There's just way too damn many heavy JavaScript frameworks duct-taped together, and poorly-taped-together at that. Even on my 4.0 GHz quad-core i5 with 16 GB RAM and a GeForce GTX 460, client-side Discourse performance is terrible. Opening new tabs in a Discourse instance freezes my entire system for seconds at a time. And this is a system that can run Crysis at max graphics settings!
Looking their performance figures is rather amusing when working in an environment where a 1ms runtime is kinda good, 10ms is salvageable, and 100 ms means that you'd better rethink your approach. And it's not as if these methods aren't dealing with thousands to 1M+ objects either...
Yeah yeah, different abstraction levels and so on...
-
Looking their performance figures is rather amusing when working in an environment where a 1ms runtime is kinda good, 10ms is salvageable, and 100 ms means that you'd better rethink your approach.
Yeah. We do a lot of embedded and real-time development at work. A lot of our stuff is measured in microseconds, and if we can't get stuff to happen that quickly then we don't have a viable product. 1ms is an eternity to me.
-
@codlnghorror said:
we bet heavily on near-desktop JavaScript performance on mobile devices
The thing I don't understand is who the hell thought that Ember + RoR would be a good idea. It's a clientside MVVM on top of a serverside MVC FFS, OMG WTF (and various other initialisms).
Yes, it is a bit freaky having what is almost MVC sat on top of another MVC. But when it comes to modern web apps, with all the widgets and dynamic shit going on, if you don't have a decent JS MVx framework, you're basically left with jQuery. Which is fine for little things, but for anything major, it's pretty shit.That said, Bootstrap (definitely not an MVx framework) and jQuery are together good enough for probably 90% of tasks, so...
I toyed with this idea for a brief period but quickly learned javascript is a fucking hornets nest and I would rather drink lead based paint than stick my hand into it.
You just need to get used to it, s'all ;)I am 100% against using any sort of JavaScript "Framework" because of how bad the user experience is with large downloads and slow page load times.
Most of which can be solved by using the versions of those frameworks served by CDNs; that way, you take advantage of all those lovely lovely caches
-
Bootstrap (definitely not an MVx framework) and jQuery are together good enough for probably 90% of tasks, so...
Also, bootstrap+jQuery don't eat up ALL THE DATAZ and ALL THE PROCESSING
-
@RaceProUK said:
Bootstrap (definitely not an MVx framework) and jQuery are together good enough for probably 90% of tasks, so...
Also, bootstrap+jQuery don't eat up ALL THE DATAZ and ALL THE PROCESSING
BUT IS IT WEB SCALE?
