Posts tagged “javascript”

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.

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.

Test packages directly in the browser, without installing anything locally. Perfect for quickly evaluating packages before bringing them into your important projects.

Taking npm packages for a test drive: incredibly useful.

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.

A repository of styled and “styled” form control elements and markup patterns, and how they are announced by screen readers.

Adrian Roselli:

What we know is that native and custom calendar controls are often a problem for users and applied where they are not needed. Before dropping the code on a screen as a matter of habit, consider if it genuinely helps the user or just your workflow.

Nick Heer:

When you think about it, it’s pretty nuts that we allow the automatic execution of whatever code a web developer wrote. We don’t do that for anything else, really — certainly not to the same extent of possibly hundreds of webpages visited daily, each carrying a dozen or more scripts.

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.

An interesting comparison from Danny Moerkerke:

Remember when document.querySelector first got wide browser support and started to end jQuery’s ubiquity? It finally gave us a way to do natively what jQuery had been providing for years: easy selection of DOM elements. I believe the same is about to happen to frontend frameworks like Angular and React.

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.

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.

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.

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

Dave Rupert:

Let’s say we have a site with ~300 third-party scripts all responsibly loaded as async, what would be the User Experience costs and risks?