skip to main content

Posts tagged “web”, page 6

  1. 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.

  2. #​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.

  3. 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.

  4. 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).

  5. 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.

  6. 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?

  7. Notes on Prototyping
    benfrain.com

    Ben Frain gives some very useful and pragmatic advice on how to build web front-end prototypes.

    Producing something of high fidelity, perfectly matching any flat designs, runs counter to the notion of creating something quickly. The challenge for the prototyper is therefore how to cut corners that don’t impact the fidelity of the prototype.

    Jeremy Keith adds:

    In my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.

    Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.

  8. Declaration
    adactio.com

    Jeremy Keith:

    I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.

    In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the fetch or cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.