61–70 of 191 posts
Earlier quoted context omitted.
Chrome and WebKit are two different things. So, no, you didn’t just say that.
He said that chrome and Firefox had everything except for tail call optimisation earlier.
I am now in agreement with everything you said. Thanks for clarifying.
I really wish we would stop calling it ES6. Browser vendors should be especially careful to call ES2015 by its correct name and help stop perpetuating the confusion (ES6, ES7, ES2016, ES2017, you can see how this quickly gets confusing).
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.
Earlier quoted context omitted.
$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.
1) Apple's cash assets aren't actually cash or just a bank account. It's accounting speak for liquid assets. Any investments that they could divest fairly quickly and easily and repurpose to finance other capital expenditures. The money isn't sitting around doing nothing; in the meantime it's invested in a safe portfolio which attempts to grow it. Imagine a hedge fund for just one LP. 2) Apple is a mega-company which…
Right... how does that make it any different?
Apple's not a finance company, or at least they weren't until they wound up with so much cash they had no actual present business needs for. If you're a hardware/software company that has so much extra money (billions) that you become your own 'hedge fund' to have something to do with it... yeah, you've got a lot of extra money. How much extra money? More than 500x the annual budget of Mozilla, yup.
Another great reason to migrate Electron to WebKit. With WebKit and JSC Electron will be faster and will use a zero amount of RAM and battery!
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.
I really wish we would stop calling it ES6. Browser vendors should be especially careful to call ES2015 by its correct name and help stop perpetuating the confusion (ES6, ES7, ES2016, ES2017, you can see how this quickly gets confusing).
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.
But hey, this is Apple which often insists on giving their OS releases both a number and a name and referring to them by each in different places (but hardly ever using both name and number at once), so. I feel like if I were able to tally up all the minutes I've spent cross-referencing "Wait, so 10.6, which one is that? Wait, so 'Leopard', which one is that?", it'd be depressing.
I really wish we would stop calling it ES6. Browser vendors should be especially careful to call ES2015 by its correct name and help stop perpetuating the confusion (ES6, ES7, ES2016, ES2017, you can see how this quickly gets confusing).
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.
"Fifteen" isn't much worse than "seven" and this won't be an issue until for another 80 years.
Earlier quoted context omitted.
Just Chrome, but yes: http://web.archive.org/web/20160303192336/http://kangax.gith...
That shows WebKit supporting tailcalls. It doesn’t a show Chrome supporting tail calls. I vividly remember us implementing tail calls and v8 not having them yet at that time. This was almost 2 years ago.
Chrome also had a failing array prototype under some non-standard syntax for a while. Despite claiming 100%, Kangax didn't show them passing. Test results have fluctuated as the tests themselves were refined. I've seen some passing results later turn into fails. That's why none of the browsers are at 100% for ES6 currently.
I'm still grudging at Apple for the year's delay between Safari 9 and 10, which left all the clueless Apple customers on ~53% ES6. Yes, WebKit had regular updates, but they didn't do a gradual release and few people thought to install WebKit instead of Safari (or even the TP). Other browsers had much better beta channels than Apple. And didn't pointlessly delay on things like WebRTC. Or block other browser engines like iOS to protect their app store.
Chrome did a good job of releasing updates gradually, but there are still some ES6 performance issues to be ironed out.
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 mean, where are service workers? Every discussion about anything in Safari on HN, even if not at all related, for the last year or two has included multiple people complaining about the lack of WebRTC. Now it's here and there is a new complaint /s I agree with threeseed that it probwont come and frankly I don't see why I'd want it (or web notification, or even WebRTC). They only seem to support the use case of re…
The general point isn't about any one feature in particular. It is about a history safari has with not implementing (or half-heartedly implementing, as with indexeddb for so long) APIs that are important to making the web a useful platform.
Reasonable people can disagree whether or not those features are good, but it seems basically true that my mobile web work is constrained by what iOS safari outright refuses to do, more than anything else.
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…
There never was a browser monopoly on Windows just a bunch of tech illiterates who don't seem bothered by MS's "monopoly" with notepad.exe or anti-competitive moves like taking away the ability to use an alternate graphical shell. Only one popular consumer OS has prevented the installation of alternate browsers and everyone looks the other way.
On the other hand, it is objectively true that there is only one browser platform for iOS. WebKit or nothing. If they actually supported chrome or Firefox instead of requiring them to be wrappers on webkit renderers, I would not have this complaint.
Of course, the reason this isnt being taken up by anti-trust folks is that iOS doesn't dominate the market the way windows did. So: i guess the answer is to convince my users to stop buying idevices. Whee.
I really wish we would stop calling it ES6. Browser vendors should be especially careful to call ES2015 by its correct name and help stop perpetuating the confusion (ES6, ES7, ES2016, ES2017, you can see how this quickly gets confusing).
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.