サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
衆院選
humanwhocodes.com
You have probably heard the terms “JavaScript engine” and “JavaScript runtime” used interchangeably to mean “a program that runs JavaScript.” These are often intermixed by referencing V8, Node.js, or some other combination of related programs. However, there is a significant difference between a JavaScript engine and a JavaScript runtime in terms of scope and functionality. Understanding this diff
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 June 3, 2014 by Nicholas C. Zakas Tags: ECMAScript 6, ECMAScript 7, JavaScript With ECMAScript 6 now feature complete, any further changes to the core of JavaScript will happen in ECMAScript 7. I’m pretty excited about the changes coming in ECMAScript 6 and there are already some great ECMAScript 7 features such as Object.observe() and asynchronous functions. While the development of ECM
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 April 22, 2014 by Nicholas C. Zakas Tags: ECMAScript 6, JavaScript, Proxies This past week I spent an hour debugging an issue that I ultimately tracked down to a silly problem: the property I was referencing didn’t exist on the given object. I had typed request.code and it should have been request.query.code. After sternly lecturing myself for not noticing earlier, a pit formed in my sto
Posted at March 26, 2014 by Nicholas C. Zakas Tags: Books, ECMAScript 6, JavaScript, Writing For almost two years, I’ve been keeping notes on the side about ECMAScript 6 features. Some of those notes have made it into blog posts while others have languished on my hard drive waiting to be used for something. My intent was to compile all of these notes into a book at some point in time, and with the
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 February 4, 2014 by Nicholas C. Zakas Tags: JavaScript, Maintainable, Node.js I’ve spent the last few months digging into Node.js, and as usual, I’ve been keeping tabs on patterns and problems that I’ve come across. One problematic pattern that recently came up in a code review was the use of process.exit(). I’ve ended up finding several examples of this, and I’m prepared to go so far as
Posted at December 27, 2013 by Nicholas C. Zakas Tags: Front End Engineers, Interviews There was a really nice article written by Philip Walton last week1 regarding his experience interviewing for front-end engineering roles at various companies in San Francisco. To summarize, he was surprised by the types of questions he was asked (mostly having to do with computer science concepts) and the types
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 September 10, 2013 by Nicholas C. Zakas Tags: ECMAScript 6, Functions, JavaScript One of the most interesting new parts of ECMAScript 6 are arrow functions. Arrow functions are, as the name suggests, functions defined with a new syntax that uses an “arrow” (=>) as part of the syntax. However, arrow functions behave differently than traditional JavaScript functions in a number of importan
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 July 9, 2013 by Nicholas C. Zakas Tags: Performance, process.nextTick, setImmediate, setTimeout One of my favorite new APIs that has been beaten about is setImmediate(). While I’ll concede the naming is completely wrong, the functionality is completely awesome. The basic idea is to tell the browser that you want some JavaScript code executed after the last UI task in the event loop compl
Posted at July 2, 2013 by Nicholas C. Zakas Tags: Internet Explorer, JavaScript, navigator, User Agent String This past week, Microsoft officially unveiled the first preview of Internet Explorer 11 for Windows 8.11. Doing so put to rest a whirlwind of rumors based on leaked versions of the much-maligned web browser. We now know some very important details about Internet Explorer 11, including its
Posted at June 25, 2013 by Nicholas C. Zakas Tags: eval, JavaScript In all of JavaScript, I’m not sure there is a more maligned piece than eval(). This simple function designed to execute a string as JavaScript code has been the more source of more scrutiny and misunderstanding during the course of my career than nearly anything else. The phrase “eval() is evil” is most often attributed to Douglas
Posted at May 21, 2013 by Nicholas C. Zakas Tags: Git, GitHub Recently I asked engineers to share their experiences working with GitHub at companies. I’ve always used GitHub for open source projects, but I was interested in learning more about using it professionally and how one’s development workflow might change given all of GitHub’s capabilities. I set up a gist1 so people could leave the answe
次のページ
このページを最初にブックマークしてみませんか?
『Human Who Codes - Human Who Codes』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く