621–623 of 623 posts
Earlier quoted context omitted.
Are you asking how going to a URL is different from installing an app?
With all the features being added to the Chrome Platform recently, given the trajectory Google is heading along with web applications, absolutely yes.
Earlier quoted context omitted.
Thank you. I have no idea what these people are talking about. They obviously didn't actually do development back then. > Apple took years to finally add WebRTC support to Safari, far enough behind Chrome and Firefox that it practically became a running joke among developers and even industry observers. Really? Because no one I know uses WebRTC and would rather use ffmpeg and sockets to do serious work like that over…
> Apple took years to finally add WebRTC support to Safari, far enough behind Chrome and Firefox "Far behind Chrome" should never be used in a sentence. Ever. Chrome releases up to 40 new "standard" features once every two months, many of them are just internal Chrome APIs with a "standards spec" in the form of a draft. Specifically for WebRTC. It was shipped in Chrome 23, in May 2012. Guess what? Here's the timeline…
your timeline, to me, indicates less that the spec was rushed & bad, and more that it took apple 5 years to get off their hostage taking kick & finally face the music & do what should have been done years ago, which is implement. once apple did start to implent, 1.0 came soon after: because that is how specs work. companies implement, they find what's not right, & they improve, then make a 1.0.
I would definitely be interested in a changes over time review of webrtc. my feeling is that the core ideas & protocols were largely stable, but needed tweaking & elaboration, needed conformance suites elaborated. I could be wrong. this is in contrast to something like spdy, which evolved seemingly a good number of times in major ways, before ultimately getting parlayed into quic+http3.
Earlier quoted context omitted.
The fewer features the browser has, the more code ends up as native apps or on cloud backends instead of the user's device. How many IoT devices could have just used bluetooth for interactive with them, but instead they all phone home to some central cloud server because the user experience of just hitting a web page is better than installing some clunky native app. Should we "just go ahead" and expose everything? Of…
> But there's room for thoughtful implementation of these features that users want. Yes, there is. And that's exactly the position of both Firefox and Safari: don't rush in and implement stuff just because you can.
It needs to be thoughtful, but the firefox position appears to be that web apps have no business accessing bluetooth or usb. Which as I explained earlier leads to user installing clunky native apps to interact with their bluetooth/usb gadgets, or the gadgets being deployed with phone home functionality so that user can still access them through a web portal.
If firefox wishes to remain relevant they're going to have to implement the things that developers and users want. Nobody wants a dumb document browser anymore, that ship has sailed. Browsers are a ubiquitous application platform.