141–150 of 191 posts
Given that other languages mandate that additional features have zero overhead if unused, this seems like a particularly bad way of evolving a language.
Earlier quoted context omitted.
But ES6 Map/Set is almost useless as it has no custom hash nor equality function. The key is either numeric, string, or object identity, not anyway better than the builtin {}.
I've found them to be useful when I write ES6 code. I agree that custom hash and equality functions would make these classes a lot better.
Earlier quoted context omitted.
> 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…
A complaint you haven't seen, however, is lack of ES6 support - which means it's still baffling that there's so much focus on that. (That said, the complaint was always lack of WebRTC and ServiceWorker support.)
You have a source for that? To me nobody really started caring about ServiceWorker until the big push recently for PWAs w/ launch of Lighthouse etc. Whereas devs have always wanted browsers to keep up with JS/ES/CSS language standards.
Also "development doesn't really work like that". Who's to say the same devs implementing ES6 features could take on ServiceWorker. Maybe there's something in the codebase blocking ServiceWorker. You just don't know. Assuming one thing is being neglected in favour of the other is a huge assumption.
I feel like the internet getting angry that 'feature 1' is released whilst the 'feature 2' they want isn't, and being all 'why are they spending all their time on feature 1 instead of working on my thing' is such an old trope there should be a term for it.
(But yeah I'd like to see ServiceWorker in Safari too, though please let's not bite the hand that feeds)!
Earlier quoted context omitted.
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.
I'm not entirely interested in relitigating a past I literally lived through. 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 domin…
Earlier quoted context omitted.
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,…
No wonder people move to other browsers instead.
Earlier quoted context omitted.
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 has had them for a while. Supposedly they just hid them behind a flag because they weren't satisfied with some perceived deficiencies in the spec. (Check out https://v8project.blogspot.com/2016/04/es6-es7-and-beyond.ht... ) WebKit did have it somewhere between mid-October to early December of 2015. ( http://web.archive.org/web/20151207203829/http://kangax.gith... ) Chrome didn't get it until late April of the…
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.
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…
> Now it's here and there is a new complaint /s
WebRTC is 6 years old and it's been implemented in Firefox and Chrome for 5 years now ! Since then there's plenty of other DOM API that where introduced and are not supported in webkit, for instance :
- service workers
- push API
- Fetch API
- User Timing API
- Subresource Integrity
On the JavaScript side, the JSC team has been doing a great job for the past two years, leading the way in term of performance and ES2015+ support, but on the DOM side, Safari is really lagging far behind (which is, I guess, probably because they don't want the compete with there native mobile apps).
Earlier quoted context omitted.
I think that's a shortsighted way to look at it. The iPhone is as successful as it is because of the perception of exclusivity - the best, newest apps will always be on iPhone first. Whether they are free or cost $100 each doesn't really matter that much - it still means Apple is the premier mobile device bar none. If they enabled more progressive webapp features, we'd start to see a lot more cross platform webapps.…
The iPhone is as successful as it is because of the perception of exclusivity - the best, newest apps will always be on iPhone first. That argument might have worked in back in the day when the iPhone was only available on AT&T but not in a world where the iPhone is available to more people than it ever has been before. The iPhone is perhaps the single most successful product ever, with over 1 billion sold: http://ww…
The iPhone is incredibly expensive. While you and your rich software developer friends might have iPhones, the vast majority of phones sold are not iPhones. They're Android phones. You can get an Android phone for $50 or less. You cannot get an iPhone for much under $1000 in NZ.
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…
I used to work on an app that was 5 to 10 times slower in v8 than in SpiderMonkey, was it a proof that v8 was slower than SpiderMonkey ? No, we were actually falling in a v8 slow path (using exceptions in a hot section of the code because babel was transpilling `for of` loops to something that used exceptions), after some profiling we found the culprit and fixed it.
When you hit a 5x differences in JavaScript speed, it's almost never a browser performance difference, it's a bug in this specific browser : you're probably hitting a slow paths in this engine and you can probably work around it (or report a bug and wait until they fix it).