HN Gopher Feed (2017-10-28) - page 1 of 10 ___________________________________________________________________
I Watched All of the Chrome Dev Summit 2017 Videos
133 points by fanf2
https://redfin.engineering/i-watched-all-of-the-chrome-dev-summi...___________________________________________________________________
daphneokeefe - 4 hours ago
I attended the event in person, and overall enjoyed it. But I keep
wondering: is the reason Google wants us to squeeze our file sizes
and page load time down to the bare minimum because they want to
maximize the bandwidth available for more and larger ads?
kinlan - 4 hours ago
I can categorically say no, that is not the reason. It's to make
the web experiences better, instant and accessible and available
to everyone.There needs to be pressure on the entire ad industry
(including Google's products) to not hurt the users experience
with crappy and bloaty ads the ruin the hard work product teams
make to build on the web. I do believe (I am biased as I am on
the Chrome team) that the Chrome team want to do the right thing
for the users of the web.
gkya - 4 hours ago
I guess we need a kind of CE mark for websites. Some
standardisation and an approval mechanism for security and
reliability. We wouldn't trust our closest friendss with our
banking accounts but we do use websites without any guarantees
whatsoever. Software that is vital to us (banking, health,
govt stuff) is subject to less regulation than cheese or wine.
briandear - 3 hours ago
And who do you trust to do such certifications? The US
government struggled with what was essentially an easy site
for Obamacare exchanges. State and local governments are
partying like its 1999 for the most part and the ?big?
enterprises like Equifax, various large health insurers,
banks and Yahoo are subject to nearly constant reports of
vulnerabilities and hacks.Really the only people I might
trust would be google, but there is a conflict of interest I
think considering they have a vested interest in enabling
things like tracking.So who does this ?certification??
Hopefully not the same people who call for 8 digit passwords
you have to chance arbitrarily every three months or people
who?s idea of security comes from circa 1996 Microsoft
documentation.
gkya - 3 hours ago
Calm down. I can trust the academicians in the field.
Also the world is more than the US. And I'm fed up with
having to trust my data with possibly/usually incompetent
people (and sometimes one really has to, e.g. my schools
online services). Trained staff and mandatory third-party
security tests are a nice place to commence. It's nice
that on the internet you can hack together a thing and get
going, but it's not one's email address the only thing at
the stakes. I would like to be able to differentiate
between the hack and the proper service. And ATM the only
thing we have is intuition and the https in the domain.
abalone - 4 hours ago
No, it's a much larger existential threat. It because they're
fighting to keep the web competitive with native apps. The more
that the world shifts from the web to native apps, the less
people use their web search engine.
colordrops - 3 hours ago
And yet Google refuses to allow web apps / PWAs on their Play
store.
kinlan - 3 hours ago
We don't refuse or disallow. We just don't take an arbitrary
URL and list it in the store automatically.We announced
Trusted Web activities
https://developers.google.com/web/updates/2017/10/using-twa
which give you a fullscreen surface for web content in an
Android App in the store and allow you to offer more
integration with the Android operating system (protocol and
scheme handling, quick links etc)... I do think this is
interesting, I worked on the Chrome Web Store when it
launched and the number one complaint was that the
experiences "were just bookmarks" and I think Trusted Web
activities give us a chance to experiment with deeper web
integrations on the host platform before we are able to
standardize it.
colordrops - 2 hours ago
Trusted web activity is not the same as a PWA. They are
not cross platform. Why can't PWAs go through a similar
getting process to apps to get onto Play?
kinlan - 1 hours ago
The process of getting apps onto Play, is to create an
Android app... so I'm not clear on what you mean. Someone
will create the tooling that will automatically create
this.Trusted Web activity is just a general way to launch
you PWA fullscreen from an Android actitivy.
dfabulich - 4 hours ago
I agree. Elsewhere in this thread, @kinlan on the Google
Developer Relations team says that their goal is "to make the
web experiences better, instant and accessible and available to
everyone," and that's true, but Google makes money by making
the web better. The more people use the web, the more people
use Google search, and the more valuable Google's ads are.If
the web is slow or unusable (especially on mobile in India, for
example), then Google search is useless on mobile in India, so
nobody will want to buy mobile search ads in India.
microcolonel - 5 hours ago
> It?s difficult to convince to most web developers to accept these
limits, especially if you don?t anticipate selling a lot of
products to ?emerging markets? nations. Hitting Google?s
recommended target often requires a ground-up rewrite, discarding
well-loved JS frameworks.That's why their target for "emerging
markets" devices is five whole seconds of JavaScript compilation,
which would hardly be considered acceptable on a device five times
as expensive, but that device is not five times as fast on a given
core, it's probably something more like one and a half or two,
maybe two and a half if you include faster main memory and
caches.Added: I once worked on an ecommerce site where I told my
team early on that we would probably do worse than we planned if we
built and tested on the latest iPhones and Galaxy devices, and was
vindicated basically every week after a certain point. It was so
bad that, on 802.11ac WiFi connected to a gigabit downlink with
about 15ms round trip latency to the servers, the homepage would
take about 10 seconds to display anything at all on an iPhone 6s,
and another 8 seconds to finish loading the visible content.
Unbelievably, more than three quarters of that time was spent
parsing and compiling JavaScript. You don't even want to know what
happens when you try to open that site on anything slower than a
late 2015 flagship device.
kinlan - 4 hours ago
Did they fix it? Did they care about fixing it?
microcolonel - 4 hours ago
Nah, it's still trash, and they expanded it to more markets!
The good-but-not-great software consulting firm they replaced
us with (lower per-head rate, and they don't question the tech
lead) sometimes still emails me to try to get ideas about how
to fix it, but they never bite the bullet. They're thinking of
doing things which will actually make it even slower and
fatter.This is what happens when you hire people who are
foolisher, lazier, or more short-sighted than you, they rot
your company from the inside out. ;- )
shitRabbits - 7 minutes ago
This comment depresses me. It just sounds like everyone had
no experience and just threw their hands up and said fuck it.
Cacti - 38 minutes ago
Man, thats like the past decade in a nutshell.
pryelluw - 1 hours ago
After hurricane Maria hit Puerto Rico, I had to drive 15 minutes
to get mobile signal. Every website except HN and Gmail (html
version) was too slow to load. This experience has lead me to
reconsider my opinions regarding performance.
eru - 18 minutes ago
What about the Google front page?(And Wikipedia?)
nawitus - 8 hours ago
"Specifically, they?d like you to use Polymer. The problem is that
the Web Component API is really unpleasant to use directly,
especially compared to React. That?s really holding Polymer back in
the framework marketplace. Other WC-based frameworks like Svelte,
Skate, and Stencil abstract away from WCs, treating them as a
compilation target."That argument feels like a non-sequitur.
Polymer's API is different from the Web Component API, so even if
the Web Component API would be unpleasant to use directly, that is
not a criticism of a different API (in this case the Polymer API).
Polymer's API is "similar" to the native Web Component API though,
but it's designed to be easier to use than the native API.
spankalee - 6 hours ago
Polymer's API _is_ the Web Components API, with some helpers
added for reacting to property changes, augmenting templating and
a few others. Polymer is simply a base class for your elements
that sits between HTMLElement and your component class.But I
don't really get the "Web Components APIs are unpleasant" line of
criticism. The WC APIs are just the element constructor,
connectedCallback, disconnectedCallback, attributeChangedCallback
and what methods and properties you define on your component.
These lifecycle methods are nearly identical to what you get in
React and just about every other framework. If those don't have
unpleasant APIs, Web Components don't.
dmitriid - 3 hours ago
> But I don't really get the "Web Components APIs are
unpleasant" line of criticism. The WC APIs are just ...dozens
of lines of tedious boilerplate for the most basic things like
?create a property, and an attribute, and a custom event?The
sad thing is that WebComponents proponents are absolutely blind
to the fact that WebComponents API is complete and utter
crap.Well, most proponents don?t propose WebComponents. They
propose Polymer.
spankalee - 1 hours ago
> create a propertyThis is a criticism of Objects, not Web
Components, and most framework/component libraries out there
assists in creating properties that can be observed, from
Ember to Angular to Polymer. That Web Components don't solve
a problem that applies to the whole of JavaScript, but Web
Components libraries do, does not seem like a very serious
criticism to me.> and an attributeAdding an attribute name to
`observedAttributes` and listening for the change in
`attributeChanged` callback is not very onerous, and similar
to frameworks that have attributes callbacks. How else do you
propose listening to an attribute? Regardless, and again,
libraries help do this small bit for you, and combine it with
a property for a single, declarative property/attribute
definition.> and a custom event"Defining" a custom event is
as simple as firing it, and since they're standard DOM
events, if you find the CustomEvent/dispatchEvent API too
difficult to use, you could write or use a small helper. I'm
not totally sure what it would do, since those APIs are so
simple. And yet again, libraries like Polymer include firing
events when properties change as a declarative option, to
make it even simpler.I know you have a major axe to grind
with Web Components on Twitter. I'm not sure what set you off
about them, and I know I won't change your mind. I only
responded for other readers here.
dfabulich - 6 hours ago
Author here. It's not just me saying that Web Components are
unpleasant. In the article, I linked to Sam Saccone of Google
saying that the WC developer experience is significantly worse
than React's developer experience.https://twitter.com/samccone/
status/914528725852663808"This of course is coming from someone
who has used web components every work day for the last 2
years. Hard to ignore the DX gap that exists."To which Alex
Russell, also of Google and one of the architects of the WC
API, replies, "Who's ignoring it?"There are certainly some
developers who compare and contrast Polymer and React and
prefer Polymer, but it's fair to say that the vast majority of
developers who have made this comparison have preferred React's
developer experience. Even Polymer's advocates seem to be
holding their nose and using it because they appreciate the
long-term promise of Web Components interop.Why? It's hard to
say exactly, but I think it has to do with React's guarantees
that the UI will be a pure function of state. Lots of nifty
React features emerge from that. Polymer components make no
such guarantees.I'm actually pretty enthusiastic about lit-HTML
as a way to close the gap. We'll see how it goes.
spankalee - 5 hours ago
Sam's tweet has no specifics, neither does your article,
about which APIs are painful. Care to add any?
dmitriid - 3 hours ago
This article: https://medium.com/@emilrmoeller/grow-with-
the-browser-learn...?To do this automatically? is followed
by dosens of lines of tedious bolierplate. And that?s for a
single most common use case of adding a property, and an
attribute that are synced. It?s then followed by yet more
boilerplate for adding a custom event.A lot of stuff here:
https://jeremenichelli.io/2017/10/the-web-components-
experie...To quote:To achieve pretty basic mutations on
small components, children references and data manipulation
there?s a lot of heavy lifting that really compromises the
developer experience.And it?s a big deal, since developer
experience is one of the reasons why React or Vue are
widely used in production.Also, web components being
included in a magical global store difficults declarative
and deterministic views or any other concept which hangs on
a visual map of dependencies like code
splitting.UNFORTUNATELY THE DEVELOPER EXPERIENCE OF
BUILDING AN APPLICATION WITH WEB COMPONENTS TODAY IS QUITE
PAINFUL SAM SACCONE?- end quote ?-
spankalee - 1 hours ago
I replied in general below, but I'll take some extra time
to respond to the complaint about getters and setters.Any
JavaScript class that wants to define observable
properties has to define a getter/setter pair.Manually,
this usually looks like this: class C { get
foo() { return this._foo; } set (foo(v) { this._foo
= v; this._somethingChanged(); } } From the part of
the article you reference, you're complaining that Web
Components don't "solve" observable properties. This is
because in JavaScript there are already ways to do this
with with getters, setters, Object.defineProperty, and
while that does involve some amount of "boilerplate"
there are helpers for both Web Components and plain
classes that will create these properties for you.I
really don't see why it's a valid criticism of Web
Components that they don't magically solve this problem
when it's just the way JavaScript works. Of course
frameworks like Angular solve this problem by generating
accessors for you - but so does every major Web
Components library. They all include some way of letting
an author declare observable properties and syncing them
with attributes. Given that the end result in DX is
exactly the same as with other frameworks, why the ding
on Web Components? Why are Web Components held to a
higher standard and expected to "fix" JavaScript?To show
how absolutely easy this is, and how off-base the DX
complain is, here's how easy a Polymer 2 + TypeScript
element is (TypeScript just to use decorators, which will
be standards JS someday...) class MyElement extends
Polymer.Element { @property({notify: true, reflect:
true}) foo: number; } That will create an observable
property, fire a "foo-changed" event and set the "foo"
attribute when it changes, and listen for the "foo"
attribute and deserialize it to the foo property when the
attribute is set.Even without decorators, this is pretty
damn easy to do, and the first thing any Polymer
developer learns: class MyElement extends
Polymer.Element { properties = { foo:
{type: Number, notify: true, reflect: true} } }
Other Web Components libraries like Skate and Stencil
include their own way of declaring properties, just like
other frameworks like Angular and Ember do.The second
article is also comparing raw Web Components with no
helpers to a framework that's full of helpers. You could
just as easily saw JavaScript has a broken DX if you
tried to do React-style components without React. The
higher expectation for Web Components here is kind of
ridiculous, to be honest.
nawitus - 30 minutes ago
"Polymer's API _is_ the Web Components API, with some helpers
added for reacting to property changes, augmenting templating
and a few others."For that reason I think they're different
APIs, even though Polymer's API can be considered a superset of
the Web Components API.
spankalee - 6 hours ago
Regarding lit-html, which I wrote the majority of, lit-html is not
a new framework, but simply a template library. This is called out
specifically in the talk.> You can wrap lit-HTML in WCs, just like
you can wrap React components up as WCs, but you gain nothing from
it.This isn't true either. lit-html has no component model, so by
using it to implement WCs, you get a component model.> it?ll be in
direct competition with Polymer, Angular, Svelte, Skate, and
StencilA template library is not in direct competition with Web
Component base classes/frameworks, but can be used by them. It's
already integrated with Skate, will be integrated with Polymer
soon, and Stencil is looking into using it too.
dfabulich - 6 hours ago
Author here. I must begin by saying that lit-HTML is really
interesting, and I hope it does well. It will be particularly
exciting if Polymer 3 or Polymer 4 or whatever primarily uses
lit-HTML out of the box.> lit-html is not a new framework, but
simply a template library.Nobody wants to be called a framework,
do they? For years, React developers insisted that it was nothing
but a "view" layer, because everybody knows that "frameworks"
suck.> lit-html has no component model, so by using it to
implement WCs, you get a component model.I think you
mis/underestimate the extent to which you have a component model
already. What you already have is the equivalent of React's
"functional components," where the component is nothing but its
render method.> A template library is not in direct competition
with Web Component base classes/frameworks, but can be used by
themIt's great that WCs let you interop with all WC-based
frameworks, but some folks will avoid lit-HTML in favor of
Stencil's JSX approach, or in favor of Svelte's Vue-alike HTML
components, or more generally to decide whether to observe
changes and respond to them or whether to regenerate the UI as a
function of state.Interop doesn't mean you're not in competition.
Viper007Bond - 2 hours ago
> Dan from Automattic came up to say that their closed-source
Jetpack plugin for WP also offers preliminary PWA support.Closed so
urce?https://github.com/Automattic/jetpackhttps://github.com/Automa
ttic/jetpack/pull/7963
curt15 - 3 hours ago
Given that Chrome apps are on their way out, a nice demonstration
of Progressive Web Apps would be to make Gmail into one to replace
the functionality of Gmail Offline.
seanwilson - 4 hours ago
Are there any good examples of progressive web apps? I made a web
app recently that had to work offline for use as a visitor
display...I looked into service workers for this (there's a Webpack
plugin that helps) but they seemed complicated plus difficult to
debug. It seems like you have to be careful you don't lock your
users out with a service worker bug because now a browser refresh
might not do the same thing for everyone now.
kinlan - 4 hours ago
https://outweb.io/ and https://pwa-directory.appspot.com/ have
collections of progressive web apps. They all have differing
levels of offline support based on their needs.
fiatjaf - 6 hours ago
If they want PWAs they should stop promoting and encouraging native
apps.
josteink - 2 hours ago
> It?s the Google Payment API. After replacing Google Checkout with
Google Wallet, and then replacing that Android Pay, the docs have
the audacity to call it ?The newest way to pay with Google.?> The
Google Payment API only works in Chrome on AndroidWhy does Google
even bother making this?
inglor - 7 hours ago
If they'd like us to start building progressive web apps - they
should pull-request webkit with PWA APIs.Safari doesn't have those
because Apple doesn't see them as a priority - but after talking to
Apple engineers who work on Safari it turns out that it's mostly
because it isn't prioritized and not because they don't want the
feature.It's not _that_ much work either on their end.If I knew I
could get PWA capabilities on an iPhone - I would definitely
consider PWAs for replacing native development entirely.
_alastair - 6 hours ago
I have a tiny insight into this, as I've been working on a
Service Worker implementation for iOS webviews (i.e. in apps, not
Safari):https://github.com/gdnmobilelab/SWWebViewI'd disagree
with your assertion that it's not that much work :) Service
Workers are their own self-contained JavaScript environments with
complicated lifecycles after all.That said, I've been surprised
by now much is possible just using public APIs, but I'm not sure
you could pull request a full OS implementation. For example,
adding an app to home screen. That's going to need to wire into
non-WebKit iOS and macOS code, which AFAIK is not open source.
Workers also sometimes run when the browser is not active, and
that wouldn't be a trivial thing to add.Also, Apple started
working on the Service Worker APIs recently. It's not clear
exactly how much they'll implement, but it's a very positive
step.
kinlan - 7 hours ago
Service Worker and Manifest are in development in Safari. It's
quite a significant amount of work to land the APIsIt's not as
simple as just forcing it in. SW can require deeper integration
with the OS and network stacks that we don't have the ability to
change on iOS or macOS.
inglor - 6 hours ago
Thanks for answering. You are correct that they are under
development but they're moving pretty slowly and I got the
feeling contribution would be really appreciated.For example,
`fetch` in service workers - caching and request intercepting
could really improve the "default" iPhone experience in PWAs.I
realize that getting this request is annoying (Build a feature
in another browser) but I really think it could significantly
push the web as a whole.It would also be great to see the
Chrome team fix some of the more annoying bugs in the existing
APIs (WebRTC has some really annoying ones).
kinlan - 6 hours ago
Re: web rtc .. yes... And getting the screen share API in
would be nice too.Re: helping. I think we have some engineers
supporting our predictablity efforts on WebKit (i.e helping
to smooth out edge cases) but I don't think we are working
pushing larger features in...
kinlan - 7 hours ago
Organizer of Chrome Dev Summit here.Please do keep sending feedback
and thoughts through on how can keep improving.In terms of session
length, I can see that being an issue. We had strict union
regulations, and a lot of content to get through and I took the
decision for more but shorter length talks that we can expand with
textual content after the event.We also tried to keep the theme for
day 1 to everything we've learnt in the last year, so what is the
new minimum bar for web experiences, how to load them quickly and
how we've done it in the real world with commerce and media
experiences and wordpress and pwa.On day 2 I wanted us to showcase
where we think the web could be heading in the next year,
specifically with more of a focus on developer experience (devtools
etc, polymer, lit etc)Not saying we hit all those goals, but I do
feel pretty happy with the event as a whole.
pas - 6 hours ago
(I've asked this on Reddit too, but maybe others want to chime
in.)Maybe somewhere in that 10 hour someone talks about it, but
let me ask about this problem: Google is big, and has many sides,
fronts, faces and eyes; what is Chrome, where is Chrome in
relation to all the other web-related, web-facing web-targeted
things?Where is Chrome, Polymer, Angular, and Android compared to
each other (and the big Google itself)? Should I wait for Angular
to adopt the Chrome PWA guidelines? Should I just wait for the
Android team to stop developing the native APIs and focus on the
WebView and make the whole Android platform more web-compatible?
If now, what's Chrome's thoughts on what these other
teams/projects/products/faces-of-Google are doing?
kinlan - 6 hours ago
That's a good question that I don't know how to answer
clearly.We are a big company with many facets and no clear web
direction owner and also lots of platforms (android, web,
assistant etc). Generally, it's lots of groups working to reach
users on the web. Chrome works on what it can work on and tries
to influence other teams as best it can.Angular team has been
very supportive of the PWA story, but it wasn't clear in this
conference for sure.For those not at the event, we had a large
forum area where we had more Google teams (AMP and Angular) and
many other browsers have a space to talk to developers.... But
this wasn't clear by just looking at the videos.I think the big
thing for me, is we are not going to say don't do Android. We
should be clearer on why things like Trusted Web activities
help you deliver web experiences with native though and we can
keep being clearer about why we think the web is good and how
best to deploy on it.
pjmlp - 4 hours ago
Regarding Android, it always feels strange to sometimes watch
jabs at native development from Web talks at IO, as if
Android wasn't a Google product.
kinlan - 4 hours ago
Do you have specific examples? I know we frequently talk
about the benefits of distribution and reach of the web in
comparison to other platforms including Android.
pjmlp - 4 hours ago
Not without watching all talks again.Usually has to do
with remarks on why to bother with native approaches, how
PWAs are going to conquer the mobile experience or how
doing web is so much better than native.For the exact
wording I would need to go again through the Chrome,
Polymer, Angular and PWA talks, so just take it with a
grain of salt.
dfabulich - 6 hours ago
Author here. This question came up several times at the
"leadership panel." You can see my notes on questions like
these in the article, but I encourage you to pull that video up
and just watch
it.https://www.youtube.com/watch?v=TU8fy8PHAl0Google accepts
that they're going to have competing approaches inside the
company, and this even has significant advantages. We all just
have to deal with it.
nojvek - 5 hours ago
I would just say, please don't forget the people who make dev
summit great. Especially the underrepresented females.There were
open complaints on Twitter about the dev summit organizers being
sexist.I won't go into details but multiple female Google
employees have voiced their opinions regarding this.Don't be that
guy.
kinlan - 4 hours ago
I saw your email to the team and I have reply coming shortly
(if it wasn't sent out already).For context, for everyone on
the thread. We had a wrap-up video
(https://www.youtube.com/watch?v=2n69vkYvo9g) of the event that
didn't have the MC's included and given they were the face of
the event, it was a mistake that we made and we didn't have
time to fix and are in the process of rectifying. We also had a
dedicated video planned just for the MC's but it takes time to
create and put together.
xenadu02 - 2 hours ago
> We had strict union regulationsCan you clarify what this
means?In my experience it means paying for more audio, video, and
venue staff because the existing folks have been on duty all day
but the conference organizers don?t want to pay or can?t afford
to pay for a) more people or b) overtimeI?ve done a bit of mix
engineering and conference organizers are very myopic: why can?t
I be as excited about their stuff as they are? They don?t think
about what happens when this is your day job and if you don?t
bring the hammer down you?ll end up working unpaid overtime every
day of every week because every conference thinks they are the
hottest most exciting shit since sliced bread.One can assume
Google is able to pay more but made the perfectly reasonable
business decision not to. The mystery for me is why you?re
blaming it on the union?Perhaps the venue completely prohibits
longer days but every rate sheet I?ve ever seen simply quotes
higher prices if you exceed a ?normal? conference day length.(I?m
genuinely curious here but also being slightly sensitive: there
are certainly abusive unions - Philly conference centers come to
mind where you have to pay master electricians to carry tables
and chairs into the venue - but it is far more common for people
to be cheap-asses & blame the unions)
kinlan - 1 hours ago
I'm not blaming the union if it came out that way it wasn't
intentional. I had to work around a number of constraints, with
timings based on regulations as well as rates, budget
constraints and other factors that came in at the last minute,
as well as people on our sides own ability to work the long
hours and I chose to balance of them all and it meant having
talks at 30 minutes and the breaks based around all these
factor.... I mean, I am happy with the content and the pace and
the quality of the work from everyone involved especially the
event crew.It's just a factor how we chose to run the event and
the content and that is what I was trying to articulate.
xenadu02 - 36 minutes ago
That makes sense; as I said there are perfectly valid
business (or other) reasons to limit the length of each
day.FWTW: I don?t see a problem with shorter sessions.
inglor - 7 hours ago
Hey, thanks for taking feedback!As someone who was invited to
attend - I really wished the talks were more low level and
technical. I'd really enjoy talks about how things are
implemented in Chrome, how the underlying APIs (for PWAs for
example) work and so on.
dalmaer - 40 minutes ago
A good place to see those talks is
BlinkOn:https://www.youtube.com/user/blinkontalks
kinlan - 6 hours ago
We are talking about that for next year.We need to do a better
job at audience segmentation because we have ranges from senior
dev to student, and CxO's etc and that's roughly why we stay a
tad higher level with a lot of case studies.We might end up
with different days or different events for the audiences.
ldd - 2 hours ago
I wish to voice the opposite view from OP: I love the fact
that you stay at a 'higher level'. My primary focus when
watching these talks is knowing the current state of chrome,
and some information directly from the source on what you
worked and will be working in the future.Because of this, I
want to say thank you precisely for not giving more lower-
level details in your talks.
kinlan - 1 hours ago
:) thank you - it's a balance...
therealmarv - 3 hours ago
At least Google addresses the problems we have with Internet in
countries/continents like e.g. Afrika or Philippines.Really... it's
a whole different world if you only have 500Kbit/s download rate
and you can see easily who has done their homework good to address
countries with slow internet and who did not. Some websites will
get completely unusable in this areas! And you will find out that
Opera Mini is your new best friend.Only want to mention one heavy
media company which has done a near perfect job: Instagram. This
app is even blazing fast with slow internet. Well done, really.