QuirksBlog

Syndicate content
Updated: 22 hours 29 min ago

Chromedge and headcount

Tue, 12/11/2018 - 6:16am

So Microsoft is going to retire EdgeHTML and use Chromium instead for Edge while not really answering the question if the web [is] better off with less engine diversity. This upset people, and Mozilla, especially, is worrying about the future:

Will Microsoft’s decision make it harder for Firefox to prosper? It could. Making Google more powerful is risky on many fronts. [...] If one product like Chromium has enough market share, then it becomes easier for web developers and businesses to decide not to worry if their services and sites work with anything other than Chromium. That’s what happened when Microsoft had a monopoly on browsers in the early 2000s before Firefox was released. And it could happen again.

Before you lament the return to a Microsoft-like monopoly, remember what happened to Microsoft’s monopoly. In fact, remember what happened to the lineal descendant of that monopoly just last week. Near-monopolies do not necessarily mean the end of the web.

Browser diversity

Back then, Microsoft stopped developing IE because it thought it had won. Right now, Google is doing no such thing — in fact, I think it’s moving too fast rather than too slow.

Back then, Microsoft welcomed the IE-only badges that sprung up on countless websites. Right now, the Chrome devrel team does not. In fact, they don’t hesitate to criticise Chrome-only sites created by other parts of Google.

Also, don’t forget WebKit. Right now web developers pretend there are only two rendering engines left, Gecko and Blink, but there is in fact a third one, and especially on mobile it’s quite important. (When did you last create a site that didn’t really have to work on iOS?)

Today’s situation is very different from fifteen years ago — though I still think web developers switching to Firefox as their default browser is a good idea. (No, I haven’t yet done so either.)

Headcount

But I don’t really want to talk about browser diversity, or about the relative merits of present-day Google and past Microsoft.

Instead, I want to talk about headcount.

The IE team first asked for my regarded opinion somewhere in 2005 or so, when they were gearing up toward IE7. Since then I’ve been in touch with them, and followed their progress with interest, occasionally submitting feature lists or clarifying our web developer point of view.

During all those years, I had the distinct feeling the IE team was under-staffed — a feeling that was occasionally, if privately, confirmed by team members. It seemed that, while Microsoft had decided to continue the development of IE, it didn’t want to commit the full resources that the project warranted.

That’s why, in the immediate aftermath of Microsoft confirming the rumour, I was quite surprised to see a We’re hiring message. (Granted, the actual job descriptions don’t mention Chromium, but they were written in October or November.)

Next, I saw this tweet by Tom Dale:

I understand why people are nervous about a Chrome monoculture. I think this case is a little different though. Microsoft has an army of engineers working on Edge. They’re one of the few companies who can go toe-to-toe with Google funding browser development.

Now I don’t follow Tom, and the only reason I saw his tweet is that it was retweeted by an Edge team member. Sure, RT !== endorsement, but this was a curious coincidence, to say the least.

Is one unexpected benefit of the switch to Chromium that the Edge team can actually expand? It’s easier to get Chromium engineers than EdgeHTML ones, that’s for sure.

Android

If Microsoft does solve its headcount problems, then things get interesting — especially on Android. Sure, Microsoft has more opportunities for expanding its market share elsewhere, notably Windows 7 (where EdgeHTML never ran), but Android is by far the most interesting one.

One huge advantage of moving to Chromium is that Edge can now be easily ported to Android. This tweet appears to confirm that an Android version is in the planning.

Let’s jump sideways for a moment. Google Services is a suite of Android apps such as Play, Search, Maps, YouTube, and other crucial services that pretty much define how useful a smartphone is. It also contains Google Chrome. Android vendors get the option of using Google Services for free, provided they use ALL of them. All non-Chinese ones actually do so, and Google Services is an important part of the hold Google has on the web and mobile markets. Also, it puts Google Chrome on every Android phone.

What if Microsoft offered the Android vendors an alternative? Microsoft has a search engine, maps, and other services. YouTube can be viewed in a browser as well as in an app — and now it has the browser. Only an alternative to the Play Store is missing — so far. It’s quite possible that some Android vendors would seriously consider such an offer. It would ease Google’s stranglehold.

