skip to main content

Posts tagged “web”, page 6

  1. Evaluating Technology
    aneventapart.com

    Jeremy Keith:

    Now when we look at new things added to HMTL, new features, new browser APIs, what we tend to ask, of course, is: how well does it work?

    How well does this thing do what it claims it’s going to do? That’s an excellent question to ask whenever you’re evaluating a new technology or tool. But I don’t think it’s the most important question. I think it’s just as important to ask: how well does it fail?

    Nothing like a full hour of Jeremy Keith to get the year’s work started.

  2. We Should Replace Facebook With Personal Websites
    motherboard.vice.com

    Jason Koebler:

    There’s a subtext of the #deleteFacebook movement that has nothing to do with the company’s mishandling of personal data. It’s the idea that people who use Facebook are stupid, or shouldn’t have ever shared so much of their lives. But for people who came of age in the early 2000s, sharing our lives online is second nature, and largely came without consequences. There was no indication that something we’d been conditioned to do would be quickly weaponized against us.

  3. Browsers
    adactio.com

    Jeremy Keith:

    Very soon, the vast majority of browsers will have an engine that’s either Blink or its cousin, WebKit. That may seem like good news for developers when it comes to testing, but trust me, it’s a sucky situation of innovation and agreement. Instead of a diverse browser ecosystem, we’re going to end up with incest and inbreeding.

  4. #​Edge​Goes​Chromium
    daverupert.com

    Dave Rupert:

    But in the past we had browser disparity as a mechanism for delaying bad ideas from becoming ubiquitous so they could be hashed out in a Web Standards body. Some of the best ideas we have today, like CSS Grid, were pioneered in one browser (IE10) and then polished in a Working Group. If V1 of -ms-grid was now the de facto standard, we’d have some regrets.

  5. Big ol’ Ball o’ JavaScript
    bradfrost.com

    Brad Frost:

    I’m confident developers will get their heads around it. They’ll figure out their swim lanes and understand which JavaScript does what. I’m more concerned about other team members who are now staring at a Big Ol’ Intimidating Ball O’ JavaScript. And I’m concerned for those recruiters and hiring managers who are even further removed from the day to day. Those job listings with a giant spray of buzzwords and technologies can now be winnowed down to a single word: JavaScript. Those recruiters have a hard enough time separating Java from JavaScript, so best of luck to them making sense of the complex JavaScript ecosystem.

  6. Reluctant Gatekeeping: The Problem With Full Stack
    heydonworks.com

    Heydon Pickering:

    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. This has two adverse effects:

    1. Poor quality code
    2. A bunch of people who can (and would enjoy!) expertly writing that code, standing unemployed on the sidelines muttering “WTF”

    I so very much agree with everything Heydon says here. And that agreement comes from the experience of trying to become a full stack dev myself (though going at it from an HTML/CSS-first perspective).

  7. It’s not about the device.
    ethanmarcotte.com

    Ethan Marcotte:

    Let me start by saying I generally avoid terms like “mobile,” “tablet,” and “desktop” in my work. It’s not that they’re bad; it’s because they’re broad. In my experience, terms like these confuse more than they clarify. Ask a roomful of clients or stakeholders to define “mobile,” and you’ll get a roomful of slightly different responses.

    What I think is helpful, though, is breaking down the specific conditions or features that’ll cause our designs to adapt.

  8. Warp and Weft
    paulrobertlloyd.com

    Paul Robert Lloyd:

    Such notions of craftsmanship can soon lead us down a dangerous path, raising questions around elitism and discrimination. These are accusations you could level towards the IndieWeb. For all its promise of giving people the tools to regain ownership of their online identity and content, to do so fully and effectively requires a proficiency for coding and familiarity with an endless barrage of acronyms. Encouraging participants to selfdogfood only exacerbates the near-impenetrability and narrowness of this movement.

    Rob Weychert chimes in and gets a strong +1 from me:

    If even web people find it difficult, how can we ever manage to empower non-web people to produce web-like content?