EvilTrout

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.

It's really nice to be able to read something without interruption.

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?

All these problems are solvable. I co-founded Discourse (http://discourse.org) which uses infinite scrolling heavily. Discourse is also 100% open source so you can see how we did it.

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'm glad that you finally found a way to get up to speed. I find it very challenging helping people over the initial jump of Ember learning so any feedback about what worked for you is great to have.

I'll probably have lots of conversations about this next week at Emberconf!

No we left it as is, but it is configurable in the admin section. This is very important for non-English languages where one or two characters is often enough for a descriptive title.

I looked at that benchmark and there's a few huge red flags right away:

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.

Om never does any work it doesn't have to: data, views and control logic are not tied together. If data changes we never immediately trigger a re-render - we simply schedule a render of the data via requestAnimationFrame.

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.

Honestly the reason I haven't written about it is because I didn't write it! Sam did a great job, and he did it in a super short period of time.

I was leaving it to him to explain how it works :)

You CAN make Angular work like Ember, but you have to add a lot of code to do what Ember encourages you to do off the bat.

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.

It's not as periodic as that.

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.

However, the discussion forums are horrible. They're using Discourse, which was written in Ember, and it's nearly impossible to find answers to anything previously posted. Because it's in Ember it's all JavaScript, so nothing is indexed on Google, and the built-in search is awful.

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!

EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time writing a big Ember app and see it loosing out in the Javascript framework wars.

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.

Any time you are showing a user a representation of data, be it in a web page or client side rendered template, it is potentially out of sync.

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!

You can't possibly argue that using Backbone for models is idomatic AngularJS.

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.

I'm mostly talking about sharing data in this post. If you have a user object from the server, why would you need to retrieve it again as you navigate around? It's already been given to you from the server.

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.

In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it.

My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that don't embrace it.

That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use

I do say in the end that there are viable workarounds. It's an issue of maintainability and consistency. Ember embraces patterns for ambitious applications.

If it works for you I'm glad, I just think we should open ourselves up more to the advantages of rich client side apps and not hold back!