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 New York, 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.
Web applications, be they thin websites or thick single-page apps, are notorious targets for cyber-attacks. In 2016, approximately 40% of data breaches originated from attacks on web apps — the leading attack pattern. Indeed, these days, understanding cyber-security is not a luxury but rather a necessity for web developers, especially for developers who build consumer-facing applications.
HTTP response headers can be leveraged to tighten up the security of web apps, typically just by adding a few lines of code. In this article, we’ll show how web developers can use HTTP headers to build secure apps. While the code examples are for Node.js, setting HTTP response headers is supported across all major server-side-rendering platforms and is typically simple to set up.
Data visualization has become an important part of our everyday life, allowing us to quickly assess information. And with so many chart types out there to choose from, it should be possible to effectively solve almost any task, whether it's exploratory (i.e. researching and analyzing data to better understand it for yourself) or explanatory (i.e. reporting and communicating data to end users).
However, variety can also cause confusion, making it difficult to clearly understand the purpose of each form of data visualization. As a result, when an inappropriate type of chart is applied to data, the user not only might be confused by the information, but, more importantly, could make bad decisions based on such a presentation.
I started out as a web developer, and that's now one part of what I do as a full-stack developer, but never had I imagined I'd create things for the desktop. I love the web. I love how altruistic our community is, how it embraces open-source, testing and pushing the envelope.
I love discovering beautiful websites and powerful apps. When I was first tasked with creating a desktop app, I was apprehensive and intimidated. It seemed like it would be difficult, or at least… different.
Over the last five years, Node.js has helped to bring uniformity to software development. You can do anything in Node.js, whether it be front-end development, server-side scripting, cross-platform desktop applications, cross-platform mobile applications, Internet of Things, you name it. Writing command line tools has also become easier than ever before because of Node.js — not just any command line tools, but tools that are interactive, useful and less time-consuming to develop.
If you are a front-end developer, then you must have heard of or worked on Gulp, Angular CLI, Cordova, Yeoman and others. Have you ever wondered how they work?
In a world driven by the Internet, mobile apps need to share and receive information from their products' back end (for example, from databases) as well as from third-party sources such as Facebook and Twitter.
These interactions are often made through RESTful APIs. When the number of requests increases, the way these requests are made becomes very critical to development, because the manner in which you fetch data can really affect the user experience of an app.
Douglas Crockford famously declared browsers to be "the most hostile software engineering environment imaginable," and that wasn't hyperbole. Ensuring that our websites work across a myriad of different devices, screen sizes and browsers our users depend on to access the web is a tall order, but it's necessary.
If our websites don't enable users to accomplish the key tasks they come to do, we've failed them. We should do everything in our power to ensure our websites function under even the harshest of scenarios, but at the same, we can't expect our users to have the exact same experience in every browser, on every device.
I’ve been thinking a lot about speech for the last few years. In fact, it’s been a major focus in several of my talks of late, including my well-received Smashing Conference talk “Designing the Conversation.” As such, I’ve been keenly interested in the development of the Web Speech API.