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.
Functional programming is the mustachioed hipster of programming paradigms. Originally relegated to the annals of computer science academia, functional programming has had a recent renaissance that is due largely to its utility in distributed systems (and probably also because “pure” functional languages like Haskell are difficult to grasp, which gives them a certain cache).
Stricter functional programming languages are typically used when a system’s performance and integrity are both critical — i.e. your program needs to do exactly what you expect every time and needs to operate in an environment where its tasks can be shared across hundreds or thousands of networked computers.
From a motion design perspective, Facebook.com is phenomenally static. It's purposefully dumbed down for the broadest levels of compatibility and user comfort. Facebook’s iOS apps, on the other hand, are fluid. They prioritize the design of motion; they feel like living, breathing apps.
This article serves to demonstrate that this dichotomy does not need to exist; websites can benefit from the same level of interactive and performant motion design found on mobile apps. Before diving into examples, let's first address why motion design is so beneficial.
Z-index is an inherently tricky thing, and maintaining z-index order in a complex layout is notoriously difficult. With different stacking orders and contexts, keeping track of them as their numbers increase can be hard — and once they start to spread across CSS files, forget about it! Because z-index can make or break a UI element’s visibility and usability, keeping your website’s UI in working order can be a delicate balance.
Optimizing your website assets and testing your design across different browsers is certainly not the most fun part of the design process. Luckily, it consists of repetitive tasks that can be automated with the right tools to improve your efficiency.
To help you tap the full potential of Marionette, we've prepared an entire eBook full of useful hands-on examples which is also available in the Smashing Library. — Ed.
In this series on Backbone.Marionette, we’ve already discussed Application and Module. This time, we’ll be taking a gander at how Marionette helps make views better in Backbone. Marionette extends the base View class from Backbone to give us more built-in functionality, to eliminate most of the boilerplate code and to convert all of the common code down to configuration.
I highly recommend that you go back and read the articles about Application and Module first, if you haven’t already. Some things may be mentioned in this article that refer to the previous articles, and this is part of a series about Marionette, so if you wish to learn about Marionette, you should read the whole series.
This article covers the key concepts that underly such intimidating fragments of code, but we’ll start with a longer example, based on an example for animating a square.
I hope that by now, in 2014, there is no need to explain why SVG is a blessing to developers who want to ensure that their graphics look sharp on all devices, especially with their huge diversity of resolutions.
But just like any other technology, SVG has its limitations. And in this article, we’ll talk about how to bypass some of them. Well, what’s the problem? Why would you even need to generate SVG on the server? The technology is entirely client-side, so what would motivate anyone to move it from there?