This extended category features articles on client-side and server-side programming languages, tools, frameworks and libraries, as well as back-end issues. Experts and professionals reveal their coding tips, tricks and ideas. Curated by Dudley Storey and Rey Bango. Subscribe to the RSS-Feed.
When they hit the front-end landscape a few years ago, preprocessors were heralded as the saviour of CSS, bringing modularity, meaning and even a degree of sexiness. Terms like “Sass architecture” became commonplace, ushering in a new generation of CSS developers who occasionally went to excess with their new-found power. The results were marvellous, and sometimes undesirable.
One of the unpleasant side effects was a preprocessor elitism that continues to persist. Neophyte designers who were just getting their hands dirty with CSS were overwhelmed by an influx of must-have tools and confused by the bitter partisan wars in web development forums.
When you start a fresh web project or start digging into an existing code base, chances are you’re trying to create or enhance a feature for your users. The last thing you want to do is spend time customizing build tools and creating infrastructure to develop your application. If you land a new client, you want to show them features today, not in a week after you’ve cobbled together a build pipeline.
If you do any kind of development for the web, then you know how important tools are, and you like finding tools that make your life easier. Developing and testing new browser features, however, takes time. Between the time a useful tool first appears in an experimental nightly build and the time it’s available for everyone to use in Firefox, a while has passed.
That’s one of the reasons Mozilla released Firefox Developer Edition in November 2014 as the recommended Firefox browser for developers. It gets new feature updates more quickly so that you can use the latest tools.
React is one of today’s most popular ways to create a component-based UI. It helps to organize an application into small, human-digestible chunks. With its “re-render the whole world” approach, you can avoid any complex internal interactions between small components, while your application continues to be blazingly fast due to the DOM-diffing that React does under the hood (i.e. updating only the parts of the DOM that need to be updated).
But can we apply the same techniques to web graphics — SVG in particular? Yes! I don’t know about you, but for me SVG code becomes messy pretty fast. Trying to grasp what’s wrong with a graph or visualization just by looking at SVG generator templates (or the SVG source itself) is often overwhelming, and attempts to maintain internal structure or separation of concerns are often complex and tedious.
What is the difference between a web page and a web application? Though we tend to identify documents with reading and applications with interaction, most web-based applications are of the blended variety: Users can consume information and perform tasks in the same place. Regardless, the way we approach building web applications usually dispenses with some of the simple virtues of the readable web.
Scalable Vector Graphics (or SVG) lend developers an incredible ability to display crisp, beautiful graphics at any size or resolution. SVG can also be animated using various techniques. In combination with clipping paths, interesting effects can be achieved.
This article explains the difference between an SVGclipPathand a CSSclip-path, including examples to guide and inform you through this journey. Finally, I’ll share a few demos both personal and in the wild to help you better understand clipPath animation and inspire your visions.
Flexbox has become one of the most popular tools for creating website layouts. Susy is another layout tool that has gained popularity with the Sass community over the last few years.
Many developers I’ve spoken with are unsure which tool is best for creating layouts for their websites. Some feel that flexbox is powerful enough to handle all of their layout problems. However, they are unsure whether to learn it because of its confusing syntax. Others feel that Susy is much simpler and prefer its simplicity to flexbox.
I’ve been a web developer for 15 years, but I’d never looked into accessibility. I didn’t know enough people with (serious) disabilities to properly understand the need for accessible applications and no customer has ever required me to know what ARIA is. But I got involved with accessibility anyway – and that’s the story I’d like to share with you today.
At the Fronteers Conference in October 2014 I saw Heydon Pickering give a talk called “Getting nowhere with CSS best practices”. Among other things, he made a case for using WAI-ARIA attributes like aria-disabled="true" instead of classes like .is-disabled to express application state. It struck me then and there that I was missing out on a few well-prepared standards, simply because ARIA belongs to that accessibility space that I had no idea of.
Having spent over two years making it, we just pressed the “Ship” button on the new Hawaiian Airlines website. It has been the biggest project of my career, and I’ve worked with the most talented team I’ve ever worked with.
Everything was rebuilt from the ground up: hardware, features, back-end APIs, front end, and UX and design. It was a rollercoaster ride like no other, but we have prevailed and built what I believe to be one of the best airline-booking experiences on the web. Yes, humble, I know!