Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm a full time engineer on the web and I don't really agree with this. I much prefer working with Chrome than any other browser. Even IE edge (supposedly Microsoft's fresh start) doesn't have all the full support for various features as Chrome does -- just head over to look at the comparison tables at caniuse (ex: http://caniuse.com/#search=blend-mode).

And the developer experience in other browsers (save for maybe Firefox) are vastly inferior to Chrome's dev tools. Firebug in firefox used to be the best, but even with Mozilla's new efforts at the developer edition of Firefox, the experience is still poor. Lack of correct support for sourcemaps, performance, and general UI polish of their tools are still lacking.

Another point I feel should be made is that IE still doesn't have a native Max OS or Linux release. This is an embarrassment to Microsoft, and its why I still don't take anything they do seriously on the web. If you're going to create a new browser, you should at least make it accessible to most of the devs -- many of whom don't even use your OS anymore.

Chrome also has a few very useful projects, such as Chromium, node webkit and Electron (what slack uses). Where is this kind of support from the other browser vendors? Why doesn't Apple have a fully integrated native browser development envrionment for Safari? Why did Mozilla's FireFox OS die on the vine and why haven't they come up with something like Electron? The executives and senior technical leadership at these projects and companies should be embarrassed.



> Why did Mozilla's FireFox OS die on the vine and why haven't they come up with something like Electron? The executives and senior technical leadership at these projects and companies should be embarrassed.

That's more than a little hyperbolic, given that Electron and node-webkit aren't Google projects and are in fact coded to an API Google explicitly considers unstable and liable to break at any time.

Disclaimer: I'm probably included in the group of people you claim "should be embarrassed".


When last I was looking into this, Chrome's embed API is much better documented and supported than Gecko's. It seems that the Gecko API that does exist is largely due to the efforts the Sailfish OS / Jolly people put into it. Hopefully servo doesn't follow the same path. I'm hoping to be able to get into that code base soon-ish. :)


> When last I was looking into this, Chrome's embed API is much better documented and supported than Gecko's.

Sure, but WebKit2 is better than both, as only WebKit2 is a stable API that is C-based and can be used from multiple languages [1].

> Hopefully servo doesn't follow the same path.

Proper embedding support, with a supported API, is a key goal of Servo.

[1]: https://trac.webkit.org/wiki/WebKit2


It's great to hear Servo is focusing on embedding support. The developers seems pretty responsive to feedback as well, which is great. Thanks for the info on webkit, need to follow up on it.


> doesn't have all the full support for various features as Chrome does

But isn’t that exactly what IE did?

Embrace the standards,

Extend the standards with their custom things – be they ActiveX, Silverlight, or NaCl

Extinguish the competition.


Yeah? And what "custom extensions" does Chrome push? NaCl is almost dead, to be replaced by the standard WebAssembly. Everything else is a standard ES2015 spec that Chrome, Edge, and Firefox have implemented (to varying degrees) and Safari has thus far failed to implement.


Chrome pretty significantly jumped the gun on shipping Shadow DOM and other Custom Element features unprefixed and on by default two years ago while there were significant outstanding objections from other vendors and no stable spec. We're only just now digging out from that mess.


> Chrome pretty significantly jumped the gun on shipping Shadow DOM

The Atom editor uses shadow dom because Atom is chrome-only. I don't know what is going to happen now that it is deprecated. I see warnings to not use it in the dev console every time I start Atom.


The only objections I remember hearing were from Apple. And implementing something that is in the standardization process with the TC39 still doesn't strike me as "custom extensions".


Their custom behaviour in the JS apis for HtmlMediaElement come to mind.

Half of which plain don’t work, and the other half work on mobile only in onClick handlers.


Dart? They pushed that one reasonably hard until the writing was on the wall.


Was dart ever part of chrome? I didn't follow that closely, seemed like a separate effort from Google.


Dart never shipped to mainline chrome. Developers could download a special version of chrome with Dart.


Additionally, there was the aborted upstream WebKit effort to allow abstraction over multiple languages with the goal of supporting Dart, and the Oilpan effort had Dart support as a major motivation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: