I've been running the Apple TV app on a Shield and it's got a lot of other bugs. Lately it's been showing shows in the totally wrong aspect ratio unless I restart the app. I do think they consider it a second class citizen.
2,265 karma · joined February 4, 2009
They both started this after the Witness came out, 10 years ago.
Since then, guess how many games Muratori has shipped? 0. (He cancelled his announced game.)
Guess how many Blow has shipped? 0 so far, but it sounds close now.
These engineers spent their time ragging on other developers for slinging bad code and doing things horribly, meanwhile those developers were shipping games and apps and all sorts of other stuff.
Discourse creates open source forum software in Ruby on Rails and Ember.js. We've always been 100% remote and are hiring for a few positions right now so please check out our web site:
I'm not sure about those stats you posted from 3 years ago since they aren't using the same `rake stats` numbers that are built in to Rails. Discourse's Rails app is currently 63k SLOC not including tests.
On my relatively fast computer booting takes 4s without bootsnap and 2.5s with it, which is a nice quality of life improvement.
I've spent a lot of time trying to tell people that all the stuff in Ember is there for a reason; for example, you're going to need a router, you're going to need support for controllers, etc. I still feel strongly that if your app is large and serious you are going to need that stuff.
But.
A lot of people just want to jump in and start building. React's immense popularity has shown the value in creating a view layer framework without all the extra stuff. It's great for onboarding new developers since there is less surface area to familiarize yourself with, and you can add in extra stuff (work your way towards full Ember) as you go.
It also comes with the added benefit of being able to add small components to a page without running the whole thing as an application, which is a use case Ember was not so great at before.
Overall I think it's a great announcement.
In the screencast it shows that when you deploy you just get a javascript file for your components that should be super small.
The "widget" framework is a series of simple ES6 classes that allow us to keep state around and delegate events as actions up to Ember controllers. We had a lot of pre-existing, battle tested code that was written using Ember idioms and was not a performance problem, so we kept that around and used the virtual dom stuff just for rendering HTML as fast as possible.
Why not React? Our main pain point was rendering, and we didn't need all the extra stuff React provided as those bases were already covered by Ember. Why include 26k min+gzip when we would only use a small part of it that was already provided by another excellent virtual-dom library?
Also, to me that sounds like cherry picking -- out of literally dozens of games you are focusing on one example.
And that specific example is from a game that caused outrage before it was even released for their "sexy latex nun" trailer:
As a side note, Ember.js has a nice method for this built in, that works on plain old Javascript objects as well as the heavier Ember ones:
Em.get(obj, 'user.them.public_keys.primary.bundle')
I've always thought we could do this as there is no technical reason why we couldn't offer both.
But honestly we receive very few complaints about it from users of the software. It seems here on HN that infinite scrolling is not super popular, but we are not getting the same feedback from our users.
In a long topic, what value does it give you?
We have found that the vast majority of users either link to a single post or scroll downwards. For mega topics, we have a summarize option that shows the "best of."
However, browsing posts is the most core functionality we offer so it's worth spending so much time on.
If the argument of the original article was "it's hard to do infinite scrolling well" I would have to agree. Pagination is much easier to implement. But for some sites, say Twitter or Facebook or apps like Discourse it's worth the effort IMO.
In terms of engagement, a user is much more likely to bail every time you require them to perform an action like click "next page." On Discourse they can just keep scrolling down as long as they care to read.
It also helps to track their position. On long topics, users often won't read it all in one sitting. I am a member of the Something Awful forums, and since they use vBulletin with pagination they can only know if I've opened a page and they use that to mark the whole segment of 20 posts as read. What if I stopped half way through? What if I opened the page in a new tab then closed my browser without looking at it? They assume I've read it all!
Logically, what is a "page" anyway and why should a user care about it? What does page 669 mean versus 670? How about we not expose implementation details to users and just let them get on with their reading?
My responses below:
> Users will lose the page length orientation - the browser scrollbar become useless.
We have a fixed "x/y" posts widget at the bottom with a progress bar.
> There’s no ability to jump to the end of the list.
The aforementioned widget has an up arrow and down arrow to jump to the top/bottom.
> Your users will not be able to get back to the same in-page position in 1 click.
We use replaceState to update the URL as they scroll. The back button works fine, and you can link to any position in the topic.
> There’s no visible footer until your users come to the end of the list/content.
Isn't this true of all sites where the user scrolls anything? I guess the difference is you see it more often with pagination. We instead have a fixed header with navigation options and extra details.
> Slow Experience - You are using a lot of browser memory as the page scrolls down.
We unload posts that have scrolled off the screen. We released a library for it too - http://eviltrout.com/2014/01/04/hiding-offscreen-ember.html
> If you switch away from the page by following a link there's no way of getting back to where you left off.
The back button works fine thanks to replaceState!
> Lack of sense of completion- no closure for users.
The progress bar and constantly increasing numbers in the widget help a lot.
> There’s no SEO opportunities for content located below the first scroll.
We serve up google indexable content just fine. See: http://eviltrout.com/2013/06/19/adding-support-for-search-en...
> You lose the ability to bookmark a dedicated point of interest.
With replaceState and updating the URL, you can bookmark at any point and return right back to where you left off.
> Distraction - The fear of missing out on data or other options will deter your users from completing an action.
I'm pretty sure this isn't relevant since we support all the above.
I'll probably have lots of conversations about this next week at Emberconf!
1. It's not running Ember in production mode which is much faster.
2. It's running an older release candidate version of Ember.
3. It is purposely wrapping individual events in run loop executions rather than just letting ember figure out when you put things into run loops.
I re-ran the benchmarks with the latest production mode Ember.js and removed the incorrect run loop usage got the following results:
https://gist.github.com/eviltrout/8058560
It's still slower than ReactJS but much less so than before. In fact it's now #3 in that benchmark suite behind ReactJS and Backbone (and much faster than ReactJS in the completing benchmark), although I wouldn't be surprised if the other frameworks were set up as incorrectly too.
Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control.
Angular also would not update the DOM as many times as the backbone example as it uses dirty checking to get around this problem.
I was leaving it to him to explain how it works :)
What you are suggesting is good practice but something that I suspect very few Angular developers do as it's not encouraged by the framework itself.
If you follow the guides on the official Angular site, they're done none of the things you suggest.
Ajax by definition is asynchronous. When you submit a post, the Ajax request is fired right away. But we don't wait for a response before showing the post in the stream (success case). We show it right away.
Then WHEN we receive a reply, we check the error status and if it was success, do nothing. If it failed, we revert the UI to the previous state. This is really easy with a client side MVC framework.
The downside is the failure case can be disorienting, as something will appear and then disappear. But the vast majority of requests, say, 99% never fail so the user so we optimize for that case.
Not true. All Discourse content has been indexed by Google since day one. Even though it's a Javascript app it's search engine friendly.
Secondly, Stack Overflow is the official place for Ember questions. The forums are for general discussion about features and other Ember related topics. Go to SO if you have a question and tag it as ember!
If I chose my languages or frameworks based on what was the most popular, I'd be using Java or PHP, not Ruby and Javascript.
Additionally, Object.Observe benefits Ember just as much as it does Angular.
The only atomic source is probably your database, and from the millisecond that you query it, it could be stale.
It is not the same thing as the class of bug I am explaining where you have multiple copies of the same object in memory leading to confusing state errors.
There are some objects that you just don't need to refresh constantly. In ember there's nothing stopping you from calling refresh when you enter a route, it gives you the object and leaves it up to you. If you think it's important to refresh it as the route changes, by all means do so!
If you're arguing that with a bunch of extra code on top of AngularJS it does what Ember does out of the box, that was kind of my point.
Secondly, client and server interfaces are not as symmetric as you indicate. Discourse has much more validation logic on the server than the client.
We generally "assume success", because the vast majority of requests do go through correctly. So if you submit a spam post for example, we'll show it in the client side view right away, but once the server asynchronously replies a failure, we'll display an error message and remove it. This can be jarring in the case of a failure as you'll see something appear then go away, but the vast majority of the time it doesn't happen.
The client side interface should do what it does best - display stuff quickly and avoid server round trips as much as possible.