はてなブックマーク

The JavaScript APIs we have today are so much better than those we had even a decade ago. Consider the transition for XMLHttpRequest to fetch(): the developer experience is dramatically better, allowing us to write more succinct, functional code that accomplishes the same thing. The introduction of promises for asynchronous programming allowed this change, along with a series of other changes that

Open source sustainability is a topic that is just starting to get the attention that it deserves. So much of the technology sector is run on software that can be used for free without any further obligation. However, as companies profit from using this software for free, the maintainers of the software often struggle to find enough time to work on the software while making enough money to survive

If you write server-side JavaScript, chances are you’ve need to read information from environment variables. It’s considered a best practice to share sensitive information, such as access tokens, inside of environment variables to keep them secure. However, the way environment variables are read from JavaScript is error-prone in subtle ways that might take you hours to figure out. When an error oc

For a variety of reasons, I prefer to write my code in vanilla JavaScript with JSDoc comments rather than writing in TypeScript. Today’s smart code editors, like Visual Studio Code, are able to read type information from JSDoc and provide Intellisense options as you code. However, those consuming your code may not get the same benefit unless you include a TypeScript declaration file along with the

GitHub Actions1 are programs designed to run inside of workflows2, triggered by specific events inside a GitHub repository. To date, people use GitHub Actions to do things like run continuous integration (CI) tests, publish releases, respond to issues, and more. Because the workflows are executed inside a fresh virtual machine that is deleted after the workflow completes, there isn’t much risk of