In that light, I found it interesting that HTC is experimenting with Brave as its default browser on one phone model. (True, the HTC Exodus is a “blockchain phone” and when I recently visited the local phone store they didn’t have any HTC whatsoever on offer, and nomen is most definitely not an omen. Still, interesting.) And if this example doesn’t convince you, remember Samsung Internet. Non-Google Chromium browsers are a thing on Android. But they aren't part of a set of services — yet.

Anyway, IF the Edge team gets more people, and IF Microsoft decides to go the Android route, the switch to Chromium may become interesting very fast.

Linkbait 42

Tue, 12/04/2018 - 12:22am

Full-stack edition. Look no further than here.

  • Microsoft is rumoured to pull the plug on their EdgeHTML rendering engine and move to Chromium for the next Edge version. It’s always a sad moment when a rendering engine leaves us.
    Now as anyone who read my Chromium blog posts knows, one Chromium is not necessarily exactly the same as another. Thus I do not expect EdgeChromium to be 100% the same as Chrome — more like 98%.
    How to solve this? Test more in Edge — 3 years ago. Of course my readers know this and do this; it’s the full-stackers that are the problem.
  • Speaking of which. Heydon takes a stab at defining the problem with full-stack developers. They try to do too much, and as a result, code quality suffers.

    By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

    He also points out that one full-stack developer is cheaper than three specialised developers, and cost cutting is certainly part of the reason why full-stack has become so popular.
    Still, to me, it all comes down to the low esteem in which HTML/CSS is held (and Heydon also mentions that). It’s much easier to declare a low-status job redundant than a high-status one. I mean, are there large companies that have the same people do development and devops?
  • In case you’re wondering why full-stack programmers have such problems with CSS (and HTML), Robin Rendle explains. Front-end (i.e. HTML and CSS) is not a problem to be solved because, essentially, it’s already been solved. Just not by full-stack programmers.

    What’s the point in learning about vanilla HTML, CSS and JavaScript if they wind up becoming transpiled by other tools and languages?

    [...] Front-end development is complex because design is complex. Transpiling [...] into HTML and CSS requires vim and nuance, and always will. That’s not going to be resolved by a tool but by diligent work over a long period of time.

  • Jeremy compares CSS to a programming language, and finds that selectors, especially, qualify. Still, that’s exactly the part of CSS that isn’t used a lot, since we all have to go modular and use classes everywhere.
    Foor for thought; also for the book.
  • While ostensibly explaining a React feature, Dan Abramov gives a lesson about JavaScript prototypes and inheritance. Useful reading for all JavaScripters — I learned (or relearned) a thing or two here.
  • Addy Osmani takes a look at the cost of JavaScript. While they work OK-ish on modern desktop computers, huge scripts cause a lot of problems on low-end phones. (News? No, not really. But people don’t listen.) As he says,

    The web is bloated by user “experience”

    If you want facts and figures to convince others, look no further than this article.
  • Harry takes an exhaustive dive into CSS and network performance.

    Your page will only render as quickly as your slowest stylesheet.

    If you ever wanted to know absolutely everything about the way stylesheets can block page rendering, read it all. Did you know, for instance, that you should not place stylesheets before async script snippets? That’s because browsers await the full stylesheet before evaluating the snippet. What if the script requests the colour of a certain element, and the CSS hasn’t come in yet? Better to wait.
    Tons more good stuff here.
  • Interesting experiment by Daniel Buchner. He shows how to use the CSS :invalid pseudo, which triggers onkeypress, in a script, where normally the invalid event would fire onsubmit (or in a few edge cases).
    Read my native form validation series for a LOT more background information about the differences. (I didn’t think of Daniel’s trick, though. Simple, elegant, useful.)
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Linkbait 42

Tue, 12/04/2018 - 12:22am

