[ecmascript] Meteor core in ES2015 and advice for packages developers


#1

Hi, I have few questions regarding the ecmascript package coming with 1.2 release of Meteor.

  1. Are you planning to rewrite most of the Meteor core to use ES2015?
  2. What advice do you have for developers creating packages in terms of using ES2015. In my two packages ReactiveMap and Astronomy I use some workarounds to support old browsers. In my situation, it’s defining setters and getters using Object.defineProperty method. As far as I know there is no polyfill for that feature. In the ReactiveMap package I’ve decided to replace size property with the size() method to make it reactive. In the astronomy package I’ve introduced the Astro.config.supportLegacyBrowsers flag that changes the way Astronomy behaves. Should I support older browsers?
  3. In many new libraries, developers don’t care about old browsers. Let’s take PIXI.js 3.0 as an example. The authors use the Object.defineProperty method extensively and thanks to that they force people to use newer browsers. For how long are you planning to support old browsers? As a company that may change a lot in the Web, you should promote the newest standards. But by supporting old technologies we won’t move far away from where we are now.
  4. Do you have any feedback on how many developers want support for old browsers?

#2

I think the browser landscape is bound to change with Microsoft’s windows 10 free upgrade strategy.

There of course are enterprises with tens of thousands of computers running IE8 or even Windows XP. I had a client who until last year responded our inquiries with comments like “we allow modern browsers in our company, we have firefox 4”

Thinking of underdeveloped countries, if your geographical target includes them, well then yes there’s also another valid concern there.

Yet I’m hopeful and what I choose to do is (except for the big-buck enterprises) bluntly and blatantly redirect old browsers to http://outdatedbrowser.com/ so that they know their options, what they are missing out on and download a modern browser.

My reasoning is, if I’m developing a modern app with some modern tech stack, the audience will most likely be users of modern tech, or at least have access to it.

In the case of enterprises, I consider a target browser as part of the spec, so if it is IE8, then IE8 it is. Only that I inform them that their going to get older tech from me as well and that it will also cost more.


#3

Maybe he just left out the 0 at the end :wink:

IMUO (U - useless, unimportant), alot of small dev houses cannot afford to support older versions of software. Certainly in the last place I worked, they were supporting IE6, but their main dev left to work on newer stuff and the role was passed to me. Then I left :wink: for a unrelated reason of course.

Meteor attracts the startup crowd. Large conglomerates who have teams of people working on just the backend, rooted in 15+ yr old technology has to bear the burden of their clients being on IE6. I truly hope Meteor doesn’t waste time adding on the burden before adding other features that enable small and agile and newer teams to get their product to market.

Angular2 or IE6? Let’s vote… :stuck_out_tongue:


#4

Well, the interesting thing is, Meteor is certainly on the enterprise radar, check this out:

and the first 5 hits from ibm.com for this search:

https://www.google.com.tr/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=IBM+meteor

I think enterprises are suffuring from being over-bureaucratically disjointed between their IT project and IT support/devops departments. The project devs certainly want to go new and shiny while the support/devops guys love their windows xp clients, as/400 mainframes and windows 2003 servers. I thinkt that’s what’s holding enterprises back.


#5

Geez, talk about a paywall on your first link


#6

Ahaha, well, that’s gartner and they earn money by releasing reports on enterprise trends. They are very successful in predicting the future and well worth the money, though :smile: