EvilTrout

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.

Blow and Muratori gained a following of engineers by bashing existing popular languages and engines, claiming they were all garbage.

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 | Full Stack Engineer | Remote | Full Time

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:

https://www.discourse.org/jobs

In Toronto mortgages don't work this way. Fixed rate mortgages are typically 5 year terms. After the term is up they'll have to get the higher interest rate.

Once they found him they collected two more samples and matched it directly with their source sample.

Discourse co-founder here.

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.

As a long time (5 years full time) Ember developer, this is quite interesting to me philosophically.

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.

Those are only the build tools, and trust me you want a great build pipeline when dealing with Javascript these days!

In the screencast it shows that when you deploy you just get a javascript file for your components that should be super small.

It's perhaps not as custom as I made it sound. The code we have is a wrapper around the [virtual-dom](https://github.com/Matt-Esch/virtual-dom) library which does most of the low level work.

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?

I just learned about your project today and it's fantastic! We must think alike.

I watched her video that featured Hitman Absolution as well and I don't recall her saying "this is integral" to the game. It was one of many examples.

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:

https://www.youtube.com/watch?v=e9NC-PCHp_I

But MP4s will play using low power on virtually every touch device today. That is a huge advantage.

What if them is `undefined`? You'll get an exception when usually you just want `undefined` as the answer.

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')

> For maximum usability, why shouldn't the app support both infinite scroll and paginated, and let the USER choose (by url slug or GET param)?

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.

Question: Why do you need to jump to page 20?

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."

It actually was (and continues to be) a lot of work. It's the very first thing we started work on for Discourse and will likely never quite "end."

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.