Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSC loves ES6

webkit.org

Post reply on HN
Print view View original

71–80 of 191 posts

Re: JSC loves ES6

#71

Post by pfooti »

threeseed wrote: post #54
pfooti wrote: post #33

It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari. I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in…

Service workers are an anathema to everything Apple is trying to achieve with Safari and I would be shocked if it ever gets included. Their focus is on improving battery life, having a great user experience and maintaining a high level of privacy and security. Service workers are awful for all three. For example look at what you have to do to see running service workers: Developer Tools > Application > Service Worker…

Something here about babies and bathwater. Service workers are pretty limited in what they can do.

Is there UX work to be done? Sure. But the fundamental problem is that they fill a need that is not met at all by Apple, and not even in a silly "use metal instead of vulkan because reasons" kind of NIH but we'll support some other similar standard fashion, but in a "nope" way.

So, kudos for the speedy es6. I'm still not going to tell people to use safari on macos, and I'm still going to build crazy DIY caches for safari on iOS because I can't do stuff with service workers in a standardized way.

Re: JSC loves ES6

#72

Post by pfooti »

pizlonator wrote: post #43
pfooti wrote: post #33

It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari. I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in…

ES6 features are faster when natively supported and natively optimized like in JSC.

Yay. Now let me build a progressive web app for iOS and I will care about javascript perf on that platform.

Speed is great and all, really great for some people. I just wish they had different priorities.

Re: JSC loves ES6

#73

Post by vosper »

chc wrote: post #42
jonas21 wrote: post #25

Earlier quoted context omitted.

On the other hand, it's not like Firefox is the side project of a few of people in their spare time -- the Mozilla Foundation has annual revenue of over $400 million! [1] https://en.wikipedia.org/wiki/Mozilla_Foundation

$400 million looks like a lot until you remember that Apple have $267 billion in cash reserves. The Mozilla Foundation's entire annual revenue isn't even a fifth of a percent of what Apple have just sitting around because they can't find a better use for it. The fact that Mozilla are able to punch even this far above their weight is kind of impressive.

But Mozilla really only has one big thing they make, which is Firefox. Apple's software portfolio on just one of their multiple hardware platforms (let's not forget that they make that hardware, too, including designing their own processors) completely dwarfs Mozilla.

I agree with jonas21 - for $400m a year you ought to be able to build an amazing browser.

Re: JSC loves ES6

#74

Post by douche »

fooey wrote: post #64
kenneth wrote: post #51

Earlier quoted context omitted.

We shouldn't be migrating Electron to anything… we should be getting rid of it. Electron is a cop-out for mediocre dev teams to make mediocre desktop apps. The result is a world where we run apps like Spotify and Slack are the main battery-killers because their engineering teams were too lazy to make a real native app.

You assume that if there wasn't Electron that those apps would exist at all.

Maybe if they can't invest in proper native apps, they shouldn't exist. Electron is a scourge - clock speeds are not getting any faster, and tying a user application to a single-threaded execution model would have been recognized as suicidal a decade ago.

Re: JSC loves ES6

#75

Post by bla2 »

pizlonator wrote: post #43
pfooti wrote: post #33

It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari. I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in…

ES6 features are faster when natively supported and natively optimized like in JSC.

That's cool, but it feels a bit like making sure your room is tidied up while your house is on fire -- it's not clear it's the most pressing priority.

But webrtc support is cool.

Re: JSC loves ES6

#76

Post by int_19h »

vmasto wrote: post #53
ergothus wrote: post #34

Earlier quoted context omitted.

I'm a touch confused...are you saying that if everyone used the year-based nomenclature, the inconsistent support would go away? Today in 2017 I have some ES6/ES2015 features I can use as well as some ES7/ES2016 features, but there are also other ES6/ES2015 that I can't count on being supported, and quite a few ES7/ES2016 features I can't count on. How are these problems alleviated if we change the name we use? Or ha…

Just talking about the name. You can see how this is confusing, here's a recent one just from today by Craig Federighi https://twitter.com/feross/status/871839072590979076

I'm pretty sure this ship has sailed for ES6. It's been referred as such while it was in development for so long, it's here to stay.

The next one might be different. But they really need to come up with a better than than "2017" or whatever. There's no similar problem with C or C++, and that's likely because they use 2 digit years, not 4 digit - C++17 isn't super short, but it's not a mouthful.

