Components are a new feature in AngularJS since version 1.5 that promote a hierarchical structure of small, reusable, predictable blocks. If you're wondering whether to start moving your Angular codebase over, I have some opinions for you.
I've been working on a standard CSS framework and UI library at work for the past little while, and it's thrown up some tricky challenges. One of the more interesting ones has been that of how to design components to be responsive without knowing which context(s) they'll be used in.
Last night I gave a brief talk at MK.js about writing elegant async code with ES2015 Promises. I'm pretty happy with how I did --- it was after all my first crack at public speaking --- and the audience seemed to like the content.
Something a little different: board books to get your little one started with HTML and CSS.
Bower is a really useful tool for pulling in front-end dependencies, but if you don't have Git on the path in your environment, you're ostensibly stuck. I've found that you can work around this, though.
As my life gets more complicated, I have to accept that I don't have time for some hobbies and interests any more. First on the chopping block is the world of web standards. Let me explain why.
David Heinemeier Hansson has posited that responsive design stops being worth it when designing anything more complex than a blog, but he's not thinking about the future (and he misunderstands responsive design anyway).
I've built quite a few sites with WordPress now, but the part I always find frustrating is the start, so I've spent some time recently building a theme template that I can use to hit the ground running on new WordPress projects.
Whilst we all enjoy the pace of modern browser development, unfortunately IE8 is still around in significant numbers. However, we can do some things with our sites to get it to an acceptable level, without compromising on use of new technology.
Is Sass "rotting developers' brains" as Paul Lloyd suggests? I think it depends on what sort of developer you are, how judiciously you use the tool, and how mindful you are of its output.
A while ago, I wondered about how often and in what way users really resize their browser windows, and set about finding out. After one failed attempt with a flawed method, I now have a useful set of data.
Using the embedded widgets for social sharing (e.g. the Twitter "Tweet Button") is a bit of a performance problem, not to mention privacy issues. However, all the major services quietly provide a way to share via good old-fashioned URLs, so we can roll our own buttons.
In just the past day, the world of web rendering engines has changed quite dramatically, with the announcements of both Servo and Blink. Here's the new look across the four major platforms.
Having written about the misconception people have about users never resizing their browser window and vowed to find out the truth, I gathered some stats on a mainstream ecommerce site, but the numbers don't really add up.
I've been using a Samsung Series 5 Chromebook, the first commercially available Chrome OS laptop, and it's been an interesting experience so far. I'm hopeful for, but not terribly confident about, the platform's future.
How many users actually resize their browser window whilst viewing your site (other than curious developers)? I've decided to find out by getting some real data.
Last Friday's dConstruct in Brighton was my first ever conference, so I wasn't exactly sure what to expect, other than for it to be great, which it was.
Over time, I've noticed a few people criticising what they call "listitis" (like "divitis" or "classitis"), but I don't agree; lists are almost the most generic elements available.
Trying to get an ASP.NET TextBox control working with new HTML5 input types and attributes has not proven easy; I've ended up writing my own.
I like the new HTML5 placeholder attribute, for use on text fields to give the user a pointer about of what sort of thing they should enter. Here's a simple jQuery polyfill for older browsers.