An internet radio show about the internet starring Dave Rupert and Chris Coyier.

Subscribe on iTunes or RSS


237 Rapidfire 73

01:09:40 Download

Show Description

A little follow up this week! We revisit some stuff we've talked about before, like Webpack, TypeScript, and the double-tap bug on iOS.

Chris is trying to get rid of cables on his desk and Dave's shopping for more computer stuff, as always. Then we get into more of your Rapidfire questions and our answers: resources for implementing accessibility in JavaScript apps, finding APIs to practice with, using Adobe XD, `` vs `` tags, and who's responsible for making things secure on the front end?

Show Sponsors

Interested in sponsoring?

Time Jumps

  • 1:45 Errs and omissions
  • 10:30 Chris updates us on his desktop arrangement and Dave goes Window (get it? get it?) shopping.
  • 20:00 iOS hover issue update.
  • 26:45 Have you got any recommendations on resources (books, sites, people to look out for) for implementing accessibility standards in a Javascript app?
  • 32:40 I'm teaching myself React and I'm trying to get more practice working with APIs. My problem is I can't find very many high-quality public APIs out there. What can I do to get on with my life and just build websites?
  • 37:40 Anyone used Adobe Xd for mock ups yet?
  • 46:15 Utilizing best practices for HTML 5, what is the best way to format text to make it Bold or Italicized?
  • 51:20 What aspects of security are a front end responsibility? I have heard of setting a Content Security Policy to protect against XSS attacks and that iframes and other HTML5 elements could be a liability, but getting a handle on this and understanding what is expected of me as a front end dev is difficult and I would love to hear your thoughts.
  • 1:03:15 A statement in response to webpack and npm scripts.


  • David Hicken

    Posting my feedback as a comment per request – David Hicken

    This isn’t really a question, just clarification on strongly/statically typed languages vs dynamically typed languages and Typescript in response to episode 245.

    By way of my background: I’ve been professionally doing web development since the late 90’s, and for the first 10 of those years my back-end language was Perl (which is dynamically typed). I have been developing with JavaScript since before the first browser wars. I’ve also worked on Visual Basic (years and years ago) and C# (rather recently) projects. So I have worked with both dynamically typed and strongly typed languages.

    Strongly typed languages enforce that a function will get the variable types that it expects, and that variable comparisons will only be between like values. This is enforced at compile time, and brought to the developers attention at development time if they are using an IDE. Additionally, having multiple types of numbers (float, int, real, etc) add to processing and memory efficiency. For example, you don’t need as much memory for an int as you do for a long, so by having those statically typed, the program can allocate less memory for the int, and doesn’t need to re-allocating memory to accommodate a bigger value because it will not allow an int to grow to the size of a long. As for CPU cycles with statically typed languages, because data types were validated at compile time, no processing is required to validate that the values are of like types when the variables are compared, or joined/added, etc during run-time. Now that is oversimplifying it a bit, but that is the idea.

    Now that I’ve made the case for strongly typed languages, you should know that generally speaking I don’t like strongly typed languages. While they are supposed to improve development efficiency due to the IDE being able to preemptively discover bugs, I feel like it slows and restricts the developer more than it helps.

    I don’t like feeling like my hands are tied with how I want to write my code, and have to spend time explicitly casting one variable as another type. With strongly typed languages, I feel like I spend more time trying to deal the constraints than writing software and solving problems. In my mind, a number is a number. I believe casting from an int to a long is something the compiler/run-time should do (not the developer). I like being able to accept different parameters to the same function and return an appropriate result based on context (instead of having to overload and have multiple copies of the function). I appreciate being able coerce a variable into being either a string or an array of strings based on context. I appreciate the flexibility of being able to have an array with mixed types (strings, numbers, booleans or even references to a sub array, an object, or a function, within the same array). I could go on and on. Not that everything I just described is good practice, but the important thing is, you CAN if you want to. Computers/Mobile Devices/Servers are powerful enough these days that, unless you are writing something that requires the up-most performance (such as 3D rendered games), you can easily justify a minor amount of code efficiency trade-off for developer efficiency gain.

    Now as for Typescript, I have not used Typescript in a project yet, but I did just get back from a conference where Bowden Kelly gave a really good presentation on it (posted on youtube: Typescript is Javascript, but adds some features. The first of course is strong typing capability. But what makes this beautiful is, it is discretionary. You can add it where you want it, and leave it out where you don’t. Something else I love is, this only affects your development. Once you compile it, all of the Typescript code is removed. Another feature is, with an editor that has a plug-in for it, you get intellisense, just like you get while using an IDE with a strongly typed language. Another big thing I know Typescript does is transpile ES6. I don’t believe that was part of the original design, but it is a part of the latest version. Of course there is more, but those are what stood out to me.

    One disadvantage to Typescript is you must run it through a pre-processor. So if you are not already running your code though a pre-processor, that could be a deterrent. But if you do start using it, and ever decide to stop using it, you simply take the output of the pre-processor and and stop using the .ts file.

    I hope you guys get some valuable out of this.

  • Tetrygon

    The thing about security is that it has to be in the back of everyone’s brain. It is just like safety in a factory. Of course there is a good amount of work that needs to be on the back end like you guys said, but there are a couple of things that front end developers can do to help. One of the biggest is validation. Are you expecting a number in on of the fields? If so, what happens if you put a “cat” or “dog” in there? What happens when you pass it an html tag like testing heading. What is the intentional data?

    It may help to think about it as forcing your users to conform to the format you want you data to be in. For example, have a date picker instead of a date text field. On mobile, it is the same way. I, personally, get irritated when I click on a field that ONLY accepts a number, and the app gives me the full keyboard.

    Also, keep in mind how the internet works. If you’re building a “classic” web site, the application needs to send a request to the server in order for the back end to validate the information that is being passed. Any work that can be done to verify the data on the front end will save server requests and the number of page loads to the end user.

  • deconai

    Re: TypeScript and static typing pros and cons, I just read an article by Eric Elliott where he talks at length about TypeScripts’s strengths and weaknesses. Very insightful.

    In the article, he highlights a bug density report that compared dynamic and static-typed languages. The results are all over the place, which supports the idea that typing has no discernible impact on bug density. In short, you don’t automatically stop having bugs because you’re writing in Java or C++.

    Another report referenced in the article shows a slight advantage toward static-typed languages, but it’s very slight.

    My own personal experience with static types is that it makes the code much less readable. If code’s purpose is to communicate programming concepts to humans, this is not a good thing. It takes much more time to find variable names among all of the declarations and can possibly lead to less productivity. To be fair, this is in _certain_ static typed languages that type inline with the variable or function declaration. I favor separating typing from the file itself (maybe via a config file).

    So, if reducing programming error is your only reason to use TypeScript, you may want to look at other, proven ways of reducing bug density, like TDD or BDD.


  • Great mention of Todd Motto’s public APIs on GitHub – I took a look and found this: Truly an “as a service” with a difference !

  • Thanks for this episode. I’m working on a rails app and just came across the ios hover issue. I remembered you guys talking about it on this episode and was able to solve it in a couple of minutes. Thanks for saving me hours of my time.

Job Mentions

Check out all jobs over on the Job Board. If you'd like to post a job, you can do that here, and have it mentioned on ShopTalk for a small additional charge.