Re: JSC loves ES6

#77

Post by rspeer »

drdaeman wrote: post #66
ergothus wrote: post #16

Earlier quoted context omitted.

ES6 is 3 syllables. ES2015 is 6 or 7 (depending if you say "twenty fifteen" or "two thousand fifteen"). I'm a dev. I'm lazy. I have no particular objection to the idea of moving away from ES6 as a name, but if the new name isn't more useful, it's not going to gain any ground.

Why not just call it ES'15 when spoken, and write as ES2015? Just like we do with years. "Fifteen" isn't much worse than "seven" and this won't be an issue until for another 80 years.

Because that's yet a third set of numbers referring to the versions, adding to the confusion, especially because it sounds kind of like the series of numbers it definitely isn't.

When you speak it, nobody can hear the apostrophe.

Re: JSC loves ES6

#78

Post by pizlonator »

bla2 wrote: post #75
pizlonator wrote: post #43

Earlier quoted context omitted.

ES6 features are faster when natively supported and natively optimized like in JSC.

That's cool, but it feels a bit like making sure your room is tidied up while your house is on fire -- it's not clear it's the most pressing priority. But webrtc support is cool.

My house is definitely not on fire. That much I can tell you.

My room, on the other hand, is definitely not tidy. Haven't cleaned that shit in ages.

Re: JSC loves ES6

#79

Post by kevingadd »

Androider wrote: post #41
kevingadd wrote: post #23

Earlier quoted context omitted.

A vendor is always the fastest when they roll out a new benchmark. It's disingenuous to suggest a browser is '3-6x slower' based on a score on one benchmark, when all the vendors actively compete on and optimize against a large set of benchmarks, and compare each others' performance numbers on individual tests to understand engine weaknesses/strengths. fwiw, Chrome, Firefox and Safari have all been fairly competitive…

The performance difference I see with my own app with Firefox is exactly the benchmark's 3-6x, that's not a benchmark but real world usage. It's enough to make the startup feel slow (3-4 seconds of being unresponsive) and things like animations and drag and drop features to feel janky. Running a non-minified build (about 20MB of JS, minifies to about 1MB) also completely murders Firefox reducing it to a slideshow, ma…

If your app is 3-6x slower overall in Firefox to the point of animations & dragging being slower, and to the point that non-minification makes it slower... something is wrong with your app. Animations are generally the work of the layout engine and compositor, which is absolutely not going to be impacted by jsc's latest JS optimizations, or by ES6 features.

For one thing, minification's impact is largely on parsing, so it shouldn't have any noticeable impact on anything other than startup time and memory usage (the compressed JS source for Function.toString will be a bit smaller if minified). If your app is really slower at runtime when not minified, again, something is wrong.

Is your application written in raw (non-transpiled) ES6 and heavily using generators, async, tail call opts etc in tight perf-sensitive loops that run on the main thread without yielding to the event loop? It's hard for me to come up with a scenario where you could see such a huge performance gap in a well-constructed application.

If computational performance is really important to you, then you're writing asm.js (or webassembly) and shipping that. All of the modern JS engines perform great on that sort of code and you simply cannot see a 3-6x gap there. So something weird is going on with your app that any vendor would be happy to fix if you sent them a repro (or just let them try out your app).

Re: JSC loves ES6

#80

Post by alwillis »

zajd wrote: post #48
pfooti wrote: post #33

It seems weird to focus so much on es2015 features, when so many of them are polyfillable (not optimal, sure, but still) when there is such uneven support for DOM (and related browser) API features in safari. I mean, where are service workers? Give me a nice, cross-platform way to handle offline-first and I'll be happy. But hey, it isn't like there's some kind of browser monopoly on iOS or anything, like there was in…

I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications.

I'm pretty sure Safari's features are intentionally crippled to keep their app ecosystem safe. See: web notifications.

I’m pretty sure you'd be wrong. Apple announced that it's paid over $70 billion to app developers since the App Store became a thing in 2008 at today's WWDC keynote. This is the 30% Apple pays developers; so we're talking about $233 billion in gross transactions in less than 10 years.

Apple is likely to be the first trillion dollar valuation company; I seriously doubt it's worried about web apps encroaching upon a fairly small part of it's revenue: http://fortune.com/2017/03/31/apple-trillion-dollar-company/

Post reply on HN