Full-stack edition. Look no further than here.

  • Microsoft is rumoured to pull the plug on their EdgeHTML rendering engine and move to Chromium for the next Edge version. It’s always a sad moment when a rendering engine leaves us.
    Now as anyone who read my Chromium blog posts knows, one Chromium is not necessarily exactly the same as another. Thus I do not expect EdgeChromium to be 100% the same as Chrome — more like 98%.
    How to solve this? Test more in Edge — 3 years ago. Of course my readers know this and do this; it’s the full-stackers that are the problem.
  • Speaking of which. Heydon takes a stab at defining the problem with full-stack developers. They try to do too much, and as a result, code quality suffers.

    By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

    He also points out that one full-stack developer is cheaper than three specialised developers, and cost cutting is certainly part of the reason why full-stack has become so popular.
    Still, to me, it all comes down to the low esteem in which HTML/CSS is held (and Heydon also mentions that). It’s much easier to declare a low-status job redundant than a high-status one. I mean, are there large companies that have the same people do development and devops?
  • In case you’re wondering why full-stack programmers have such problems with CSS (and HTML), Robin Rendle explains. Front-end (i.e. HTML and CSS) is not a problem to be solved because, essentially, it’s already been solved. Just not by full-stack programmers.

    What’s the point in learning about vanilla HTML, CSS and JavaScript if they wind up becoming transpiled by other tools and languages?

    [...] Front-end development is complex because design is complex. Transpiling [...] into HTML and CSS requires vim and nuance, and always will. That’s not going to be resolved by a tool but by diligent work over a long period of time.

  • Jeremy compares CSS to a programming language, and finds that selectors, especially, qualify. Still, that’s exactly the part of CSS that isn’t used a lot, since we all have to go modular and use classes everywhere.
    Foor for thought; also for the book.
  • While ostensibly explaining a React feature, Dan Abramov gives a lesson about JavaScript prototypes and inheritance. Useful reading for all JavaScripters — I learned (or relearned) a thing or two here.
  • Addy Osmani takes a look at the cost of JavaScript. While they work OK-ish on modern desktop computers, huge scripts cause a lot of problems on low-end phones. (News? No, not really. But people don’t listen.) As he says,

    The web is bloated by user “experience”

    If you want facts and figures to convince others, look no further than this article.
  • Harry takes an exhaustive dive into CSS and network performance.

    Your page will only render as quickly as your slowest stylesheet.

    If you ever wanted to know absolutely everything about the way stylesheets can block page rendering, read it all. Did you know, for instance, that you should not place stylesheets before async script snippets? That’s because browsers await the full stylesheet before evaluating the snippet. What if the script requests the colour of a certain element, and the CSS hasn’t come in yet? Better to wait.
    Tons more good stuff here.
  • Interesting experiment by Daniel Buchner. He shows how to use the CSS :invalid pseudo, which triggers onkeypress, in a script, where normally the invalid event would fire onsubmit (or in a few edge cases).
    Read my native form validation series for a LOT more background information about the differences. (I didn’t think of Daniel’s trick, though. Simple, elegant, useful.)
  • Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

Fronteers considers applying for W3C membership

Thu, 09/27/2018 - 5:19am

Months of planning come to a head, and the cat is out of the bag. Fronteers, the Dutch professional association of front-end developers, is planning to apply for W3C membership and appoint Rachel Andrew as our paid representative. This would solve the problem of front-end developer representation in W3C.

Note that this plan will be submitted to the Fronteers members on 19th of October, and that they can vote it down.

Below is the press release, in case you’re interested.

Also, I wrote an A List Apart article, Rachel wrote a Smashing Magazine article, and if you read Dutch you should read the Fronteers blog post that contains the complete proposal.

Press release

On its annual general member meeting on 19th of October, the Fronteers board will propose to become a member of the World Wide Web Consortium (W3C), and to hire Rachel Andrew as our representative in that standards body. By becoming a W3C member, Fronteers aims to be the first membership organisation to give front-end developers a voice (and vote) in web standards.

While W3C has always desired input from front-end developers, and some of them became Invited Experts and contributed to the discussions, these experts had to do so in their own spare time and at their own expense. Fronteers aims to change that.

Our W3C membership is not yet set in stone: the Fronteers general member meeting will have to approve of this plan (and its financial consequences), which will be laid before it on 19th of October. Rachel Andrew will be present to explain the consequences to the Fronteers members.

Founded in 2007, Fronteers is the professional association of Dutch front-end developers. It is best known for its annual Fronteers conference in October, but it has been locally active with workshops, meet-ups, a job board, and other activities for Dutch front-enders.

The World Wide Web Consortium (W3C) is the international organisation whose members and full-time staff, helped by specialised members of the public, develop the web standards used in all of today's browsers.

Rachel Andrew is a British front-end and back-end developer, speaker, author, and the editor-in-chief of Smashing Magazine. As an Invited Expert to W3C, especially for CSS layout matters such as flexbox and grid, she has ample experience in the standardisation process.

©2003 - Present Akamai Design & Development.