Last week, I tweeted something that got quite a few surprising responses: In 2019, one of the things I’m going to do is stop exporting things as default from my CommonJS/ES6 modules. Importing a default export has grown to feel like a guessing game where I have a 50/50 chance of being wrong each time. Is it a class? Is it a function? — Nicholas C. Zakas (@slicknet) January 12, 2019 {: .twitter-twe

Job Details The data alone doesn’t really tell the full story, so here are the details around each position. I’ve also included how I came to work at each company, as I think it’s important to recognize blind resume submissions from having contacts as a company. In 2006, I moved from Massachusetts to California. This undoubtedly affected my pay positively due to the higher cost of living in Califo

Compared to ECMAScript 6 (also known as ECMAScript 2015), ECMAScript 2016 was a minor update to the language specification for JavaScript. This was due to the decision that ECMAScript editions would now move to a yearly release cycle, effectively just a snapshot of all the features that were ready. As such, most resources list only two significant changes in ECMAScript 2016: The addition of the ex

One of the most long-awaited features of ECMAScript 6 is the formal definition of modules as part of the language. For years, JavaScript developers have struggled with organizing their code and needing to decide between alternate ad-hoc module formats like RequireJS, AMD, and CommonJS. Formally defining modules as part of JavaScript will eliminate a lot of heartache in the future, but right now, t

Posted at October 20, 2015 by Nicholas C. Zakas Tags: ECMAScript 6, Destructuring With all of the new syntax in ECMAScript 6, you’re bound to periodically find something that is confusing (likely as you’re hunting down an error). Recently, I’ve seen an uptick in the reporting of a specific type of error as it relates to destructuring assignment[1] using object patterns. Destructuring basics Before

Posted at September 8, 2015 by Nicholas C. Zakas Tags: Web, Internet, API, Platform Peter-Paul Koch recently wrote a blog post entitled, “Stop pushing the web forward” [1], in which he argued for a one-year moratorium on adding new features to the web platform. By new features, he means new APIs and capabilities in HTML, CSS, and JavaScript, arguing: We’re pushing the web forward to emulate native

Posted at May 6, 2014 by Nicholas C. Zakas Tags: Browsers, Internet, URLs Last week, there was a fair bit of furor when Jake Archibald wrote an article1 describing an experimental feature in Chrome that hides all but the domain name of the URL you’re on. The idea is very similar to what already happens in the iOS 7 version of Safari: once navigation is underway, the URL is hidden and only the doma

Posted at March 4, 2014 by Nicholas C. Zakas Tags: API, Google, JavaScript, Node.js, Spreadsheets I’ve recently been working on a project involving Google Spreadsheets. My goal was to store data in the spreadsheet using a form and then read the data from that spreadsheet using a Node.js application. Having no experience with Google web services, I ended up digging through a lot of documentation on

Posted at February 25, 2014 by Nicholas C. Zakas Tags: Books, JavaScript, Writing I’m very proud to announce that Principles of Object-Oriented JavaScript is now shipping! For frequent readers, this book is the print version of my self-published ebook, The Principles of Object-Oriented Programming in JavaScript, which I published at the beginning of 2013. Birth of an ebook The whole process began

Posted at September 14, 2012 by Nicholas C. Zakas Tags: Apache, AWS, Elastic Beanstalk, Linux, nginx, Tomcat WellFurnished has been using Amazon’s Elastic Beanstalk1 service for some time now with one of the default configurations. For those who are unaware, Elastic Beanstalk is Amazon’s answer to services like Heroku and Google App Engine. You set up an application and one or more environments ma

Posted at November 4, 2013 by Nicholas C. Zakas Tags: Code Quality, ESLint, JSHint, JSLint It was four months ago when I announced the start of the ESLint project. My initial goal was to create a fully-pluggable JavaScript code quality tool where\ every single rule was a plugin. Though I like and appreciate JSHint, the inability to be able to define my own rules alongside the existing ones was kee

Posted at October 7, 2013 by Nicholas C. Zakas Tags: Architecture, JavaScript, Node.js, Web Server Front-end engineers have a rather long and complicated history in software engineering. For the longest time, that stuff you sent to the browser was “easy enough” that anyone could do it and there was no real need for specialization. Many claimed that so-called web developers were nothing more than g

Posted at July 16, 2013 by Nicholas C. Zakas Tags: ESLint, JavaScript, JSHint, JSLint, Linting A long time ago, JSLint was the state of the art in JavaScript linting technology. Then JSHint came along as a fork and took over due to increased flexibility. I welcomed JSHint as my linter of choice and used it everywhere, happily submitting patches and customizing which rules to apply based on the pro

Posted at April 30, 2013 by Nicholas C. Zakas Tags: Blink, Vendor Prefix, Web Development, WebKit When Google announced that it was forking WebKit into Blink, there was a lot of discussion around what this would mean for web developers, and if the WebKit monoculture was truly breaking or not. Amongst the consternation and hypotheticizing was a detail that went overlooked by many: Blink’s plan to s

Posted at April 16, 2013 by Nicholas C. Zakas Tags: iframe, JavaScript, referrer Dealing with iframes is always a double-edged sword. On the one hand, you get sandboxing of content within another page, ensuring that JavaScript and CSS from one page won’t affect another. If the iframe is displayed a page from a different origin then you can also be assured that the page can’t do anything nefarious

Posted at April 1, 2013 by Nicholas C. Zakas Tags: Accessibility, ARIA, HTML, Screen Readers Last week, Pamela Fox tweeted a question to me: @slicknet Do you know the best way to make a that just has an icon accessible? title, aria-label, hidden text? — Pamela Fox (@pamelafox) March 26, 2013 As tends to happen on Twitter, we fruitlessly exchanged 140 character messages trying to get some resolutio

Over the past few days, people have been going a little crazy over the announcement of the Internet Explorer 11 user-agent string. User-agent string announcements are typically met with a keen eye as we are still horribly tied to user-agent sniffing on servers around the world. And so when some beta testers leaked an Internet Explorer 11 user-agent string, people sat up and paid attention. The str

Posted at December 11, 2012 by Nicholas C. Zakas Tags: ECMAScript 5, JavaScript I was working with a client recently on a project that could make full use of ECMAScript 5 when I came across an interesting problem. The issue stemmed from the use of mixins, a very common pattern in JavaScript where one object is assigned properties (including methods) from another. Most mixin functions look somethin

Posted at November 27, 2012 by Nicholas C. Zakas Tags: Algorithms, Computer Science, JavaScript, Sorting Most discussions about sorting algorithms tend to end up discussing quicksort because of its speed. Formal computer science programs also tend to cover quicksort1 last because of its excellent average complexity of O(n log n) and relative performance improvement over other, less efficient sorti

Posted at November 6, 2012 by Nicholas C. Zakas Tags: ECMAScript 6, JavaScript, WeakMap Weakmaps are similar to regular maps in that they map a value to a unique key. That key can later be used to retrieve the value it identifies. Weakmaps are different because the key must be an object and cannot be a primitive value. This may seem like a strange constraint but it’s actually the core of what make

Like it or not, ECMAScript 6 is going to have classes1. The concept of classes in JavaScript has always been polarizing. There are some who love the classless nature of JavaScript specifically because it is different than other languages. On the other hand, there are those who hate the classless nature of JavaScript because it’s different than other languages. One of the biggest mental hurdles peo

Posted at October 4, 2012 by Nicholas C. Zakas Tags: JavaScript, TypeScript Earlier this week, Microsoft released TypeScript1, a new compile-to-JavaScript language for “application scale JavaScript.” My initial reaction was confusion: Um, why? blogs.msdn.com/b/somasegar/ar… (via @izs) — Nicholas C. Zakas (@slicknet) October 1, 2012 It seems like almost every week there’s a new language that’s tryi

Posted at January 4, 2012 by Nicholas C. Zakas Tags: CSS, JavaScript, Media Query I’ve been doing a lot of thinking about CSS media queries lately. I’m a big fan of media queries, as I think they bring a sense of sanity to feature detection. That’s a big reason why I was investigating CSS media queries in JavaScript1 and will continue to do so. I think we’re only scraping the surface of what can b