skip to main content

Posts tagged “software”

  1. Catalina Vista
    mjtsai.com

    The macOS Catalina situation seems to be pretty bad. My biggest reasons for upgrading are Apple Arcade and Reminders, but in return I’d have to:

    • give up Photoshop CS6
    • give up a bunch of games on my Steam library
    • deal with my old Aperture libraries as the app is finally broken
    • learn a new shell, or replace it
    • fix all the tooling stuff that will break due to the new read-only system volume
    • put up with all the permission annoyances
    • deal with all the damn bugs

    Marco Arment’s take on ATP is right: “not enough carrot to take the stick”. For the first time ever I might actually skip a major version of macOS.

  2. The imitation game
    adactio.com

    Jeremy Keith:

    Jason shared some thoughts on designing progressive web apps. One of the things he’s pondering is how much you should try make your web-based offering look and feel like a native app.

    This was prompted by an article by Owen Campbell-Moore over on Ev’s blog called Designing Great UIs for Progressive Web Apps. He begins with this advice:

    Start by forgetting everything you know about conventional web design, and instead imagine you’re actually designing a native app.

    This makes me squirm. I mean, I’m all for borrowing good ideas from other media—native apps, TV, print—but I don’t think that inspiration should mean imitation. For me, that always results in an interface that sits in a kind of uncanny valley of being almost—but not quite—like the thing it’s imitating.

    People have been gleefully passing around the statistic that the average number of native apps installed per month is zero. So how exactly will we measure the success of progressive web apps against native apps …when the average number of progressive web apps installed per month is zero?

  3. Simplicity (II)
    bastianallgeier.com

    Bastian Allgeier:

    I have a simple rule of thumb when it comes to programming:

    less code === less potential issues

    This rule of thumb controls my own feelings towards a solution. It shouldn’t take 120 MB of code to uglify some JS. But maybe I’m wrong.

    In practice, this dependency hell has bitten me so often already that my life expectancy probably sank by 2-3 years. You want to build a JS file? Please update Webpack first. Oh, that new version of Webpack is no longer compatible with your Node version. Oh, your new Node version is no longer compatible with that other dependency. Oh, now you have 233 detected security issues in all your node_modules but you can’t fix them because that would break something completely unrelated.

  4. Fast Software, the Best Software
    craigmod.com

    Craig Mod:

    Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.

  5. How to Kill IE11 - What the Deaths of IE6 and IE8 Tell Us About Killing IE
    mike.sherov.com

    Mike Sherov:

    In order to understand how best to kill IE11, we need to look back to how 2 previous versions of IE met their fate: IE6 and IE8. By examining the strategies employed to kill browsers, we can look at current efforts to sunset IE11. We can predict and evangelize for what may ultimately do it in, finally freeing the JS community from the burden of ES5.

    Interesting historical analysis but I think that attempting to “kill” browsers is a misguided goal. I think the right way to move forward here is Oliver Williams’ idea of applying the “mustard cut” technique to all versions of Internet Explorer and serving those users just barebones (but useful) HTML and CSS.

  6. We Are Tenants on Our Own Devices
    wired.com

    Zeynep Tufekci is worried about what ownership means for always-connected products:

    Today, we may think we own things because we paid for them and brought them home, but as long as they run software or have digital connectivity, the sellers continue to have control over the product. We are renters of our own objects, there by the grace of the true owner.

    I worry about this a lot, maybe too much. Unless I don’t have a choice, I avoid any device that superflously requires an internet connection (or worse, a smartphone app) like the plague.

  7. Freedom
    inessential.com

    Brent Simmons:

    In a way, it feels like iOS devices are rented, not owned. This is not a criticism: I’m totally fine with that. It’s appropriate for something so very mass-market and so very much built for a networked world.

    But what about Macs?

    Macs carry the flame for the revolution. They’re the computers we own, right? They’re the astounding, powerful machines that we get to master.

    Except that lately, it feels more and more like we’re just renting Macs too, and they’re really Apple’s machines, not ours.

  8. I was just reminiscing about this a few days ago. Nine years later, @lorenb’s Twitter for iPad is still unmatched. Devices are now several times more powerful, yet the experience of using Twitter on the original iPad is the best we ever got.

  9. CERN 2019 WorldWideWeb Rebuild
    worldwideweb.cern.ch

    Digital archeology — a working simulation of the first ever web browser:

    In December 1990, an application called WorldWideWeb was developed on a NeXT machine at The European Organization for Nuclear Research (known as CERN) just outside of Geneva. This program – WorldWideWeb — is the antecedent of most of what we consider or know of as “the web” today.

    In February 2019, in celebration of the thirtieth anniversary of the development of WorldWideWeb, a group of developers and designers convened at CERN to rebuild the original browser within a contemporary browser, allowing users around the world to experience the origins of this transformative technology.

    It’s amazing just how resilient and backwards-compatible HTML is. My site is already quite usable in WorldWideWeb, but now I’ll have to resist the urge to add some optimizations for 1990 web users.

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

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