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:
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.
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.
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?
> 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.
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.
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.
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.
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.