JavaScript, Page 2

Hand-code an SVG snowflake, experiment in an interactive playground, and generate infinite random snowflakes with a dash of JavaScript.

Components are everywhere, but they are rarely reusable across systems. A design system component is written differently than a CMS editor component. But does it have to be this way? Could we take one set of components and port them to multiple JavaScript frameworks, import them into design tools, and use them for the editing interfaces in content management systems?

On a recent client project, we built a form that submitted to a third-party registration service. Easy-peasy, right? What followed was a comical series of incidents that served as an excellent lesson in defensive API handling.

Using JavaScript, SVGs, and CSS to procedurally generate unique solar systems.

By leveraging native browser controls, we can make accessible and high-performing components with just a dash of JavaScript.

You may have heard that you should be “linting” your code. What does that mean? Why would you want to do it?

Join me in exploring a recent experience where I started with flawed logic (without realizing it) and the steps I took to fix my bug. Let’s experience some broken code together. 🎉

Development toolchains now have many more layers of tools than they did years ago. Because of this change, the JS code that runs in our users' browsers looks less like the original code we authored. Periodically checking the code generated by our tools can lead to opportunities to reduce bundle size and improve performance for users.

If you’ve ever tried to use a CSS transition on an element with the hidden attribute or display: none;, you know this can be a challenge. I’ve run into this problem a number of times…