You know, we use ad-blockers as well. We gotta keep those servers running though.
Did you know that we publish useful books and run
friendly conferences — crafted for pros like
yourself? E.g. our upcoming SmashingConf Barcelona,
dedicated to smart front-end techniques and design patterns.
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.
I’ve never been a fan of color theory. I think it’s because I’ve always been a bit hopeless at it. I’d love to be able to sit there, color wheel in hand, and pick out complementary, split-complementary and triad color schemes, impressing all of my friends, family and clients in the process.
But the theory has always eluded me, and, truthfully, I’ve never found it useful when trying to use color in my projects. Somewhat ironically, I’ve been finding that the better I get at choosing and using color, the better I become in the theory behind it.
When I was young and learning to program, I was fascinated by the possibility of creating things that could live inside my monitor. I had the same feeling when I started to play with procedural content generation, which is to find the rules behind a phenomenon, encode them in an algorithm, and use that algorithm to create something virtual, but realistic — a plausible simulation.
Typically, you can give a seed or some initial parameters to a procedural content generation algorithm, and get some result. You could generate the landscape of a city, the shape of a tree or an entire world.
Have you ever wanted to use a particular CSS feature but didn’t because it wasn’t fully supported in all browsers? Or, worse, it was supported in all browsers, but the support was buggy, inconsistent or even completely incompatible? If this has happened to you — and I’m betting it has — then you should care about Houdini.
Houdini is a new W3C task force whose ultimate goal is to make this problem go away forever. It plans to do that by introducing a new set of APIs that will, for the first time, give developers the power to extend CSS itself, and the tools to hook into the styling and layout process of a browser’s rendering engine.
You know how it works: you spend hours trying to find a workaround for a problem that you have encountered, just to realize that it doesn't quite work in, you know, that browser. Finding little techniques and tricks to help you get to results faster can immensely improve your productivity, so you don't have to waste time on solutions that will never see the light of day.
I love finding those little useful front-end goodies that make our lives easier. Since technologies emerge and evolve permanently, keeping track on what's going on is often difficult, especially since specifications change and so does the browser support. For a replacement talk at SmashingConfOxford last week, I've decided to collect some of the useful techniques from various articles, conversations and my workshops in a slide deck — and since it proved to be useful for many front-end developers I've spoken to after the talk, I'm very privileged to share it with the entire community as well.
Location-based services are growing in popularity every day, and beacon-based services are tipped to be the advertising goldmine of 2016. You may already be using location data and beacons to enhance your users’ experience with your websites, apps and wearables. However, the use of location data is not without limits.
Developers must become aware of international privacy laws, as well as industry codes of self-regulation, that govern its usage. Following laws and codes, while also adhering to best practice principles through frameworks such as privacy by design (PbD), will ensure public trust in your app as well as in your services as a developer.
If you’ve ever worked in an agile environment, chances are you’ve had your share of “retrospectives” — meetings where people write what made them “glad,” “mad” or “sad” onto different-colored notes, post them onto a board, arrange them in groups and — most importantly — talk about them.
These meetings are straightforward, as long as everyone is in the same room. But if you’re working with a locally distributed team, things can get a bit tricky. Let’s address this by creating a virtual version of our board to allow team members in different locations to hold their retrospective just as if they were in the same room.
Web applications are everywhere. There is no official definition, but we’ve made the distinction: web applications are highly interactive, dynamic and performant, while websites are informational and less transient. This very rough categorization provides us with a starting point, from which to apply development and design patterns.
These patterns are often established through a different look at the mainstream techniques, a paradigm shift, convergence with an external concept, or just a better implementation. Universal web applications are one such pattern.
Preload (spec) is a new web standard aimed at improving performance and providing more granular loading control to web developers. It gives developers the ability to define custom loading logic without suffering the performance penalty that script-based resource loaders incur.
A few weeks ago, I shipped preload support in Chrome Canary, and barring unexpected bugs it will hit Chrome stable in mid-April. But what is that preload thing? What does it do? And how can it help you?
Augmented reality is generally considered to be very hard to create. However, it's possible to make visually impressive projects using just open source libraries. In this tutorial we'll make use of OpenCV in Python to detect circle-shaped objects in a webcam stream and replace them with 3D Earth in Three.js in a browser window while using WebSockets to join this all together.
We want to strictly separate front-end and back-end in order to make it reusable. In a real-world application we could write the front-end in Unity, Unreal Engine or Blender, for example, to make it look really nice. The browser front-end is the easiest to implement and should work on nearly every possible configuration.
Flexbox gives us a new kind of control over our layouts, making coding challenges that were hard or impossible to solve with CSS alone straightforward and intuitive. It provides us with the means to build grids that are flexible and aware of dynamic content, and thus, give us the freedom to focus on the creation process instead of hacking our way towards a layout.
To give you a head start into Flexbox and provide you with ideas on how to use it to master common coding challenges, we have collected tips, tricks, and tools that help you get the most out of its power already today. The list is by no means complete but includes the resources which we found helpful and useful.
It’s not exactly a new subject, but lately I’ve had reason to revisit the skill of content modeling in my team’s work. Our experience has reached a point where the limitations of how we practice are starting to become clear. Our most common issue is that people tend to tie themselves and their mental models to a chosen platform and its conventions.
Instead of teaching people how to model content, we end up teaching them how to model content in Drupal, or how to model content in WordPress. But I’d prefer that we approach it from a focus on the best interests of users, regardless of which platform said content will end up in.
Cross-browser testing is time-consuming and laborious. This, in turn, makes it expensive and prone to human error… so, naturally, we want to do as little of it as possible. This is not a statement we should be ashamed of. Developers are lazy by nature: adhering to the DRY principle, writing scripts to automate things we’d otherwise have to do by hand, making use of third-party libraries — being lazy is what makes us good developers.
The traditional approach to cross-browser testing doesn’t align well with these ideals. Either you make a half-hearted attempt at manual testing or you expend a lot of effort on doing it “properly”: testing in all of the major browsers used by your audience, gradually moving to older or more obscure browsers in order to say you’ve tested them.