Hey,
Nearly every month I see a tweet where a spokesperson of a big brand or big online service writes that they can’t support every major modern browser and offer Chrome-only features or banners that indicate users to switch to Chrome, claiming that they can’t provide the same experience in all browsers and need to focus on the most important things. Now, from a product and project management view this is a totally known strategy to ship features fast—build a minimum viable product, ship it fast and iterate. What we don’t see in this approach though is the question where situations like this originate. Most of the companies I read such announcements have large teams behind the product, most of them have their business built upon an online web service.
Now think about this again: A company that relies on customers using web browsers limits their clients artificially by restricting them to one browser. How can it come to such a product that needs dozens of engineers but only works in one product of many out there? A similar issue can be observed in accessibility: Many web projects still ‘need’ support for IE8 but accessibility has no priority, leaving more than quadruple the number of IE8 users globally out to buy the same product. Sometimes we miss to reframe what we do, to have a bird-eye look on the issues we have and how we can solve them and what to prioritize.
What if we as developers would prioritize our users over the coding convenience? What if we who decide what to prioritize think a bit more out of the box? What if we try to achieve cross-browser support by using standards instead of proprietary tools? And remember, if you encounter a bug, miss a feature, I’m sure every engineer of any browser will be happy if you file a bug report for it. They also learn from us, their customers.
News
- The big news from browser vendors don’t stop coming in: Google Chrome now announced that starting in Chrome 68 (to be releaded in July 2018) the browser will mark non-secure sites (HTTP) as “not secure”, marking the end of non-HTTPS websites. I just imagine all the clients with their small business sites and portfolios desperate about this change. It’s great to see the shift to a more secure web but sometimes I feel like those who decide don’t think enough about the impact of small entities using the Internet as well.
- Safari’s Technology Preview 49 brings some interesting features: The Intelligent Tracking Protection now has a debug tool in experimental mode,
column-gapsupports%-values now,active-descendantis supported, and Console will now throw a warning if AppCache is used. - Here we go with the announcement of the last major browser vendor to support Progressive Web Apps, this time Microsoft in Windows and the Edge browser. Edge 17 will come with Service Workers and Push Notifications, but more interestingly the company shares their strategy on how they will support such apps at an Operating System level: The Microsoft Store will start listing Progressive Web Apps by manual submission which is a big step ahead for making web apps as usable as native apps. I can imagine many Electron apps to become obsolete if this concept gets adopted by other OS-vendors as well.
Generic
- Eric Meyer has been one of the persons who worked with CSS since the beginning and has a close insight on how it developed. He now wrote up some thoughts in regard to how the complexity of CSS changed over time.
- Matt Ludwig wrote an article last year about the problem of software compatibility over time and why a Progressive Web App rewrite will be the solution to make it still work in fifty years. The fallacy here is to think that the web is the same like twenty-five years ago. Today we face browsers removing a lot of APIs after a few years, putting existing features behind a HTTPS wall, and developers building code based on a countless amount of dependencies that are abandoned after some time by their authors. And once we’re building upon anything that is not the plain web standard, we’re not in a position anymore to say that the code will last for long. I’ve built relatively simple projects several years ago and without investing time today, they would not work anymore. The Geolocation API has been restricted to HTTPS, so I need to get a certificate and renew it regularly which depends on an external company that could go bankrupt or untrusted by browsers anytime. AppCache gets removed from browsers and put behind secure context as well so my Progressive App I’ve built with web standards just five years ago does not work today anymore. The web changed a lot, and despite HTML and some basic parts of CSS and JavaScript I think we cannot be sure that things will work in ten years, as sad as this sounds. But we all make progress and learn from errors and so do browser vendors. Time changes the tools we use and we will need to adapt.
Tooling
- Monica Dinculescu shares how she wrote a script with Puppeteer, the Chrome team’s reference library to automate headless Chrome to achieve automated visual diffing.
- Chrome 65 is coming soon and it’ll bring a very handy feature to the Developer Tools: A contrast ratio tool in the color picker that helps identifying contrast in color pairings.
Security
- As it seems, Mixpanel has collected user passwords for months inadvertently with their Autotrack feature. If you use Mixpanel, you should upgrade to the latets version of the script as soon as possible to fix this behaviour.
Privacy
- Holger Bartel takes Vitaly Friedman’s article “̦Respect Always Comes First” as opportunity to highlight the importance of respecting users by asking a very interesting question: Everyone wants to create better experiences, but what are you willing to do for it? It’s not easy to find an answer and to blaze the trail for this in our work but an important part of building products.
Web Performance
- Ben Robertson shares how we can lazy load videos and choose quality based on the user’s connection speed.
- Seva Zaikov asks in public thoughts about the trend to build everything as Single Page Applications whether this can be in the interest of users and tries to find some numbers to find out whether his assumption of websites getting slower for users can be backed by data. It’s not a rant about tools like React but asks important questions we should ask ourselves before starting to build the technical architecture of a new project.
Work & Life
- How do we decide when to iterate on things and when to rebuild? I ask myself this question again and again and wrote up some conclusions how to make things better in a short article.
Anselm