| 01:00 | <bkardell> | Ah apparently i was searching with... Not Google 😊 |
| 01:08 | <sideshowbarker> | for users and developers, we definitely have regressed from what could be done easily with Flash |
| 01:09 | <sideshowbarker> | …for that class of web content that was being produced with Flash — that timeline-based experience |
| 01:11 | <sideshowbarker> | which is admittedly only a subset, and different from a full “app” experience the way that mobile apps provide |
| 01:11 | <sideshowbarker> | but the web losing Flash was not a win for end users and developers |
| 01:12 | <sideshowbarker> | Flash enabled a lot of people to develop content without needing to be “coders” — the tooling made it easy for them to create content |
| 01:13 | <sideshowbarker> | and they did it on scale, and users on scale liked the experience it provided |
| 01:16 | <sideshowbarker> | And it had ubiquity all the way up until the first iPhone came out — on which even Safari was just barely even usable running on the iPhone on its own. And so it just literally wasn’t feasible to have the Flash runtime also running on top of the browser runtime in Safari on the first iPhones |
| 01:16 | <sideshowbarker> | And so Flash lost the key property of ubiquity it’d had until then |
| 01:55 | <sideshowbarker> | I’ve been thinking back to 2004–2005 when Flickr and other such sites first launched, and I was still working at Openwave and we had a mobile browser |
| 01:57 | <sideshowbarker> | once I learned that XHR was what those sites were using to make the user experience they gave, I remember talking with people on the browser team and saying to them, Well, clearly now we really need to enable XHR in our browser |
| 01:58 | <sideshowbarker> | But there response at the time was, No, we really don’t, because what we have now is working |
| 01:59 | <sideshowbarker> | And they were provably right when they said that, because our browser (EZWeb browser) was shipping preinstalled on literally millions of browsers in Japan, and that browser was solving problems for literally millions of people in Japan who were using it every day to do all kinds of things |
| 02:00 | <sideshowbarker> | And we were making great money from it all |
| 02:00 | <sideshowbarker> | But my feeling was still, we can do better than this |
| 02:02 | <sideshowbarker> | The browser was well designed, and worked with content written in XHTML and CSS, not just WML — and it even had scripting. But it wasn’t JavaScript — it was WMLScript instead |
| 02:06 | <sideshowbarker> | And I remember people from the browser team patiently telling me that, with just our current stack, we could actually enable developers to create richer user experiences of the kind that were coming out in sites then, in 2004 and 2005 — that it in part, just needed developers to start doing some things differently and better (and providers buying more of our server products) |
| 02:07 | <sideshowbarker> | And then into our market came the full Opera browser shipping preinstalled on just one phone, labeled as “PC Site Viewer” — and users in Japan could then, on their mobile phones, access real full web content, from real web sites |
| 02:09 | <sideshowbarker> | with some XHR support in the browser |
| 02:09 | <sideshowbarker> | but for us at Openwave, enabling XHR meant adding support for JavaScript to the browser, switching from WMLScript to JavaScript |
| 02:12 | <sideshowbarker> | but the company just did not at all have the economic incentives to invest in doing that — we already had the customers shipping our browser on millions of devices, we had a huge number of developers creating content that worked well in it already, and we had millions of users already using it |
| 02:13 | <sideshowbarker> | and the browser PMs and engineers just saw no good strong need for it |
| 02:13 | <sideshowbarker> | …and that’s when I left and went to work at Opera |
| 02:16 | <sideshowbarker> | among the great things at Opera was that among the engineering team and QA team the default attitude really was “we can do better than this”, and they were wiling to try out some risky, nutty, unproven ideas — and the company management then really supported that (all the way up to Jon von Tetzchner and Haakon, especially) |
| 18:30 | <wanderview> | Is there a canonical way to go from a Navigator to the environment settings object that contains it? |
| 18:44 | <wanderview> | I guess I want relevant settings object |
| 18:59 | <Matthew Phillips> | So the cost of doing it all natively, vs wrangling the web into doing it when you're trying to tweak things at a level below the primitives it naturally exposes, just leans pretty heavily towards native, and that's not unreasoanble. |
| 19:00 | <TabAtkins> | I'm saying that the cost of reproducing those, compared with the cost of losing the rest of the web platform, tilts the economics pretty decently toward "do it yourself in native code" |
| 19:00 | <TabAtkins> | You just don't need much of the web platform in an ereader |
| 19:01 | <TabAtkins> | But you do need pagination and better text layout, which the web platform doesn't provide and doesn't give you the primitives to reasonably do yourself. |
| 19:01 | <Matthew Phillips> | No, but building a full ereader from scratch in native is more complicated than building a pagination widget in JS, no? |
| 19:02 | <TabAtkins> | That one bit, yes. There's more that you end up needing to reinvent. |
| 19:03 | <TabAtkins> | Other things I mentioned above: drm (and its precursor, dependable local storage) |
| 19:04 | <Matthew Phillips> | Ok, so things that are possibly fixable. |
| 19:04 | <TabAtkins> | Everything's potentially fixable, yeah |
| 19:05 | <Matthew Phillips> | But small things in comparison to the "reinvent the web on wasm" idea :) |
| 19:05 | <TabAtkins> | It's just that several of them aren't high-prio (or even perhaps medium prio) for web content as it exists today, so making the argument for working on it (specs and impls) isn't easy. |
| 19:05 | <TabAtkins> | Different people are reinventing the stuff in that case, with different incentives. ^_^ |
| 19:08 | <Matthew Phillips> | The upside here is potentially huge though. Inventing an ereader in native is a lot of work. So much so that only a few companies have ever even tried. The web is close here. And the upside would be that publishers could avoid the Amazon tax. |
| 19:09 | <Matthew Phillips> | So what is it about payment? Is it just the friction (which presumably web payments removes) or is it something else? |
| 19:10 | <TabAtkins> | Payment's gotten a lot better in the last few years! It was still pretty bad even five years ago. |
| 19:10 | <TabAtkins> | Tho the app stores getting more aggressive with their cuts make the friction argument less and less relevant to the bottom line. |
| 19:11 | <TabAtkins> | Like, the Nook app on Android no longer lets you buy books in it (because they'd have to give 30% of the price to Google). All you can do is wishlist, then they'll link you to the b&n website to actually buy it. |
| 19:11 | <Matthew Phillips> | Does Google take the same cut from web payments? |
| 19:13 | <TabAtkins> | Surely not; the CC processers would scream bloody murder and they're a powerful mafia. |
| 19:13 | <TabAtkins> | But I don't know the details. |
| 19:13 | <Matthew Phillips> | Comixology (Amazon company) had to do the same thing in their Android app. It makes the experience really bad. Feels like an opportunity for the web. |
| 19:14 | <Matthew Phillips> | ok, that makes sense, i was thinking that web payments had the same UI overlay as native but that doesn't mean that google is taking a cut |
| 19:20 | <Matthew Phillips> | So if we were doing a list:
|
| 21:57 | <zip> | DRM: Remove |