Centering

One of the topics of discussion in the broader conversation around algorithmic fairness has been the idea of decentering: that we should move technology away from the center of attention – as the thing we build to apply to people – and towards the sides – as a tool to instead help people.

This idea took me a while to understand, but makes a lot of sense. After all, we indeed wish to use “tech for good” — to help us flourish — the idea of eudaimonia that dates back to Aristotle and the birth of virtue ethics.

We can’t really do that if technology remains at the center. Centering the algorithm reinforces structure; the algorithm becomes a force multiplier to apply uniform solutions for all people. And that kind of flattening – the treatment of all the same way – is what leads to procedural ideas of fairness as consistency, as well as systematically unequal treatment of those that are different.

Centering the algorithm feeds into our worst inclinations towards tech solutionism – the idea that we should find the “one true method” and apply it everywhere.

So what should we, as computer scientists, do instead? How can we avoid centering the algorithm and instead focus on helping people flourish, while at the same time allowing ourselves to be solution-driven? One idea that I’m becoming more and more convinced of is that, as Mitchell and Hutchinson argue in their FAT* 2019 paper, we should make the shift from thinking about fairness to thinking about (un)fairness.

Unfairness

When we study fairness, we are necessarily looking for something universal. It must hold in all circumstances — a process cannot be fair if it only works in some cases. This universality is what leads to the idea of an all-encompassing solution – “Do this one thing and your system will be fair”. It’s what puts the algorithm at the center.

But unfairness comes into many guises, to paraphrase Tolstoy. And it looks different for different people under different circumstances. There may be general patterns of unfairness that we can identify, but they often emerge from the ground up. Indeed, as Hutchinson and Mitchell put it,

Individuals seeking justice do so when they believe that something has been unfair

Hutchinson & Mitchell. 50 Years of Test (Un)fairness: Lessons for Machine Learning. ACM FAT* 2019.

And to the extent that our focus should be on justice rather than fairness, this distinction becomes very important.

How does a study of unfairness center the people affected by algorithmic systems while still satisfying the computer scientist’s need for solutions? Because it aligns nicely with the idea of “threat models” in computer security.

Threat Models

When we say that a system is secure, it is always with respect to a particular collection of threats. We don’t allow a designer to claim that a system is universally secure against threats other than those explicitly accounted for. Similarly, we should think of different kinds of unfairness as attacks on society at large, or even attacks on groups of people. We can design tools to detect these attacks and possibly even protect against them — these are the solutions we seek. But addressing one kind of attack does not mean that we can fix a different “attack” the same way. That might require a different solution.

Identifying these attacks requires the designer to actually pay attention to the subject of the threat — the groups or individuals being targeted. Because if you don’t know their situation, how on earth do you expect to identify where their harms are coming from? This allows us a great deal more nuance in modeling, and I’d even argue that it pushes the level of abstraction for our reasoning down to the “right” level.

This search for nuance in modeling is precisely where I think computer science can excel. Our solutions here would be the conception of different forms of attack, how they relate to each other, and how we might mitigate them.

We’re already beginning to see examples of this way of thinking. One notable example that comes to mind is the set of strategies that fall under what has been termed POTs (“Protective Optimization Technologies”) due to Overdorf, Kulynych, Balsa, Troncoso and Gürses (one, two). They argue that in order to defeat the many problems introduced by optimization systems – a general framework that goes beyond decision-making to things like representations and recommendations – we should design technology that users (or their “protectors”) could use to subvert the behavior of the optimization system.

POTs have challenges of their own – for one thing they can also be gamed by players with access to more resources than others. But they are an example of what decentered solution-focused technology might look like.

I wrote this essay partly to help myself understand what decentering even might mean in a tech context, and why current formulations of fairness might be missing out on novel perspectives. I’ll have more to say on this in a later post.

Fascinating blog post from Laura Larke that helps to answer the question: Why isn’t high school computing growing in England?  The Roehampton Report (pre-release of the 2019 data available here) has tracked the state of computing education in England, which the authors describe as a “steep decline.” Laura starts her blog post with the provocative question “How does industry’s participation in the creation of education policy impact upon what happens in the classroom?” She describes teachers who aim to protect their students’ interests — giving them what they really need, and making judgments about where to allocate scarce classroom time.

What I found were teachers acting as gatekeepers to their respective classrooms, modifying or rejecting outright a curriculum that clashed with local, professional knowledge (Foucault, 1980) of what was best for their young students. Instead, they were teaching digital skills that they believed to be more relevant (such as e-safety, touch typing, word processing and search skills) than the computer-science-centric content of the national curriculum, as well as prioritising other subjects (such as English and maths, science, art, religious education) that they considered equally important and which competed for limited class time.

Do we see similar issues in US classrooms?  It is certainly the case that the tech industry is painted in the press as driving the effort to provide CS for All.  Adam Michlin shared this remarkable article on Facebook, “(Florida) Gov. DeSantis okay with substituting computer science over traditional math and science classes required for graduation.” Florida is promoting CS as a replacement for physics or pre-calculus in the high school curriculum.

“I took classes that I enjoyed…like physics. Other than trying to keep my kids from falling down the stairs in the Governor’s mansion I don’t know how much I deal with physics daily,” the governor said.

The article highlights the role of the tech industry in supporting this bill.

Several top state lawmakers attended as well as a representative from Code.org, a Seattle-based nonprofit that works to expand computer science in schools. Lobbyists representing Code.org in Tallahassee advocated for HB 7071, which includes computer science initiatives and other efforts. That’s the bill DeSantis is reviewing.

A Microsoft Corporation representative also attended the DeSantis event. Microsoft also had lobbyists in Tallahassee during the session, advocating for computer science and other issues.

The US and England have different cultures. Laura’s findings do not automatically map to the US. I’m particularly curious if US teachers are similarly more dubious about the value of CS curricula if it’s perceived as a tech industry ploy.

VIA Rail has a page that compares various aspects, including emissions, of the train vs. the car vs. the plane for some common central Canadian routes.

The fine print is interesting:

Train emissions calculator

The formula used to calculate train related data emissions is: (Litres of diesel fuel consumed X Emission Factor) / average of seats available on the selected route = Kg of CO2 equivalent per seat. The emission factor of 3.00715 Kg of CO2 equivalent per Liter of diesel No. 2 was used. The fuel consumption for each selected route was calculated using an average of real-time fuel consumption as measured by the Witronix technology over a 12-month period. The emission factor for diesel No. 2 is calculated by Environment Canada as part of its National Inventory Report (2011 submission) and takes into consideration the global warming potential of CO2, CH4 and N2O.

Flight emissions calculator

Number from Zerofootprint Flight emission calcultor for Air Canada used.

Car emissions calculator

For the calculations, a mid-size sedan with a combined fuel consumption rate of 10.0 Liters per 100 km was used, considering an average capacity of 4 passengers per vehicle. The distances are calculated in Kilometers using Google Maps. The formula used to calculate car related data emissions is: (Litres of gasoline consumed X Emission Factor) / average # of seats = Kg of CO2 equivalent per seat. The emission factor of 2.500 Kg of CO2 equivalent per Liter of gasoline (Tier 0) was used. The fuel consumption rate for a mid-size vehicle is an average calculated for mid-size type vehicles from the 2013 Fuel Consumption Guide developed by Natural Resources Canada. The emission factor for gasoline is calculated by Environment Canada as part of its National Inventory Report (2011 submission) and takes into consideration the global warming potential of CO2, CH4 and N2O.

