skip to main content

Posts tagged “javascript”

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

  2. 5G Will Definitely Make the Web Slower, Maybe
    filamentgroup.com

    Scott Jehl:

    Faster networks should fix our performance problems, but so far, they have had an interesting if unintentional impact on the web. This is because historically, faster network speed has enabled developers to deliver more code to users—in particular, more JavaScript code.

    Ugh. Jeremy Keith comments:

    The longer I spend in this field, the more convinced I am that web performance is not a technical problem; it’s a people problem.

  3. What I Like About Vue
    daverupert.com

    Dave Rupert:

    Upgrading legacy applications was one of the usecases Vue was designed around. It means that developers can piecemeal upgrade bits of an application as necessary.

    In my experience Angular, React, and a lot of other frameworks ultimately require you to go all in early and establish a large toolchain around these frameworks. Angular prescribes a lot with its amazing CLI. React on the other hand doesn’t prescribe anything, but requires you to self-assemble and wield a somewhat complex toolchain. But as Evan put it in his JSConf Asia talk, Vue sits in the middle of the “Cathedral and the Bazaar”. Vue has useful tooling, but it’s all optional and you can use only what you need. In some ways, Vue’s grafting capabilities really does make it seem like a jQuery replacement you can drop in to give your components superpowers as needed.

  4. Split
    adactio.com

    Jeremy Keith:

    Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

    So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

  5. Yet Another JavaScript Framework
    css-tricks.com

    Great writing on this well-researched story, by Jason Hoffman:

    At first glance, the bug appeared to be fairly routine, most likely a small problem somewhere in the website’s code or a strange coincidence. After just a few hours though, it became clear that the stakes for this one particular bug were far graver than anyone could have anticipated. If Firefox were to release this version of their browser as-is, they risked breaking an unknown, but still predictably rather large number of websites, all at once. Why that is has everything to do with the way MooTools was built, where it drew influence from, and the moment in time it was released. So to really understand the problem, we’ll have to go all the way back to the beginning.

  6. Stuffing the Front End
    bridgestew.com

    Bridget Stewart:

    How many features are built-in to a framework or library that your app doesn’t need yet (and may never need)? How much can you hold back from the package you send to the web? How dependent are these modules and bits of code on one another? To me, that sounds like a lot of analysis up front to pick apart a tool before I even write a single line of code to be truly productive. It is also the antithesis of Progressive Enhancement, which strives to start with the bare minimum necessary to make it work and build up from there.

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

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

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