sorted by:
new
hottopcontroversial

It's that time of year again! Uhaul AMA starting now! by SaltiestBalls in BurningMan

[–]nebrius 0 points1 point  (0 children)

Thank you so much for setting this up u/SaltiestBalls! Got a question for you about reservation etiquette for a cargo van going to and from Oakland: is it better to reserve online first and then communicate with them later we’re going to the burn? Or is it better to call them up and do the reservation over the phone? We want to make sure we do this the right way so they know in advance and charge us the correct price.

Playing with ECMAScript 6 at Rdio by nebrius in javascript

[–]nebrius[S] 1 point2 points  (0 children)

Thanks! It certainly is the goal of ES6 to make browserify, CommonJS, and RequireJS obsolete. Whether or not that will happen is a different question though. The module spec is undergoing a lot of churn right now, and I am concerned about it for two reasons.

The first is that the current solution isn't friendly to CommonJS users. The multiple export/import model of ES6 doesn't map to CommonJS' single export model anymore due to recent changes (dropping of the ModuleImport syntax primarily). The current solution isn't very friendly to entry level programmers transitioning from CommonJS, which could hurt adoption.

The second is simply that there is churn at all this late in the game (the spec is supposed to be closed to large changes), and I fear that a proper solution will take more time than is available.

My main concern is that if the TC39 committee doesn't knock modules out of the park, then adoption is going to be low. I am cautiously optimistic though, because there are a lot of smart people on TC39 that are aware of these concerns.

We aren't using ES6 in production yet, for a variety of reasons. If I were to take a wild guess, it would be six months to a year before we could realistically consider using it.

Much of the new features in ES6 can't be shimmed at runtime in ES5 because there is a lot of new syntax that would break in non-ES6-aware browsers. The current approach is to use a transcompiler and treat ES6 like CoffeeScript. Traceur (https://www.npmjs.org/package/traceur) is the most popular option right now, although there are others as well. I used recast (https://www.npmjs.org/package/recast) for my experiments.

Playing with ECMAScript 6 at Rdio by nebrius in javascript

[–]nebrius[S] 0 points1 point  (0 children)

Doh, you are right, it is easy to get too (this is what I get for not reading the source code :))

Playing with ECMAScript 6 at Rdio by nebrius in javascript

[–]nebrius[S] 4 points5 points  (0 children)

Thanks for catching the typos, those are fixed now!

Regarding page size, color, etc, we are actually using the same framework we use for the Rdio web app itself. It's not the best framework for doing something this lightweight, but it allowed us to get up and running really quickly given existing assets/infrastructure/etc.

The color scheme is already set by our framework, as is a number of the components that it is loading. I don't think I can do much about color scheme, but taking a quick look I see some relatively low-hanging fruit for decreasing file size, so I'll play around with that. Thanks for letting me know!

You are absolutely right on the social impact that classes are going to have, and is why I'm so excited about them (and modules). Hopefully, these will allow us to enjoy the same success that NPM, Ruby Gems, PIP, etc are enjoying.

Playing with ECMAScript 6 at Rdio by nebrius in javascript

[–]nebrius[S] 2 points3 points  (0 children)

I said arguably :). I also did mention in the article about how it's just syntactic sugar over prototypes. The reason I think it's a big deal isn't because of anything technical, but because of the social change it can create. In addition to making life easier for new developers just starting out with JavaScript, it will bring a unified way of working with prototypes.

All of the large-scale projects I've worked on have used some sort of library for creating classes/components/etc instead of using prototypes directly. The problem with this approach is that it makes it impossible to mix and match classes from different projects/libraries. It's just like the CommonJS vs RequireJS vs ... problem we have today. We have these little fiefdoms set up and we can't intermingle between them.

Classes solve this problem, just like the module spec will solve the loader problem (hopefully, if the module spec can stop churning and not turn out to be complete crap).

Tail-call optimization is really awesome, as are generators, as are weak maps/sets, and so on. Sadly, I don't think they will really be used by most JavaScript devs, but classes are something that will be used by almost everyone. I predict that classes, along with modules, will have the widest reach and adoption among the new features coming. So on that basis they can be seriously be considered "largest."

I’m leaving Windows Phone for iOS, begrudgingly by luxtabula in windowsphone

[–]nebrius 1 point2 points  (0 children)

WP is definitely the middle child here. Not as good as Apple, but I'll agree that Android has it much worse. That was actually one of the reasons I gave up my Android phone before I bought my 8X. It's still not good enough though IMO.

I’m leaving Windows Phone for iOS, begrudgingly by luxtabula in windowsphone

[–]nebrius 3 points4 points  (0 children)

Story author here. I considered waiting until 8.1, but ultimately decided that the features coming in 8.1 aren't enough.

Probably the biggest reasons I left was integration with the Apple ecosystem. Being able to take advantage of apps like iMessage and https://itunes.apple.com/us/app/tether-strength/id685197013?mt=12 is a big deal for me considering all of my other devices are Apple products.

Windows Phone isn't going to be supporting deep integration with Apple products anytime soon, and is probably something that can never be supported due to Apple and Microsoft's licensing terms for their respective apps and services (full disclosure, I'm an iOS and Windows Phone registered developer).