I don’t know if these are the right calculations to be using, but kudos to VIA for including them.

It would be nice if VIA create a more general-purpose emissions calculator that worked for all of their routes.

Pro tip: if you have a list of files that you need to retrieve from a webserver, you’re better off putting the list of URIs in a file, and then:

wget -i list-of-files.txt

than you are crafting a shell script like:

wget http://www.example.com/file-number-1.jpg
wget http://www.example.com/file-number-2.jpg
wget http://www.example.com/file-number-3.jpg

The former works much, much faster.

Is the ad for real?  I ask only because I hadn’t seen this instant classic before.

(Update 24 Sep 2019: add link to IsLoggedIn. Update 20 Sep 2019: copy edit. Update 14 Aug 2019: Add link to Safari's policy)

(Disclaimer: I work for Mozilla. Not speaking for Mozilla here.)

The first result of the browser privacy trend is a growing difference between how the browser treats two kinds of third-party data collection.

• third-party data collection that happens when the user chooses to use information from one site on another site

• third-party data collection that happens when a site or service, without an action from the user, tries to use information about the user's actions from one site while they're using another site.

Any third party interaction that the user knows about is supposed to keep working. But hidden tracking pixels, scripts and any technology that tries to implement tracking without user interaction are all supposed to stop working.

Protections to implement this are still in progress, but this clearly the direction Safari, Firefox, and now Microsoft Edge are going. We now have the same kind of rough consensus on user expectations about tracking that we developed pretty early on in the email spam situation. This consensus is based on extensive user research. (Why browsers took so long to listen to people about what they find creepy is another story.)

An example of a protection step that's common across browsers is the the Storage Access API. This gives browsers a way to allow third-party scripts to use cookies and LocalStorage, but only if the user takes action. Apple Safari, Mozilla Firefox, and Microsoft Edge are all involved. (hashtag #worldsFriendliestBrowserWar)

The WebKit Tracking Prevention Policy used by Apple Safari, says

Merely hovering over, muting, pausing, or closing a given piece of content does not constitute an intention to interact.

and

We consider certain user actions, such as logging in to multiple first party websites or apps using the same account, to be implied consent to identifying the user as having the same identity in these multiple places. However, such logins should require a user action and be noticeable by the user, not be invisible or hidden.

The Mozilla anti-tracking policy is similar.

For sites, what this means is that SSO and registration walls are relatively safe. If the user is clearly presented with "Sign in with (identity provider brand)" and there is a button the user has to click the first time they go to the site, that SSO system should keep working. The user knows that they're using it, and clicked the logo of the provider they "sign in with." A proposed API, IsLoggedIn, from Apple Safari developer John Wilander, would make it easy for a site to check logged-in status from JavaScript.

If the user can't see the way that multiple sites are trying to use the same information about them, then that flow of data across sites is likely to get blocked, whatever the technical implementation is. This is likely to be good for the relative market power of sites that people trust more, if it turns out that people are more willing to "sign in with" (and obviously share info about themselves) on their trusted sites than on a random site that their uncle sent them a link to.

More on this: Will ITP and ETP kill traffic arbitrage?

Bonus links

Cookies and other tracking devices: the CNIL publishes new guidelines

What happened when Congress looked into data brokers almost 50 years ago

The Washington Post is preparing for post-cookie ad targeting

AdTech Sucks: This Time It’s Personal IDs

Uber’s Latest Lawsuit Calls Out Agencies, Advertisers and Now Ad Tech

OK so maybe I was a bit hasty about using that “last post” title.

I got a tweet from the CBC that I wanted to share – but by the time I had found what it lead to the tweet was way off somewhere, and hard to find for even a simple retweet. Then I thought about sending it by email to by chums at Transport Action BC – but the rigmarole gmail puts me through to do that – I have not found how to do email lists – makes it daunting. And if I hit “reply all” I can’t change the thread Title.

Facebook just makes a muck of the links and the pictures.

So the CBC reports that there is a new, large archive of historical BC photos at UBC. So of course the first thing I do is go have a peek and search for train and streetcar images. “Train” produces 20 images of which this is the first

The Uno Langmann Family Collection of British Columbia Photographs is currently being digitised but is both searchable and usable since the images have a Creative Commons license.

GOOD.

I have been working on ProjectOnHerOwn since we got selected for Gender Bender 2019. Gender Bender is India’s first arts festival that focuses on fresh perspectives of Gender. Our work #ProjectOnHerOwn will be part of it.

#ProjectOnHerOwn is a multimedia exploration through the landscape of women’s experiences of self-discovery, self-reliance and self-assertion. It travels through familiar stories about women all of us know. It unravels our moments of silent rebellion and shows us that we are not alone in these. In a world where the non-conforming voice has to fight for space, it is time for the collective to make space for the stories of everyday fight.

As part of #ProjectOnHerOwn, We are setting up a telephone line where anyone can call and listen to a story. Also at the end leave their own story as a response. I think it is an interesting way to listen to a story. Telephone makes the experience personal and intimate. IVR gives us option to tell those stories in human voice and in the language they choose. More about stories in a different blog, this post is about the tech part.

Last time I setup an IVR line was more than half a decade back. Voice APIs were just getting started, it was not that easy. Things have gotten a lot easier now. With serverless functions I don’t even have to pay for a server unless they get used. Freedom of not managing a LAMP server is huge. Even the database is a service this time. Though I must say, I use my own CouchDB as database. As far as this application is considered database is just a RESTful API.

Lambda is written in Python, it responds to KooKoo API’s stateful calls. CouchDB is used for saving the state of the call and user language preferences. I use CouchDBs RESTFul APIs. The public media files are stored on AWS S3 in a public bucket. So KooKoo servers them from S3 bucket. I will open source the code once it reaches a stable state with comments, so it can be reused for any similar audio projects.

Tech Arch diagram of ProjectOnHerOwn.

We also have an HTML widget to embed in a web page to show the number of stories heard. This is like web 1.0 page counter sticker we are all nostalgic about. Here again Lambda talks to CouchDB and get the count of sessions. Usually one session = one call = one story heard.

In all my testing it sounds good. It sounds like your friend is telling you a story. I am happy about the quality of the sound. At this point we have enough ports to accommodate quite a few users in parallel. We will have to see how it goes once we go public. But the developers at KooKoo have been very friendly and responsive. So I am guessing all is going to go well. Now I’m waiting for Aug 1, to invite you all to try it out. Until then see follow the updates on our instagram page.

This being the 2,38947234th and probably last time I’ll change my username, (marriage is permanent, right?) I thought I’d better write a quick post on how this transition can be achieved as smoothly as possible. You can read official instructions on how to change your GitHub username here, and they will tell you how to do it and what happens. The following is a quick guide to some things to consider afterwards.

Where to make changes

1. Change username in GitHub account settings.
2. If using GitHub Pages, change name of your “username.github.io” repository.
3. If using other services that point to your “username.github.io” repository address, update them.
4. If using Netlify, you may want to sign in and reconnect your repositories. (Mine still worked, but due to a possibly unrelated issue, I’m not positive.)
5. Sign in to Travis CI and other integrations (find them in your repository Settings tab -> Integrations & services). This will update your username there.
6. Update your local files and repository links with very carefully executed find and sed commands, and push back changes to GitHub.
7. Redeploy any websites you may have with your updated GitHub link.
8. Fix any links around the web to your profile, your repositories, or Gists you may have shared.

Local file updates

Here are some suggestions for strings to search and replace your username in.

• github.com/username (References to your GitHub page in READMEs or in website copy)
• username.github.io (Links to your GitHub Page)
• git@github.com:username (Git config remote ssh urls)
• travis-ci.com/username (Travis badges in READMEs)
• shields.io/github/.../username (Shields badges in READMEs, types include contributors, stars, tags, and more)

You can quickly identify where the above strings are located using this command for each string:

grep -rnw -e 'foobar'

This will recursively (r) search all files for strings matching the whole (w) pattern (e) provided and prefix results with the line numbers (n) so you can easily find them.

Using find and sed can make these changes much faster. See this article on search and replace.

Enjoy your new handle! (I hope it sticks.)

Much easier than regulating to break up Facebook, just regulate to force them to make an API for us to get data in and out. We can break them up ourselves once we have that. (source)

Neil is right, an effective way to break-up big tech monopolies is requiring they have API‘s. (Much like key government data sets across the EU will be required to have API’s from 2021 based on the 2019 PSI Directive)

A monopolistic platform that has an API will be effectively broken up by its users and by app builders as they will interact with bits and pieces from various platforms as they see fit.

That FB and Twitter e.g. have been on a path over steadily reducing public API access over time shows you the truth of that.

(Adversarial) interoperability and standards are key elements in avoiding vendor lock-ins. This is true for ‘smart home’ appliance silos just as much as for webservices.

If you don’t have an API you’re not a platform (platforms are after all bases to build/grow things on, if you stunt that ability you’re not a platform). If you’re not a platform, you’re fully liable for your user uploaded content. How’s that for a trade-off?

All platforms should be required to join the API family…

Picture taken earlier this month at La Folie de Finfarine in Poiroux

Neuroscientist Shane O’Mara believes that plenty of regular walking unlocks the cognitive powers of the brain like nothing else. He explains why you should exchange your gym kit for a pair of comfy shoes and get strolling.

More >

[Thanks, Florian]

Eine heiße Woche liegt hinter uns und es hat endlich wieder geregnet. Damit unsere Pflanzen nicht kaputt gehen, wässern wir sie regelmäßig. Wir haben keinen Rasen, aber einen Hausbaum, jede Menge große Töpfe, viel pflegeleichten Kies und zweimal 30 Meter Hecke sowie Beete. Den Baum und die Töpfe gießen wir mit dem Schlauch und in der Hecke liegt ein Tropfschlauch. In der Vergangenheit haben wir diesen Schlauch schon mal aufgedreht und über Nacht dann vergessen. Ich habe es mit einem Gardena Computer probiert, aber der WAF war unterirdisch.

Ganz anders Eve Aqua. Im einfachsten Fall drückt man einfach auf den Knopf, der Schieber geht auf und nach einer vorher festgelegten Standardzeit wieder zu. Ich habe ein paar mal die Garten-Wasseruhr vorher und nachher abgelesen. In einer Stunde verteilt unser Tröpfelschlauch 260 Liter, also je nach Größe ein bis zwei Badewannen. Da Eve weiß, wann und wie lange der Schieber auf ist, kann ich in der App nachlesen, wann das letzte Mal gewässert wurde und wieviel Wasser durchgelaufen ist. Das ist natürlich nur eine Schätzung, die man ab und zu mal prüfen muss.

Für Eve Aqua braucht man ein iPhone (oder iPad), denn es spricht HomeKit über Bluetooth. Eve betreibt keine Cloud, deshalb speichert das Gerät alles selbst. Regelmäßig, mindestens alle drei Wochen, sollte man die App aufrufen, wenn man ein vollständiges Log aller Bewässerungen haben will. Und zwar mit jedem Gerät, dass das wissen soll. Eve ist da wirklich radikal. Das Gerät weiß es, und die App, und sonst niemand.

Da man nicht ständig selbst auf den Knopf drücken will, kann man Eve Aqua programmieren. Ich gieße gerne zweimal die Woche, jeweils zwei Stunden vor Sonnenaufgang. Das merkt sich das Gerät und ich könnte bis zu 14 dieser Programme hinterlegen.

Wenn Aqua in Bluetooth-Reichweite eines HomeKit Hubs ist, also HomePod, Apple TV oder ein iPad am Strom, dann kann man die Bewässerung auch von unterwegs aus steuern. HomeKit stellt eine verschlüsselte Verbindung mit dem HomeKit Hub her und übermittelt die Befehle an Aqua. Nächsten Monat gibt es noch ein neues Gerät Eve Extend, mit dem man die Reichweite vergrößern kann. Ohne eine solche Verbindung fährt Aqua einfach stur sein Programm.

Mit einem HomeKit Hub kann man die Bewässerung auch zentral steuern, etwa durch die HomeKit Automation. Sehr lustig fände ich eine Katzenvergrämung: "Wenn nachts Bewegung erkannt wird, Rasensprenger für zwei Minuten einschalten". Mit iOS 13 wird HomeKit auch noch über Kurzbefehle programmierbar, da wird noch viel mehr möglich. Aktuell erzeugt einem Eve zwei Kurzbefehle, die den Zeitplan für heute oder heute und morgen pausieren.

Ich liebe diese HomeKit App von Eve mittlerweile sehr. Anfangs habe ich sie ignoriert, aber sie ist viel informativer als Apple Home. Beide nutzen das gleiche API, so dass alle Konfiguration soweit möglich in beiden Apps auftauchen. Und für die Liebhaber des Dark Mode: Ja, das gibt es auch.

More >

This blog post comes from a Twitter thread I did on snippets of wisdom that I have drawn from a broad range of writers. It’s like the synthesis/distillation of all (or most of) the books about writing that I have read. This wisdom applies to writers of books, articles, or theses.

MAKING SPACE: Most authors I have read (Joli Jensen, Eviatar Zerubavel, Stephen King, Helen Sword) recommend that people carve a physical space to do their writing. This ritualistic approach may not work for everyone, it does for me. I have 3 spaces where I work (home, office), and my home office in my childhood bedroom at my Mom’s house.

I try really, really hard NOT to work in my dining table (I now have a big enough house that I can do this, but even when I lived in Vancouver in a shoebox, I had a little alcove that I used to JUST write my doctoral dissertation). The point that Stephen King and Joli Jensen in particular make is that you need to CARVE that space out of whatever you have available at the moment.

MAKING TIME. The authors I mentioned, plus Bolker and Boyle Single, all suggest that you should designate (or carve) *SOME* time to sustain a writing practice. Most people say 15 minutes is not even enough to launch the laptop. Probably, BUT I have found that if I am able to devote at least 15-30 mins to writing, I feel like it helps ME move my work forward.

I try to always remind people that nobody has the same schedule. Contingent faculty cobbling courses together don’t have the luxury of carving time. Let’s fight this. I want an academia where contingent faculty are moved up to permanent contracts, where they are paid decent wages, and where they are able to carve time to write instead of having to struggle to make ends meet.

At any rate, for me, carving chunks of time and creating a physical space are also associated with creating a “mental space”. My brain needs to be “in the right head space” to write.

ENERGY: You need the right amount of energy to write. This is something I realized when I started with my chronic fatigue/pain. I don’t always have the energy to write. Again, most writers (but especially Jensen) suggest that we acknowledge that in order to write we need to be in decent/optimal energy/health state.

Nobody can provide a magic formula for how to develop the energy to write simply because we are all different (and I recommend that you read Chronically Academic, so you can understand the struggles of individuals facing chronic illness, and many of the wonderful folks who are courageous and brave and speak out about mental health issues. Let’s accept that academia is a highly competitive environment that has at the very least the potential to have very negative effects on people. Let’s also admit that to write we need energy/mental state.

PROCESS: Zerubavel, Dunleavy, Single, Sword and Jensen all emphasize that we should have a writing practice. John Warner’s The Writer’s Practice provides some examples of how to develop one, I do have mine (you can check blog posts I’ve written on this topic by clicking on this link)

There is huge variation across writing practices. Some authors recommend writing every day (Jensen, Zinsser) because, you know, it’s like a muscle, others (Zerubavel) suggest that you block out when you CAN’T write and make the time for writing based on those “Can’t Do” slots.

PREPARATION AND PLANNING – this is the part that I see very clearly in Zerubavel, Single, Jensen, Dunleavy, Heard, Sternberg: you need to pre-write (which includes outlining, reading, researching, synthesizing literature, gathering data, analyzing, etc.) before writing.

AUDIENCE: Warner, Germano, Rabiner and Fortunato, Zinsser, Kamler and Thomson all insist that part of your preparation includes determining the audience. This is also why I love Josh Bernoff’s Writing Without Bullshit. Our audience wants (for the most part) clear prose, although I know a few academics who seem to revel in writing obscure stuff.

QUALITY AND QUANTITY – Paul Silvia tells you that you should write a lot, which coincides with most advice (Bolker and Dunleavy included) that says that “the best dissertation is the done dissertation”. I don’t know if you should write a lot, but what works for me instead is breaking down the work in smaller components and then engage with those work packets.

I write memorandums, synthetic notes, rows in my Conceptual Synthesis Excel Dump. I try to write a bit every day (I’m not a “words per day guy” for the most part). Most advice does suggest “words per day” as a metric, but your mileage may vary. I encourage my students and research assistants to look at “paragraphs and sentences completed” instead.

On quality: I’ve seen some very senior academics say “I don’t want to read a half-baked paper when peer-reviewing”. I’m going to try to say this in the nicest way possible: “Remember that your definition of half-baked may not be that of other people, please provide kind, concise and actionable feedback on how someone can turn a half-baked paper into something that you’d like to read”. Particularly senior people, you’ve been in this business longer. Please help out whenever you can.

SUMMARY: There is no perfect approach to writing. I examine my own process regularly, adjust, change, try different things. Waking up early to write works for me, writing every day works for me, reading about how to improve my writing works for me.

YOU DO YOU.

And remember: we all struggle with our writing.

I don’t know who needs to hear this, but…

All writers that I know, seasoned writers (myself included), beginners, mid-career, everyone struggles with their writing.

It’s challenging to start writing, to continue writing and to complete a piece of writing.

Writing is HARD.

— Dr Raul Pacheco-Vega (@raulpacheco) July 23, 2019

Google dropped exciting news on us today with the announcement that it packed a ‘Soli’ sensor into the Pixel 4, allowing users to interact with the phone without touching it.

In the announcement video, the company showcased a user swiping above the phone without touching it to change songs. The accompanying blog post added that Soli could be used to snooze alarms and silence phone calls.

This isn’t the first we’ve heard of or seen of Project Soli. A Google I/O 2015 video from the company’s Advanced Technology and Projects group (ATAP) showcased a little more about what we can expect from Soli.

In one of the videos, the sensor detects when a user makes their hand into a phone shape. This then triggers the phone to answer a call.

The sensor also can detect different materials. In the demo video, the technology could even tell the difference between a variety of metals and liquids in cups based on their density.

Another video from Google I/O in 2015 showed off how the system can be used to detect a variety of motions such as pushing, twisting and more.

While at the time Google didn’t show off these motions in action, it seems like it could be used for scrolling on your device without touching it, among other things.

You can learn even more about Soli from ATAP’s website about the project. 

Source: ATAP, Google

The post Google packed a ‘Soli’ sensor into the Pixel 4, this is what it’s capable of appeared first on MobileSyrup.

This is inspired by Dan Luu's post on the advantages of a single big repository over many small ones. That post is fairly old, and I confess that I'm hardly up to date on the state of tooling, both for managing multiple repos and for dealing with one big one. But I'm going to make an argument which I think mostly works regardless of the state of tooling on any given day:

• Monorepo is great if you're really good, but absolutely terrible if you're not that good.
• Multiple repos, on the other hand, are passable for everyone – they're never great, but they're never truly terrible, either.

If you agree with the above, the choice is up to your personal philosophy. To me, for instance, it's a no-brainer – I'll choose the passable thing which successfully withstands contact with apathetic mediocrity over the greater thing which falls apart upon such contact in a heartbeat.

You might be different – you might believe in Good – and then you'll choose a monorepo, like Google, the ultimate force for Good in technology (which is why they safeguard your personal data; you wouldn't want someone evil to have it – luckily, Google can do no evil.) And I'm almost not kidding: the superpower which lets Google maintain the grassroots bureaucracy which I find necessary to make monorepos work well is actually the same trait making you sufficiently delusional to chant, or at least to have chanted "Don't Be Evil" entirely seriously. I don't have that. I am, to a first approximation, evil. Worse is Better.

But that's me – I'm not saying you/your org are Not So Good, or Evil. I'm only saying that you should be open to the possibility, and that I don't see the implications of being Not So Good discussed as much as they deserve.

Why are monorepos terrible if you're not that good? Three reasons:

1. Branching in
2. Modularity out
3. Tooling strained

Let's discuss them in some detail.

Branching: getting forked by your worst programmer

In a Good team, you don't have multiple concurrent branches from which actual product deliveries are produced, and/or where most people get to maintain these branches simultaneously for a long time. And you certainly can't have branching due to outright atrocities, like someone adding a feature by killing a feature – for example, making the app work on Android, but destroying the ability to build for iOS in the process.

But in a not-so-good team… you get the idea.

What do you do when you have a branch working on Android and another branch working on iOS and you have deliveries on both platforms? You postpone the merge, and keep the fork. For how long do you postpone the merge? For as long as is necessary for the dumbass who caused the fork to fix their handiwork, in parallel with delivering more features (which likely results in digging a deeper hole to climb out of afterwards.) And the dumbass might take months, years, or forever.

The question then becomes, what was forked?

In a multi-repo world, the repo maintained by the team with the dumbass on it got forked. In a monorepo world, the entire code base got forked, and the entire org is now held hostage by the dumbass. And you might think that this will result in a lot of pressure to fix the problem, and you'd be wrong, for the same reasons that high murder rates don't cure themselves by people putting pressure on whomever to lower them to some equilibrium level common to all human societies.

Some places have higher than average murder rates, and some places have have higher than average fork rates. And I argue that a lot of places have fork rates which combine into a complete disaster with a monorepo. And you might not even realize how bad the fork rate is at your place, because multiple repos largely shield you from the consequences. Or, more tragically, you might not realize how bad your fork rate is because your monorepo is in its first couple of years, and you're sowing what you'll reap in its next couple of years, when you'll have more code, more deliveries and more dumbasses.

With multiple repos, if you have your shit under control, and your repos have a single release branch with a single timeline, all you have to do is to test against both of the dumbass's branches. But with a monorepo, you need to maintain your code in 2 branches, with a growing share of everybody else's code morphing incompatibly in those branches, simply because they exist. And very soon it will be more than 2 because there's more than a single dumbass, and good luck to you.

Modularity: demoted from a norm to an ideal

Norms are mundane, but they are what is. Ideals are lofty, but they are merely what should be (and typically isn't.) If you want to actually have something, you don't want it to be an ideal, like altruism – you want it to be a norm, like wiping one's ass. If something is demoted from ass-wiping to altruism, that something will scarcely be found in the wild.

With multiple repos, modularity is the norm. It's not a must - you technically can have a repo depending on umpteen other repos. But your teammates expect to be able to work with their repo with a minimal set of dependencies. They don't like to have to clone lots of other repos, and to then worry about their versions (in part because the tooling support for this might be less than great).

In fact, a common multi-repo failure mode is that people expect too few dependencies and make too many repos which are too small to host a useful self-contained system. Note that this failure mode is not lethal. It kinda sucks to have this over-modularity with benefits of independence which turn out to be imaginary upon a closer look, and to have people treat what essentially are internal APIs with way too much reverence, just because two modules which are extremely tightly coupled conceptually are independent technically, in terms of cloning/building/testing. But it doesn't kill you.

With a monorepo, modularity is a mere ideal. Everybody clones the whole thing. You're not supposed to add gratuitous dependencies, but it's very easy to add such a dependency in terms of cloning, building and versioning, and nobody objects to the dependency being added the way they would if they needed to clone more repos.

Of course in a Good team, needless dependencies would be weeded out in code reviews, and a Culture would evolve over time avoiding needless dependencies. In a not-so-good team, your monorepo will grow into a single giant ball of circular dependencies. Note that adding dependencies is infinitely easier than untangling them, much like forking is easier than merging, with the difference that the gut-felt urgency to merge ("I can't maintain all your damned branches any longer!!") is far greater and far more backed by simple self-interest than the urgency to improve the dependency structure.

Tooling: is yours better than the standard?

This part might age worse than the others, and might not be particularly up to date even now – what "standard" tools are capable of changes over time. But generally speaking, a growing monorepo is likely to outgrow the standard version management tools and methods, as well as other tools and methods dealing with your revision controlled code.

Google used to have a FUSE driver to avoid copying hundreds of millions of source lines at a time, and instead getting the files on demand, when a directory is cd'd into. Facebook used to hack on hg to make it fast on its large monorepo. Maybe already today, or some day, a growing number of off-the-shelf tools will scale to infinite monorepos without such investments. But it sounds reasonable that there will always be tools and workflows which you will struggle to make work with a large monorepo (starting with some script doing find/grep.)

With a bunch of small monorepos, you work with a small overall number of source files in your working directory, so you don't need to tell your tools, "don't try to deal with the whole thing – instead only search this subset, or use this index etc. etc." And you have tools these days which kinda sorta let you manage the revisions of multiple repositories (for instance, there's Google's Repo.) And I think the result is very, very far from a great experience potentially afforded by a large monorepo. But it also never breaks down as badly as a large monorepo outgrowing the abilities of tools, as well as the ability of your local toolsmiths to find creative workarounds for these growth pains.

Summary

Don't ask if a monorepo is good for you – ask if you're good enough for a monorepo. Personally, I don't have the guts to bet on the supply of Goodness in a given org to remain sufficiently large over time to consistently avert the potential disasters of monorepos. But that's just my personal outlook; if you want to compliment me, don't call me "smart," and definitely don't call me "good" – I know my limits in these areas, and I take far more pride in knowing these limits than in the limits themselves; so, to compliment me, call me "pragmatic." Yet a culture worthy of a monorepo absolutely can exist – just make sure yours actually is one of those, and don't mistake your ideals for your norms.

Every school in South Dakota must now display the motto “In God We Trust” in a prominent location. I have two problems with this: a God problem and a trust problem. South Dakota’s legislature passed the law, joining other states with similar rules including Kentucky. Now every student will be confronted with a statement about … Continued

The post In God we trust? appeared first on without bullshit.

We are proud to unveil the final specifications for the Librem 5 smartphone, set to begin shipping in Q3 of 2019. Here’s the high level hardware specs:

---

Librem 5

Display : 5.7″ IPS TFT screen @ 720×1440
Processor: i.MX8M (Quad Core) max. 1.5GHz
Memory: 3GB RAM
Storage: 32 GB eMMC internal storage
External Storage: microSD storage expansion
Wireless: 802.11abgn 2.4 Ghz / 5Ghz + Bluetooth 4
Baseband: Gemalto PLS8 3G/4G modem w/ single SIM on replaceable M.2 card
GPS: Teseo LIV3F GNSS
Smartcard: Reader with 2FF card slot (SIM card size)
Sound: 1 earpiece speaker, 3.5mm headphone jack
Accelerometer: 9-axis IMU (gyro, accel, compass)
Front Camera: 8 MPixel
Back Camera: 13 MPixel w/LED flash
Vibration motor: Included
USB Type C: USB 3.0 data, Charging (Dual-Role Port), Video out
Battery: User replaceable – 3,500 mAh

---

You can pre-order the Librem 5 for the early bird discounted price of $649 — with the price going up $50 after July 31st.

Here’s a more detailed breakdown of the Librem 5 hardware and specific components included:

CPU i.MX8M @ max. 1.5GHz

• Quad core Cortex A53, 64bit ARM
• GPU: Vivante GC7000Lite (hardware supports OpenGL/ES 3.1, Vulkan, OpenCL 1.2)
• Auxiliary Cortex M4

RAM:

• 3GB RAM

Storage:

• Internal 32GB eMMC
• microSD storage expansion slot (max 2 TB)

Display:

• 5.7″ IPS TFT screen @ 720×1440

3 Hardware Kill Switches:

• WiFi / Bluetooth
• Cellular Baseband
• Cameras & microphone
• All 3 off = additionally disable IMU+compass & GNSS, ambient light and proximity sensors

Other Buttons:

• Power button, Volume ± buttons

Battery:

• 3,500mAh, user replaceable

Wireless:

• 802.11abgn 2.4 Ghz / 5Ghz + Bluetooth 4

Baseband:

• Option 1: Gemalto PLS8 3G/4G modem w/ single SIM on replaceable M.2 card
• Option 2: Broadmobi BM818 (made in China)
• nanoSIM tray for cellular

GPS:

• Teseo LIV3F GNSS

Cameras:

• Rear camera @ 13 MPixel
• Camera flash LED for rear camera
• Front camera @ 8 MPixel

USB Type-C Port:

• USB3.0 data
• Power Delivery (Dual-Role Port)
• Video out

Audio:

• 1 earpiece speaker + digital microphone
• 3.5mm headphone jack with stereo out and mono microphone input
• Audio DAC: Wolfson Media WM8962
• 1 loudspeaker

Smartcard:

• Reader with 2FF card slot (SIM card size)

Notification Lights:

• RGB LED with PWM control per color

Other Sensors, Components:

• Acceleration, gyro and compass sensor (“9-axis” by ST, LSM9DS1)
• Ambient light and proximity sensor: VCNL4040
• Haptic motor

The post Librem 5 Smartphone – Final Specs Announced appeared first on Purism.

Research has shown that walking is good for your physical and mental health, and building cities and spaces that are connected and walkable provide increased opportunities for social interaction. Transportation expert Jeff Tumlin has a TEDx Talk on Sex, Neuroscience and the City pointing out how vital these links are.

NPR.com’s Paul Nicolaus explored current research on every day interaction on the street.  Elizabeth Dunn and Gillian Sandstrom from the University of British Columbia studied the impact of customers talking to staff in coffee shops, with half of the people asked to interact with staff, and half not to interact. They found that those that had limited interaction with the coffee shop staff  increased their general mood and increased happiness.

“The same researchers found that these seemingly trivial encounters with the minor characters in our lives — the random guy at the dog park or the barista at our local coffee shop — can affect feelings of happiness and human connection on a typical day.”

Studies also found that when walking brief eye contact “increased people’s sense of inclusion and belonging”,  and can trigger the neural release of the peptide hormone oxytocin, called the “cuddle chemical” in Jeff Tumlin’s TEDx talk.

No one likes feeling invisible when someone walks past. The Germans even have a term for it — wie Luft behandeln, which means “to be looked at as though air.” And while people may not necessarily want to talk to everyone they meet on the street or in the coffee shop,  psychologists have ascertained that even brief eye contact increases the sense of inclusion and belonging.

As University of Chicago’s behavioural scientist  Nicolas Epley describes it “The mood boost of talking to strangers may seem fleeting, but the research on well-being suggests that a happy life is made up of a high frequency of positive events, and even small positive experiences make a difference. Happiness seems a little bit like a leaky tire on a car. We just sort of have to keep pumping it up a bit to maintain it.”

You can take a look at Jeff Tumlin’s TEDx talk on the benefits of  social interaction on the street here.

The ware for July 2019 is shown below.

ISA, I say! Back in the day when all it took was a couple 7400 series chips to talk to a computer…now we use a small computer just to properly negotiate power before talking for real over standards like USB-C.

Thanks to Nava for contributing this ware, found at Akihabalast, “Akihabara final waste disposal site!”.

For more than a century, one school of political science dominated the education of Turkey’s governing class — until the Erdogan regime set about destroying it.

Buy it now:
– Nokia 9 PureView (ship to US): https://amzn.to/2LL2HWr
– Nokia 9 PureView (ship abroad): https://www.gearbest.com/cell-phones/pp_009384229006.html?lkid=46172535
– OnePlus 7 Pro: https://www.gearbest.com/cell-phones/pp_009344732282.html?lkid=46172661
– Huawei P30 Pro: https://www.gearbest.com/cell-phones/pp_009365143046.html?lkid=46172756

Deals:
– OnePlus 7 8+256 Gray, $469.99: https://www.gearbest.com/cell-phones/pp_009591521059.html?lkid=45651578
– Huawei P30 Lite 6+128, $299.99: https://www.gearbest.com/cell-phones/pp_009928688347.html?lkid=46171597
– Get free Supercharging for your Tesla: https://ts.la/myriam23187

Support the channel:

Sponsors:
– Get 50% off proXPN: https://secure.proxpn.com/?a_aid=5c184e7abd686

Subscribe to my podcast: http://www.mobiletechpodcast.com
Subscribe to my YouTube channel: https://www.youtube.com/MyriamJoire
Follow me on Twitter: https://twitter.com/tnkgrl
Follow me on Instagram: https://www.instagram.com/tnkgrl/
Read me on GeekSpin: https://geekspin.co/author/myriam-joire/
Read me on Android Police: https://www.androidpolice.com/author/myriam-joire/

Over 5 years ago I wrote No more JS frameworks and just recently Jon Udell asked for an update.

It's almost 4 years since @bitworking said: "Stop using JS frameworks, start writing reusable, orthogonally-composable units of HTML+CSS+JS."

I'm curious, Joe, about what you've since learned, thought about, and done with the idea.https://t.co/zdKjEZfIe3

— Jon Udell (@judell) July 17, 2019

I have been blogging bits and pieces over the years but Jon’s query has given me a good excuse to roll all of that up into a single document.

For the last five years me and my team have been using web components to build our web UIs. At the time I wrote the Zero Framework Manifesto we moved all of our development over to Polymer.

Why Polymer?

We started with Polymer 0.5 as it was the closest thing to web components that was available. At the time I wrote the Zero Framework Manifest all of the specifications that made up web components were still just proposed standards and only Chrome had implemented any of them natively. We closely followed Polymer, migrating all of our apps to Polymer 0.8 and finally to Polymer 1.0 when it was released. This gave us a good taste for what building web components was like and verified that building HTML elements was a productive way to do web development.

How

One of the questions that comes up regularly when talking about zero frameworks is how can you expect to stitch together an application without a framework? The short answer is ‘the same way you stitch together native elements’, but I think it’s interesting and instructional to look at those ways of stitching elements together individually.

There are six surfaces, or points of contact, between elements, that you can use when stitching elements together, whether they are native or custom elements.

Before we go further a couple notes on terminology and scope. For scope, realize that we are only talking about DOM, we aren’t talking about composing JS modules or strategies for composing CSS. For the terminology clarification, when talking about DOM I’m referring to the DOM Interface for an element, not the element markup. Note that there is a subtle difference between the markup element and the DOM Interface to such an element.

For example, <img data-foo="5" src="https://example.com/image.png"/> may be the markup for an image. The corresponding DOM Interface has an attribute of src with a value of https://example.com/image.png but the corresponding DOM Interface doesn’t have a data-foo attribute, instead all data-* attributes are available via the dataset attribute on the DOM Interface. In the terminology of the WhatWG Living Standard, this is the distinction between content attributes vs IDL attributes, and I’ll only be referring to IDL attributes.

With the preliminaries out of the way let’s get into the six surfaces that can be used to stitch together an application.

Attributes and Methods

The first two surfaces, and probably the most obvious, are attributes and methods. If you are interacting with an element it’s usually either reading and writing attribute values:

element.children

or calling element methods:

document.querySelector('#foo');

Technically these are the same thing, as they are both just properties with different types. Native elements have their set of defined attributes and methods, and depending on which element a custom element is derived from it will also have that base element’s attributes and methods along with the custom ones it defines.

Events

The next two surface are events. Events are actually two surfaces because an element can listen for events,

ele.addEventListener(‘some-event’, function(e) { /* */ });

and an element can dispatch its own events:

var e = new CustomEvent(‘some-event’, {details: details});
this.dispatchEvent(e);

DOM Position

The final two surfaces are position in the DOM tree, and again I’m counting this as two surfaces because each element has a parent and can be a parent to another element. Yeah, an element has siblings too, but that would bring the total count of surfaces to seven and ruin my nice round even six.

<button>
  <img src="">
</button>

Combinations are powerful

Let’s look at a relatively simple but powerful example, the ‘sort-stuff’ element. This is a custom element that allows the user to sort elements. All children of ‘sort-stuff’ with an attribute of ‘data-key’ are used for sorting the children of the element pointed to by the sort-stuff’s ‘target’ attribute. See below for an example usage:

 <sort-stuff target='#sortable'>
   <button data-key=one>Sort on One</button>
   <button data-key=two>Sort on Two</button>
 </sort-stuff>
 <ul id=sortable>
   <li data-one=c data-two=x>Item 3</li>
   <li data-one=a data-two=z>Item 1</li>
   <li data-one=d data-two=w>Item 4</li>
   <li data-one=b data-two=y>Item 2</li>
   <li data-one=e data-two=v>Item 5</li>
 </ul>

If the user presses the “Sort on One” button then the children of #sortable are sorted in alphabetical order of their data-one attributes. If the user presses the “Sort on Two” button then the children of #sortable are sorted in alphabetical order of their data-two attributes.

Here is the definition of the ‘sort-stuff’ element:

And here is a running example of the code above:

• Item 3
• Item 1
• Item 4
• Item 2
• Item 5

Note the surfaces that were used in constructing this functionality:

1. sort-stuff has an attribute 'target' that selects the element to sort.
2. The target children have data attributes that elements are sorted on.
3. sort-stuff registers for 'click' events from its children.
4. sort-stuff children have data attributes that determine how the target children will be sorted.

In addition you could imagine adding a custom event ‘sorted’ that ‘sort-stuff’ could generate each time it sorts.

Why not Polymer?

But after having used Polymer for so many years we looked at the direction of Polymer 2.0 and now 3.0 and decided that may not be the direction we want to take.

There are a few reasons we moved away from Polymer. Polymer started out and continues to be a platform for experimentation with proposed standards, which is great, as they are able to give concrete feedback to standards committees and allow people to see how those proposed standards could be used in development. The downside to the approach of adopting nascent standards is that sometimes those things don’t become standards. For example, HTML Imports was a part of Polymer 1.0 that had a major impact on how you wrote your elements, and when HTML Imports failed to become a standard you had a choice of either a major migration to ES modules or to carry around a polyfill for HTML Imports for the remainder of that web app’s life. You can see the same thing happening today with Polymer 3.0 and CSS mixins.

There are also implementation decisions I don’t completely agree with in Polymer, for example, the default use of Shadow DOM. Shadow DOM allows for the encapsulation of the children of a custom element so they don’t participate in things like querySelector() and normal CSS styling. But there are several problems with that, the first is that when using Shadow DOM you lose the ability to do global styling changes. If you suddenly decide to add a “dark mode” to your app you will need to go and modify each element’s CSS. It was also supposed to be faster, but since each element contains a copy of the CSS there are performance implications, though there is work underway to address that. Shadow DOM seems like a solution searching for a problem, and Polymer defaults to using Shadow DOM while offering a way to opt out and use Light DOM for your elements; I believe the default should lie in the other direction.

Finally Polymer’s data binding has some mis-features. It offers two-way data binding which is never a good idea, every instance of two-way data binding is just a bug waiting to happen. The data binding also has a lot of magic to it, in theory you just update your model and Polymer will re-render your template at some point in the future with the updated values. The “at some point in the future” is because updates happen in an async fashion, which in theory allows the updates to be more efficient by batching the updates, but the reality is that you spend a lot of development time updating your model, not getting updated DOM, and scratching your head until you remember to either call a function which forces a synchronous render, or that you updated a deep part of your model and Polymer can’t observe that change so you need to update your code to use the set() method where you give the path to the part of the model you just updated. The async rendering and observing of data is fine for simple applications, but for more complex applications leads to wasted developer time debugging situations where a simpler data binding model would suffice.

It is interesting to note that the Polymer team also produces the lit-html library which is simply a library for templating that uses template literals and HTML Templates to make the rendering more efficient, and it has none of the issues I just pointed out in Polymer.

What comes after Polymer?

This is where I started with a very concrete and data driven minimalist approach, first determining what base elements we really needed and then what library features we would need as we built up those elements, and finally what features we need as we build full fledged apps from those base elements. I was completely open to the idea that maybe I was just being naive about the need for async render or Shadow DOM and I’d let the process of building real world applications inform what features were really needed.

The first step was to determine which base elements we really needed. The library of iron-* and paper-* elements that Polymer provides is large and the idea of writing our own version of each was formidable, so instead I looked back over the previous years of code we’d written in Polymer to determine which elements we really did need. If we’d started this process today I would probably just have gone with Elix or another pure web components library of elements, but none of them existed at the time we started this process.

The first thing I did was scan each project and record every Polymer element used in every project. If I’m going to replace Polymer at least I should know how many elements I’m signing up to rewrite. That initial list was surpising in a couple of ways, the first was how short the list was:

After four years of development I expected the list to be much larger.

The second surpise was how many of the elements in that list really shouldn’t be elements at all. For example, some could be replaced with native elements with some better styling, for example button for paper-button. Alternatively some could be replaced with CSS or a non-element solution, such as iron-ajax, which shouldn’t be an element at all and should be replaced with the fetch() function. After doing that analysis the number of elements actually needed to be re-implemented from Polymer fell to a very small number.

In the table below the ‘Native’ column is for places where we could use native elements and just have a good default styling for them. The ‘Use Instead’ column is what we could use in place of a custom element. Here you will notice a large number of elements that can be replaced with CSS. Finally the last column, ‘Replacement Element’, is the name of the element we made to replace the Polymer element:

** - For radio-sk elements just set a common name like you would for a native radio button.

That set of minimal custom elements has now been launched as elements-sk.

Now that we have our base list of elements let’s think about the rest of the tools and techniques we are going to need.

To get a better feel for this let’s start by looking at what a web framework “normally” provides. The “normally” is in quotes because not all frameworks provide all of these features, but most frameworks provide a majority of them:

• Framework
  • Model
  • Tooling and structure
  • Elements
  • Templating
  • State Management

All good things, but why do they have to be bundled together like a TV dinner? Let’s break each of those aspects of a framework out into their own standalone thing and then we can pick and choose from the various implementations when we start developing an application. This style of developement we call “a la carte” web development.

Instead of picking a monolithic solution like a web framework, you just pick the pieces you need. Below I outline specific criteria that need to be met for some components to participate in “a la carte” web development.

A la carte

“A la carte” web development does away with the framework, and says just use the browser for the model, and the rest of the pieces you pick and choose the ones that work for you. In a la carte development each bullet point is a separate piece of software:

A la carte

Tooling and structure

Defines a directory structure for how a project is put together and provides tooling such as JS transpiling, CSS prefixing, etc. for projects that conform to that directory structure. Expects ES modules with the extension that webpack, rollup, and similar tools presume, i.e. allow importing other types of files, see webpack loaders.

Elements

A library of v1 custom elements in ES6 modules. Note that these elements must be provided in ES6 modules with the extension that webpack, rollup, and similar tools presume, i.e. allow importing other types of files, see webpack loaders. The elements should also be “neat”, i.e. just HTML, CSS, and JS.

Templating

Any templating library you like, as long as it works with v1 custom elements.

State Management

Any state management library you like, if you even need one.

The assumptions needed for all of this to work together are fairly minimal:

1. ES6 modules and the extension that webpack, rollup, and similar tools presume, i.e. allow importing other types of files, see webpack loaders.
2. The base elements are “Neat”, i.e. they are JS, CSS, and HTML only. No additional libraries are used, such as a templating library. Note that sets of ‘neat’ elements also conform to #1, i.e. they are provided as webpack/rollup compatible ES6 modules.

Obviously there are other guidelines that could be added as advisory, for example Google Developers Guide - Custom Elements Best Practices, should be followed when creating custom elements sets, except for the admonition to use Shadow DOM, which I would avoid for now, unless you really need it.

Such code will natively run in browsers that support custom elements v1. To get it to run in a wider range of browsers you will need to add polyfills and, depending on the target browser version, compile the JS back to an older version of ES, and run a prefixer on the CSS. The wider the target set of browsers and the older the versions you are targeting the more processing you will need to do, but the original code doesn’t need to change, and all those extra processing steps are only incurred by projects that need it.

Concrete

So now that we have our development system we’ve started to publish some of those pieces.

We published pulito, a stake in the ground for what a “tooling and structure” component looks like. You will note that it isn’t very complex, nothing more than an opinionated webpack config file. Similarly we published our set of “neat” custom elements elements-sk.

Our current stack looks like:

Tooling and structure

pulito

Elements

elements-sk

Templating

lit-html

We have used Redux in an experimental app that never shipped and haven’t needed any state management libraries in the other applications we’ve ported over, so our ‘state management’ library is still an open question.

Example

What is like to use this stack? Let’s start from an empty directory and start building a web app:

$ npm init
$ npm add pulito

We are starting from scratch so use the project skeleton that pulito provides:

$ unzip node_modules/pulito/skeleton.zip
$ npm

We can now run the dev server and see our running skeleton application:

$ make serve

Now let’s add in elements-sk and add a set of tabs to the UI.

$ npm add elements-sk

Now add imports to pages/index.js to bring in the elements we need:

import 'elements-sk/tabs-sk'
import 'elements-sk/tabs-panel-sk'
import '../modules/example-element'

And then use those elements on pages/index.html:

<body>
  <tabs-sk>
    <button class=selected>Some Tab</button>
    <button>Another Tab</button>
  </tabs-sk>
  <tabs-panel-sk>
    <div>
      <p> This is Some Tab contents.</p>
    </div>
    <div>
      This is the contents for Another Tab.
    </div>
  </tabs-panel-sk>
  <example-element active></example-element>
</body>

Now restart the dev server and see the updated page:

$ make serve

Why is this better?

Web frameworks usually make all these choices for you, you don’t get to choose, even if you don’t need the functionality. For example, state managament might not be needed, why are you ‘paying’ for it, where ‘paying’ means learning about that aspect of the web framework, and possibly even having to serve the code that implements state managment even if you never use it. With “a la carte” development you only include what you use.

An extra benefit comes when it is time to upgrade. How much time have you lost with massive upgrades from v1 to v2 of a web framework? With ‘a la carte’ developement the upgrades don’t have to be monolithic. I.e. if you’ve chosen a templating library and want to upgrade to the next version you only need to update your templates, and not have to touch every aspect of your application.

Finally, ‘a la carte’ web development provides no “model” but the browser. Of all the things that frameworks provide, “model” is the most problematic. Instead of just using the browser as it is, many frameworks have their own model of the browser, how DOM works, how events work, etc. I have gone into depth on the issues previously, but they can be summarized as lost effort (learning something that doesn’t translate) and a barrier to reuse. What should replace it? Just use the browser, it already has a model for how to combine elements together, and now with custom elements v1 gives you the ability to create your own elements, you have all you need.

One of the most important aspects of ‘a la carte’ web developement is that it decouples all the components, allowing them to evolve and adapt to user needs on a much faster cycle than the normal web framework release cycle allows. Just because we’ve published pulito and elements-sk doesn’t mean we believe they are the best solutions. I’d love to have a slew of options to choose from for tooling, base element sets, templating, and state management. I’d like to see Rollup based tools that take the place of pulito, and a whole swarm of “neat” custom elements sets with varying levels of customizability and breadth.

What we’ve learned

We continue to learn as we build larger applications.

lit-html is very fast and all the applications we’ve ported over have been smaller and faster after the port. It is rather pleasant to call the render() function and know that the element has been rendered and not getting tripped up by async rendering. We haven’t found the need for async rendering either, but that’s not surprising. Let’s think about cases where async rendering would make a big difference, i.e. where it would be a big performance difference to batch up renders and do them asynchronously. This would have to be an element with a large number of properties and each change of the property would change the DOM expressed and thus would require a large number of calls to render(). But in all the development we’ve done that situation has never arisen, elements always have a small number of attributes and properties. If an element takes in a large amount of data to display that’s usually done by passing in a small number of complex object as properties on the element and that results in a small number of renders.

We haven’t found the need for Shadow DOM. In fact, I’ve come to think of the Light DOM children of elements as part of their public API that goes along with the attributes, properties, and events that make up the ‘normal’ programming surface of an element.

We’ve also learned that there’s a difference between creating base elements and higher level elements as you build up your application. You are not creating bullet-proof re-usable elements at every step of development; the same level of detail and re-usability aren’t needed as you move up the stack. If an element looks like it could be re-used across applications then we may tighten up the surface of the element and add more options to cover more use cases, but that’s done on an as-needed basis, not for every element. Just because you are using the web component APIs to build an application doesn’t mean that every element you build needs to be as general purpose and bullet proof as low level elements. You can use HTML Templates without using any other web component technology. Same for template literals, and for each of the separate technologies that make up the web components group of APIs.

I agree with this statement: "The problem isn't privacy," the cryptography pioneer Whitfield Diffie said recently. "It's corporate malfeasance." Wendy Grossman continues, " Viewed that way, when data profiteers claim that "privacy is no longer a social norm", as Facebook CEO Mark Zuckerberg did in 2010, the correct response is not to argue about privacy settings or plead with users to think again, but to find out if they've broken the law." Via Ton Zijlstra.