Profile

Cover photo
Peter Wagenet
1,354 followers|492,863 views
AboutPostsPhotosVideos

Stream

Peter Wagenet

Shared publicly  - 
 
 
Ember.js 1.0 is out now!  Go forth and build great things!

http://emberjs.com/blog/2013/08/31/ember-1-0-released.html
Ember 1.0 Released. Posted By: The Core Team – Aug 31, 2013. Today, we're excited to announce the final release of Ember.js 1.0. The first commit to the repository that would become Ember.js happened on April 30th, 2011, almost two and a half years ago. At the time, Backbone.js was rocketing to ...
2
Add a comment...

Peter Wagenet

Shared publicly  - 
 
7
Add a comment...

Peter Wagenet

Shared publicly  - 
 
Ember 1.0.0-pre.4 is out now. New router API, performance improvements and much more! http://emberjs.com
3
Add a comment...

Peter Wagenet

Shared publicly  - 
 
 
Maybe I pick a tool that's really distinct with it's conventions and has some legacy to it like Ember.js? I was asking myself these questions about 9 months ago.
2
Add a comment...

Peter Wagenet

Shared publicly  - 
 
 
The big news today was Mark Zuckerberg's excuse that the previous version of their native apps bet too much on HTML5.

I wouldn't call their previous app an "HTML5" app, except pedantically. Making an app that appears native dependent on the server for new UI is performance suicide. You can get away with it inside of a mobile web browser, but if it pretends to be a native app, be damned sure it can respond autonomously.
1
Add a comment...

Peter Wagenet

Shared publicly  - 
 
 
Ember 1.0 RC7 is out now! We're getting close to 1.0!
Ember 1.0 RC7 Released. Posted By: Peter Wagenet – Aug 14, 2013. We're pleased to announce the release of Ember 1.0 RC7 today! If all goes smoothly, this will be our penultimate RC before Ember 1.0. This release includes a number of bug fixes and a few small improvements.
2
2
Add a comment...

Peter Wagenet

Shared publicly  - 
 
 
Awesome pull request just merged into the Ember.js Chrome inspector by Teddy Zeenny. Lots of exciting progress has been made in the past few weeks. If you haven't been following, check it out!
2
1
Add a comment...

Peter Wagenet

Shared publicly  - 
 
 
My Problem With Turbolinks

I made a few snarky comments about Turbolinks recently and figured I should write down my thoughts more clearly.

If you're not aware of Turbolinks, it captures all local links that look like HTML pages, makes an Ajax request for the content, and then replaces the body with the response's body. It does a few other clever things, like extracting and replacing the title, and executing scripts in the response.

Overall, it's a clever way to get some increased speed while still using a traditional server-rendered-HTML architecture.

Caveats

Like any other solution, it comes with some caveats.

Probably the most important one is that normal HTML-rendered pages have their own clean global scope every time a new page is rendered.

This is not a mere quibble: a lot of existing JavaScript operates under the assumption of a clean scope, and a single DOMContentLoaded event. In a perfect world, popular JavaScript plugins would be architected to work well with a solution like Turbolinks, but the assumption of a clean global scope per server-rendered HTML page is baked into a lot of the JavaScript and jQuery libraries that people tend to use.

It is possible to deal with problems like this on a case-by-case basis (see https://github.com/rails/turbolinks/issues/87, for example), but in my opinion, this is going to end up in a game of whack-a-mole as each new patch breaks other valid use-cases.

At the end of the day, unless Turbolinks can perfectly emulate the browser's behavior, attempts to use Turbolinks with third-party JavaScript will either fail often or require an ever-growing library that handles more and more targeted edge-cases.

jQuery Turbolinks (https://github.com/kossnocorp/jquery.turbolinks) is a good example of something that tries to make the solution more transparent,  but introduces problems as it now triggers ready callbacks multiple times, and idempotence is not typically a requirement of ready handlers. I encourage you to review the open and closed issues on these projects to get a sense of the specific kinds of problems that can occur.

The Good

That said, for applications that are willing to carefully think through the requirements of Turbolinks, this solution does provide a nice transitional way to keep building applications without a lot of architectural changes with improved speed.

If you are thinking about using Turbolinks, make sure:

• Your JavaScript is designed to be long-lived across many different
  HTML pages without a refresh
• Your refresh handlers are idempotent. Don't register event handlers
  or other bindings in a refresh handler unless you reliably tear them down.
• You audit all third-party code that you use to make sure that they do not
  rely on DOM Ready events, or if they do, that they DOM Ready events are
  idempotent. If you don't feel comfortable auditing and cleaning up
  third-party code, don't use any. (note that the "turbolinks community",
  such as it is, might vet existing libraries for compliance, and that would
  help).
1
Add a comment...

Peter Wagenet

Shared publicly  - 
 
One of the major complaints against Ember is that it's too complicated. Does Ember have complexity? Certainly. But before you can determine whether something is too complicated, you need to know what it's for. A tool that seems too complex at the start may become indispensable once one understands how to use it.

To consider a rather mundane example, I recently bought an $80 leaf blower for my townhome's small backyard/patio. Now certainly, this is too complicated and expensive a tool for this use. I mean, a $10 broom would be much better suited for this case, wouldn't it? However, there are two trees that drop a lot of leaves in my patio, there is also a significant amount of landscaping. The leaf blower also has vacuum functionality that means I can easily suck up leaves and a metal impeller that won't be damaged by the frequent sweet gum seed pod and occasional rock. As it turns out, using the leaf blower, I can clean my patio much faster and much better than I could ever do with a broom.

I still own a broom. I use it for cleaning indoors. If my patio was just a concrete slab, I'd use it to clean out there too. The point is each tool has its place. Don't shy away from a tool just because it seems too complex at a glance. Understand why the complexity exists and maybe you'll see that it's more appropriate for your problem than you thought.
7
2
Alan Baker's profile photo
 
That's a good offline example. I like to look at it in more simplistic terms, if I'm making a website vs. an application.

If I'd jump from a form view to a friend view to a contact view, fine, something simpler is excellent. Let's say I want to make a desktop style application that takes me from a form to a contact, but in between I'd see friends in common with alternate views of similar interests and related schedules... I'd use Ember.

When we look at how the internet is evolving, our interactions continually become closer to how we expect in everyday life. Ember is shaping up to fit that need online.
Add a comment...
Basic Information
Gender
Male
Links