Tech Guides - Front-End Web Development

I was on the WebKit.org site the other day, and it struck me that it was a fairly ugly site for the home page of such a well-known browser engine. Lime green to white background transition, drop-shadow headers. It doesn’t even respond; what? I don’t want to take anything away from its functionality – it works perfectly well – but it did bring to mind the argument about frontend frameworks and the beautification of the Internet. When the Internet started to become a staple of our daily compute, it was an ugly place. Let’s not delude ourselves in thinking every site looked awesome. The BBC, my home page since I was about 14, looked like crap until about 2008. As professional design started improving, it left “home-brew” sites still looking old, hacky, and unloved. Developers and bedroom hacks, not au fait with the whims of JavaScript or jQuery, were left with an Internet that still looks prehistoric. A gulf formed between the designers who were getting paid to make content look better and those who wanted to, but didn’t have the time. It was the haves, and the have nots. Whilst the beautification of websites built by the “common man” is a consequence of the development of dozens of tools in the open source arena, I’m ascribing the flashpoint as Twitter Bootstrap. Yes, you can sniff a Bootstrap site a mile off, and yes it loads a bit slower except for the people who use Bootstrap (me), and yes some of the mark-up syntax is woeful. It does remain, however, a genuine enabler of web design that doesn’t suck. The clamor of voices that have called out Bootstrap for the reasons mentioned above, I think, have really misunderstood who should be using this tool. I would be angry if I paid a developer to knock me up a hasty site in Bootstrap. Designers should only be using Bootstrap to knock up a proof of concept (Rapid Application Development), before building a bespoke site and living fat off the commission. If, however, someone asked me to make a site in my spare time, I’m only ever going to be using Bootstrap (or, in fairness, Foundation), because it’s quick, easy, and I’m just not that good with HTML, CSS, or JavaScript (though I’m learning!). Bootstrap, and tools like it, abstract away a lot of the pain that goes into web development (really, who cares if your button is the same as someone else’s?) for people who just want to add their voice to the sphere and be heard. Having a million sites that look similar but nice, to me is a better scenario than having a million sites that are different and look like the love child of a chalkboard and MS Paint. What’s clear is that it has home-brew developers contributing to the conversation of presentation of content; layout, typography, iconography. Anyone who wants to moan can spend some time on the wayback machine.

If you are new to JavaScript, you may find it a little confusing depending on what computer language you were using before. Although JavaScript is my favorite language to use today, I cannot say that it was always this way. There were some things I truly disliked and was genuinely confused with in JavaScript. At this point I have come to accept these things. Today we will discuss the five hurdles you may come across in the JavaScript programing language. Global variables No matter what programming language you are using, it is never a good idea to have variables, functions, or objects as part of your global scope. It is good practice to limit the amount of global variables as much as possible. As programs get larger, there is a greater chance of naming collisions and giving access to code that does not necessarily need it by making it global. When implementing things, you want a variable to have a large enough scope as you need it to be. In JavaScript, you can access some global variables and objects through window. You can add things to this if you would like, but you should not do this. Use of Bitwise Operators As you probably know, JavaScript is a high level language that does not communicate with the hardware much. There are these things called Bitwise Operators that allow you to compare the bits of two variables. For instance x & y does an AND operation on x and y. The problem with this is, in JavaScript there is no such thing as integers, only double precision floating point numbers. So in order to do the bitwise operation, it must convert x and y to integers, compare the bits, and then convert them back to floating point numbers. This is much slower to perform and really should not be done, but then again it is somehow allowed. Coding style variations From seeing many different open source repositories, there does not seem to be one coding style standard that everyone adheres too. Some people love semicolons, others hate them. Some people adore ES6, other people despise it. Personally, I am fan of using standard for coding style, and I use ES5. That is soley my opinion though. When comparing code with other people who have completely different styles, it can be difficult to use their code or write something similar. It would be nice to have a more generally accepted style that is used by all JavaScript developers. It would make us overall more productive. Objects Coming from a class-based language, I found the topic of prototypical inheritance difficult to understand and use. In prototypical inheritance all objects inherit from Object.prototype. That means that if you try to refer to a property of an object that you have not defined for yourself, but it exists as part of Object.prototype, then it will execute using that property or function. There is a chain of objects where each object inherits all of the properties from its parent and all of that parents' parents. Meaning, your object might have access to plenty of functions it does not need. Luckily, you can override any of the parent functions by establishing a function for this object. A large amount of falsy values Here is a table of falsy values that are used in JavaScript: False Value Type 0 Numbers NaN Numbers '' String false Boolean null Object undefined undefined All of these values represent a different falsy value, but they are not interchangeable. They only work for their type in JavaScript. As a beginner, trying to figure out how to check for errors at certain points in your code can be tricky. Not to harp on the problem with global variables again, but undefined and NaN are both variables that are part of global scope. This means that you can actually edit the values of them. This should perhaps be illegal, because this one change can affect your entire product or system. Conclusion As mentioned in the beginning, this post is simply an opinion. I am coming from a background in C/C++ and then to JavaScript. These were the top 5 problems I had with JavaScript that made me really scratch my head. You might have a completely different opinion reading this from your different technical background. I hope you share your opinion! If you enjoyed this post, tweet and tell me your least favorite part of using JavaScript, or if you have no such problems, then please share your favorite JavaScript feature! About the author Antonio Cucciniello is a Software Engineer with a background in C, C++ and JavaScript (Node.Js) from New Jersey.   His most recent project called Edit Docs is an Amazon Echo skill that allows users to edit Google Drive files using your voice. He loves building cool things with software, reading books on self-help and improvement, finance, and entrepreneurship. Follow him on twitter @antocucciniello, and follow him on GitHub here: https://github.com/acucciniello

Google apparently wants all the web developers to adopt the AMP approach for their websites. The AMP project was announced by Google on October 7, 2015, and AMP pages first became available to web users in February 2016. Mobile search is more popular presently as compared to desktop search. It is important for web pages to appear in Google’s mobile search results, and this is why AMP is not optional for web publishers. Without AMP, a publisher’s articles will be extremely unlikely to appear in the Top Stories carousel on mobile search in Google. This means the developers will have two options for them, either to design the complete app in the AMP format, or have two formats ready, one as per their own design considerations, the other as per the Google AMP format. Does that really work for the developers? We will try to address that question here in this article. The trouble with Web content - Searchability and Indexing The searchability of your application is heavily dependent on the structure & format of your app. To be found on Google search is dependant on how easily Google can crawl and index your application. The main challenge for indexing is the vast nature of internet and the wide variety of applications that exist. The absence of a structure or a particular format makes the task of checking website content and categorizing them very difficult. This was the primary reason why Google had come up with the idea of Accelerated Mobile Pages. The purpose of adopting AMP is to make all web and mobile applications conform to a certain structure, so that they can be easily classified and categorized. Since the implementation of ‘mobile first’ approach - an approach that puts more emphasis on the mobile platform and UI considerations for mobile devices, the AMP way has been slowly becoming the most preferred way of app designing. But the real question here is are developers adopting this particular design thinking willingly or are they finding themselves running out of other options with Google forcing its hand on how they design their apps. The Ground Realities of the Web - Diversity vs Uniformity The truth is that the internet is a diverse playing ground. It’s a place for information sharing. As such, the general consensus is not exactly in line with Google’s vision of a uniform web. Google started off as a search engine whose main task was to be the gateway of information - to lead people to the specific web addresses. From there on, they have evolved to be one of the leading beneficiaries of the world wide web. The next step in Google’s evolution seems to be quite natural to take control over content and hosting. Google has also recently announced that they are going to lay down undersea internet cable from Japan to Guam, and from Guam to Australia. They are portraying this decision as an economic decision which will save them money eventually after the cables are laid. But some are seeing this as a step to remove external dependencies and as a step closer to total control over the internet. Google’s recent partnering deal with WordPress is a proof that Google is taking steps towards owning up the web hosting space. AMP specification means that Google will have the final say over design specifications. The diversity in design will suffer as you would not want to spend time to design a site that won’t be indexed by Google. Hence the developers will only have two options, use the pre-designed template provided by Google, or make two specific website designs, one as per their own design consideration and the other one as per AMP. But Google will keep showing you error signs if your AMP version doesn’t match the main design. Hence the choice finally narrows down to choosing AMP. The trouble with AMP Your content published using AMP is stored in a Google cache and hence repeated views are loaded from the cache. This also means that the user will actually spend more time in Google’s own page and will see Google’s ads and not the ones which the content creator had put up. This by extension means loss of revenue for the actual content creator. Using Analytics is far more difficult in AMP-based pages. The AMP pages are difficult to customize and hence difficult to design without looking similar. So the web might end up with similar looking apps with similar buttons and UIs all across. The AMP model takes its own decisions as per how it actually shows your content. So you don’t get to choose your metadata being displayed, but Google does. That means less control over your content. With Google controlling the extent to which your website data is displayed, all the pages are going to look similar with very little metadata info shown, fake stories will appear parallel to normal news thumbnails because there will be very little text displayed to enable to make a call, whether a story is true or false. All of these come with the caveat that AMPed up pages will rank higher on Google. If that’s the proverbial carrot used to lure web publishers to bring their content under Google’s umbrella, then we must say that it’s going to be a tricky choice for developers. No one wants a slow web with irregular indexing and erroneous search results. But how far are we prepared to let go of individuality and design thinking in this process, that’s a question to ponder about. Google wants web developers to embrace AMP. Great news for users, more work for developers. Like newspapers, Google algorithms are protected by the First Amendment Implementing Dependency Injection in Google Guice

Mario Casciaro is a software engineer and technical lead with a passion for open source. After the recent publication of his successful book Node.JS Design Patterns, we caught up with him to discuss his views on today’s most important web development skills, and what the future holds. The best tool for the job may not be in your skillset yet I remember working on a small side project, something I try to do as much as possible, to put new skills into practice and try things outside of my job. It was a web application, something very similar to a social network, and I remember choosing Java with the Spring Framework as the main technology stack, and Backbone on the front-end. At the time - around 4 years ago - I was an expert Java developer, and considered it the technology with the most potential. It worked perfectly to implement enterprise web applications as well as mission-critical distributed applications and even mobile apps. While Java is still a popular and valuable tool in 2015, my experience doing this small side project made me rethink my opinion – I wouldn’t use it today unless there was a particular need for it. I remember that at some point I realized I was spending a lot of my development time in designing the object-oriented structure of the application and writing boilerplate code. Trying to find a solution, I migrated the project to Groovy and Grails and on the front-end I tried to implement a small homemade two-way binding framework. Things improved a little, but I was still feeling the need for something more agile on both ends, something more suited to the web. The web moves fast, so always let your skills evolve I wanted to try something radically different than the typical PHP, Ruby on Rails or Python for the server or JQuery or Backbone for the client. Fortunately I discovered Node.js and Angular.js, and that changed everything. By using Node I noticed that my mindset shifted from “how to do things” to “just get things done”. On the other hand, Angular revolutionized my approach to front end development, allowing me to drastically cut the amount of boilerplate code I was using. But most importantly, I realized that JavaScript and its ecosystem was becoming a seriously big thing. Today I would not even consider building a web application without having JavaScript as my primary player. The amount of packages on npm is staggering - a clear indication that the web has shifted towards JavaScript. The most impressive part of this story is that I also realized the importance that these new skills had in defining my career; if I wanted to build web applications, JavaScript and its amazing ecosystem had to be the focus of my learning efforts. This led me to find a job where Node, Angular and other cutting-edge JavaScript technologies actually played a crucial role in the success of the project I was in charge of creating. But the culmination of my renewed interest in JavaScript is the book I published 6 months ago - Node.jsDesignPatterns - which contains the best of the experience I accumulated since I devoted myself to the full-stack JavaScript mantra. The technologies and the skills that matter today for a web developer Today, if I had to give advice to someone approaching web development for the first time I would definitely recommend starting with JavaScript. I wouldn’t have said that 5-6 years ago, but today it’s the only language that allows you to get started both on the back end and the front end. Moreover JavaScript, in combination with other web technologies such as HTML and CSS, gives you access to an even broader set of applications with the help of projects like nw.js and ApacheCordova. PHP, Ruby, and Python are still very popular languages for developing the server-side of a web application, but for someone that already knows JavaScript, Node.js would be a natural choice. Not only does it save you the time it takes to learn a new language, it also offers a level of integration with the front end that is impossible with other platforms. I’m talking, of course, about sharing code between the server and the client and even implementing isomorphic applications which can run on both Node.js and the browser. React is probably the framework that offers the most interesting features in the area of isomorphic application development and definitely something worth digging into more, and it’s likely that we’ll also see a lot more from PouchDB, an isomorphic JavaScript database that will help developers build offline-enabled or even offline-first web applications more easily than ever before. Always stay ahead of the curve Today, as 4 years ago, the technologies that will play an important role in the web of tomorrow are already making an impact. WebRTC, for example, enables the creation of real-time peer-to-peer applications in the browser, without the need for any additional plugin. Developers are already using it to build fast and lightweight audio/video conferencing applications or even complete BitTorrent clients in the browser! Another revolutionizing technology is going to be ServiceWorkers which should dramatically improve the capabilities of offline applications. On the front end, WebComponents are going to play a huge role, and the Polymer project has already demonstrated what this new set of standards will be able to create. With regards to JavaScript itself, web developers will have to become familiar with the ES6 standard sooner than expected, as cross-compilation tools such as Babel are already allowing us to use ES6 on almost any platform. But we should also keep an eye on ES7 as it will contain very useful features to simplify asynchronous programming. Finally, as the browser becomes the runtime environment of the future, the recently revealed WebAssembly promises to give the web its own “bytecode”, allowing you to load code written in other languages from JavaScript, When WebAssembly becomes widely available, it will be common to see a complex 3D video game or a full-featured video editing tool running in the browser. JavaScript will probably remain the mainstream language for the web, but it will be complemented by the new possibilities introduced by WebAssembly. If you want to explore the JavaScript ecosystem in detail start with our dedicated JavaScript page. You'll find our latest and most popular, along with free tutorials and insights.

You've probably heard plenty of buzz about something called progressive web apps over the past couple of years – you might have even been given the opportunity to use some of these on your devices. You’re also here reading this article, so it’s probably safe to say you’re also at least somewhat interested in learning more about progressive web apps. Let’s dive into what they are, some characteristics of one, and how progressive web apps affect you as a developer. What’s this all about then? A progressive web app is a program that is stored on a server somewhere and given to the user on a web browser, but is delivered with and interacted with as a native application experience. Stated more simply, it is a web application that feels like a native application to the user. It is built using web development technologies (browser, server, database, etc.), but it's created with the design and feel of being a native application for the end users. It is a great attempt at creating an application that combines the benefits of a web-based application and a native application. Progressive web apps have some defining characteristics, like they are: Reliable: The app should load instantly even under poor network conditions. Lighting fast and app-like: The app should respond to the user's actions with speed and with a smooth interaction. Engaging and responsive: The app should give the feeling that it was made specifically for that device, but it should be able to work across all platforms. Protected and secure: Since it is still a web app, it is served over HTTPS to make sure the contents of the app are not messed with. Installable: The app can be saved to a device's home screen for offline usage. Linkable: The app can be shared and accessed through a URL. Up-to-date: The application is always up to date using service workers.  Why should you care? Now let's dive into why application developers should be interested in progressive web apps. As you probably already noticed when reading the list above this, there are plenty of benefits to using progressive web apps for the user. First off, it keeps the simplicity and speed of developing a web application. It is built using the same old web technology that you have been building your web application with, which tends to be easier and cheaper to get developed compared to a native application because that is device specific, and involves learning more techonologies. Second, it has service workers that allow users to use the application with some offline functionality. The service workers usually cache application resources in order to be used offline. In a standard web app, you would not be able to access anything offline, but in a progressive web app it gives that added benefit to the user. Third, it allows for fluidity between all of your devices. Because the user interface and the interactions with it are the same on all devices, it is easy for the user to use the progressive web app on multiple platforms. Fourth, learning about the topic of building a progressive web application does not involve you learning a new technology if you have already been developing web applications for some time now. All you need to do as a developer is to build the web application with the correct principles in mind when starting out. Looking ahead Progressive web appsare an awesome combination of a web app and a native app that have the combined benefits of developing either/or, and bringing it to the user in one application. You can build the application more easily, it can be used at least partially offline, it allows for a nice fluidity between all of your devices, and it does not require much extra learning on your part. I would highly suggest you take this approach into consideration when building your next application. If you wanted to take a look at some of the progressive web apps that are out today, check out this link. It gives you a link to some of the better progressive web applications to date.  About the author Antonio Cucciniello is a Software Engineer with a background in C, C++ and JavaScript (Node.Js) from New Jersey.   His most recent project called Edit Docs is an Amazon Echo skill that allows users to edit Google Drive files using your voice.  He loves building cool things with software, reading books on self-help and improvement, finance, and entrepreneurship. Follow him on twitter @antocucciniello, and follow him on GitHub here: https://github.com/acucciniello. 

If you have been paying attention to the world of web development lately, it can seem a little chaotic. There are brand new frameworks and libraries that come out each and every day. These frameworks are sometimes related to previous ones that recently came out, or they are attempting to develop something entirely new. As new technologies emerge, they change things that could have been standard for a long time. With these changes happening fairly often, it can be beneficial or frustrating, depending on the situation. Let's take a look at why the creation of new technologies in web development could be a benefit for some developers, or a negative for others. Why change and novelty in web development is awesome Let's first take a look at how the rapid changes in web development can be a wonderful thing for some developers. New tools and techniques to learn With new tech constantly emerging, you will always have something new to learn as a developer. This keeps the field interesting (at least for me and other developers I know that actually like the field). It allows you to continuously add to your skillset as well. You will constantly be challenged with the newer frameworks when learning them, which will help you learn future technologies faster. Having this skill of being a constant learner is crucial in a field that is always improving. Competition When there are a high number of frameworks that do similar things, the best ones will be the ones that are used by the majority of people. For instance, there are tons of front-end frameworks like React and Angular, but React and Angular are the ones that survive simply because of their popularity and ease of use. This is similar to how capitalism works: Only the best will survive. This creates a culture of innovation in the web development community and causes even more tech to be developed, but at a higher quality. Even better products A large amount of technology being released in a short period of time allows for developers to develop creative and stunning web pages using various combinations of technologies working together. If websites are stunning and easy to use, businesses are more likely to get customers to use their products. If customers are more likely to use products, that probably means they are spending money and therefore growing the economy. Who does not love awesome products anyway? Workflows become more efficient and agile When better web development tools are created, it becomes easier for other web developers out there to create their own web apps. Usually newer technologies present a brand new way of accomplishing something that happened to previously be more difficult. With this increased ability it allows you to build on top of the shoulder of giants, allowing new developers to create something that previously was too difficult or time consuming. Why change and novelty in web development is a pain Now let's take a look at how the ever-changing state of web development can be a bad thing for web developers. New tools require more learning time With each new technology, the user must learn exactly how it works and how it can even benefit their company or project. There is some time in the beginning that must be spent on actually figuring out how to get the new technology to work. Depending on the documentation, this can sometimes be easier than others, but that extra time can definitely hurt if you are attempting to hit a hard deadline. Identifying risk v. reward can be a challenge With attempting something new, there is always a risk involved. It can turn out that this framework will take up a large portion of your time to implement, and it may only give you a minor performance increase, or minor reduction in development time. You must make this tradeoff yourself. Sometimes it is worth it, other times it definitely is not. Support lifespans are getting shorter for many tools Something that is not popular or widely used will tend to lose support. You may have been an early adopter, when you thought that this technology would be great. Just because the technology was supported today, does not mean it will be supported in the future, when you plan on using it. Support can sometimes make or break the usage of an application and it can sometimes be safer to go with a more stable framework. In my opinion, an ever-changing web development landscape is a good thing, and you just need to keep up. But I've attempted to give you both sides of the coin in order for you to make a decision on your own. Antonio Cucciniello is a Software Engineer with a background in C, C++ and JavaScript (Node.js) from New Jersey. His most recent project called Edit Docs is an Amazon Echo skill that allows users to edit Google Drive files using your voice. He loves building cool things with software, reading books on self-help and improvement, finance, and entrepreneurship. Follow him on twitter @antocucciniello, and follow him on GitHub.

MongoDB is a popular document-based NoSQL database. Here in this post, I am listing some mistakes that I've found developers make while working on MongoDB projects. Database accessible from the Internet Allowing your MongoDB database to be accessible from the Internet is the most common mistake I've found developers make in the wild. Mongodb's default configuration used to expose the database to Internet; that is, you can connect to the database using the URL of the server it's being run on. It makes perfect sense for starters who might be deploying a database on a different machine, given how it is the path of least resistance. But in the real world, it's a bad default value that often is ignored. A database (whether Mongo or any other) should be accessible only to your app. It should be hidden in a private local network that provides access to your app's server only. Although this vulnerability has been fixed in newer versions of MongoDB, make sure you change the config if you're upgrading your database from a previous version, and that the new junior developer you hired didn't expose the database that connects to the Internet with the application server. If it's a requirement to have a database accessible from the open-Internet, pay special attention to securing the database. Having a whitelist of IP addresses that only have access to the database is almost always a good idea. Not having multiple database users with access roles Another possible security risk is having a single MongoDB database user doing all of the work. This usually happens when developers with little knowledge/experience/interest in databases handle the database management or setup. This happens when database management is treated as lesser work in smaller software shops (the kind I get hired for mostly). Well, it is not. A database is as important as the app itself. Your app is most likely mainly providing an interface to the database. Having a single user to manage the database and using the same user in the application for accessing the database is almost never a good idea. Many times this exposes vulnerabilities that could've been avoided if the database user had limited access in the first place. NoSQL doesn't mean "secure" by default. Security should be considered when setting the database up, and not left as something to be done "properly" after shipping. Schema-less doesn't mean thoughtless When someone asked Ronny why he chose MongoDB for his new shiny app, his response was that "it's schema-less, so it’s more flexible". Schema-less can prove to be quite a useful feature, but with great power comes great responsibility. Often times, I have found teams struggling with apps because they didn't think the structure for storing their data through when they started. MongoDB doesn’t require you to have a schema, but it doesn't mean you shouldn't properly think about your data structure. Rushing in without putting much thought into how you're going to structure your documents is a sure recipe for disaster. Your app might be small and simple and so easy right now, but simple apps become complicated very quickly. You owe your future self to have a proper well thought out database schema. Most programming languages that provide an interface to MongoDB have libraries to impose some kind of database schema on MongoDB. Pick your favorite and use it religiously. Premature Sharding Sharding is an optimization, so doing it too soon is usually a bad idea. Many times a single replica set is enough to run a fast smooth MongoDB that meets all of your needs. Most of the time a bad schema and (bad) indexing are the performance bottlenecks many users try to solve with sharding. In such cases sharding might do more harm because you end up with poorly tuned shards that don't perform well either. Sharding should be considered when a specific resource, like RAM or concurrency, becomes a performance bottleneck on some particular machine. As a general rule, if your database fits on a single server, sharding provides little benefit anyway. Most MongoDB setups work successfully without ever needing sharding. Replicas as backup Replicas are not backup. You need to have a proper backup system in place for your database and not consider replicas as a backup mechanism. Consider what would happen if you deploy the wrong code that ruins the database. In this case, replicas will simply follow the master and have the same damage. There are a variety of ways that you can use to backup and restore your MongoDB, be it filesystem snapshots or mongodump or a third party service like MMS. Having proper timely fire drills is also very important. You should be confident that the backups you're making can actually be used in a real-life scenario. Practice restoring your backups before you actually need them and verify everything works as expected. A catastrophic failure in your production system should not be the first time when you try to restore from backups (often only to find out you're backing up corrupt data). About the author Charanjit Singh is a freelance JavaScript (React/Express) developer. Being an avid fan of functional programming, he’s on his way to take on Haskell/Purescript as his main professional languages.

2017 has been an interesting year in web development. Today the role of a web developer is stretched across the stack - to be a great developer you need to be confident and dexterous with data, and have an eye for design and UX. Yes, all those discrete roles will be important in 2017, but being able to join the pieces of the development workflow together - for maximum efficiency - will be hugely valuable in 2018. What web development tools will matter most in 2018? Find out here. But what will really matter in 2018 in web development? Here's our list of the top 5 things you need to be thinking about… 1. Getting over JavaScript fatigue JavaScript fatigue has been the spectre haunting web development for the last couple of years. But it's effects have been very real - it's exhausting keeping up with the rapidly expanding ecosystem of tools. 'Getting over it', then, won't be easy - and don't think for a minute we're just saying it's time to move on and get real. Instead it's about taking the problem seriously and putting in place strategies to better manage tooling options. This article is a great exploration of JavaScript fatigue and it puts the problem in a rather neat way: JS Fatigue happens when people use tools they don't need to solve problems they don't have. What this means in practical terms, then, is that starting with the problem that you want to solve is going to make life much better in 2018. 2. Web components Web components have been a development that's helping to make the work of web developers that little bit easier. Essentially they're reusable 'bits' that don't require any support from a library (like jQuery for example), which makes front end development much more streamlined. Developments like this hint at a shift in the front end developer skillset - something we'll be watching closely throughout 2018. If components are making development 'easier' there will be an onus on developers to prove themselves in a design and UX sphere. 3. Harnessing artificial intelligence AI has truly taken on wider significance in 2017 and has come to the forefront not only of the tech world's imagination but the wider public one too. It's no longer an academic pursuit. It's not baked into almost everything we do. That means web developers are going to have to get au fait with artificial intelligence. Building more personalized UX is going to be top of the list for many organizations in 2018 - pressure will be on web developers to successfully harness artificial intelligence in innovative ways that drive value for their businesses and clients. 4. Progressive web apps and native-like experiences This builds on the previous two points. But ultimately this is about what user expectations are going to look like in 2018. The demand is going to be for something that is not only personalized (see #3), but something which is secure, fast and intuitive for a user, whatever their specific context. Building successful progressive web apps require a really acute sense of how every moving part is impacting how a user interacts with it - from the way data is utilised to how a UI is built. 2018 is the year where being able to solve and understand problems in a truly holistic way will be vital. 5. Improving the development experience 5. Web development is going to get simultaneously harder and easier - if that makes sense. Web components may speed things up, but you're time will no doubt quickly be filled by something else. This means that in 2018 we need to pay close attention to the development experience. If for example, we're being asked to do new things, deliver products in new ways, we need the tools to be able to do that. If agility and efficiency remain key (which they will of course), unlocking smarter ways of working will be as important as the very things we build. Tools like Docker will undoubtedly help here. In fact, it's worth looking closely at the changing toolchain of DevOps - that's been having an impact throughout 2017 and certainly will in 2018 too.

Last week, I embarked on a quest to build my first website that would simultaneously deliver on two puns; I would “launch” my website with a “landing” page that was of a rocket sailing across the stars. On my journey, I learned SO much that it probably best belongs in a BuzzFeed list. 7 things only a web dev hack would know “Position” is a thing no one on the Internet knows about. You change the attribute until it looks right, and hope no one breaks it. The Z-index has a number randomly ascribed until the element goes where you want. CSS animations are beyond my ability as someone who’s never really written CSS before. So is parallax scrolling. So is anything other than ‘width: x%’. Hosting sites ring you. All the time. They won’t leave you alone. The more tabs you have open the better you are as a person. Alt+Tab is the best keyboard hack ever. Web development is 60% deleting things you once thought were integral to the design. So, I bought a site, jslearner.com (cool domain, right?), included the boilerplate Bootstrap CDN, and got to work. Act I: Design, or, ‘how to not stick to plan’ Web design starts with the design bit, right? My initial drawing, like all great designs, was done on the back of an envelope that contained relatively important information. (Author’s note: I’ve now lost the envelope because I left it in the work scanner. Please can I get it back?!) As you can clearly see from the previous image, I had a strong design aesthetic for the site, right from the off. The rocket (bottom left) was to travel along the line (line for illustration purposes only) and correct itself, before finally landing on a moon that lay across the bottom of the site. In a separate drawing, I’d also decided that I needed two rows consisting of three columns each, so that my rocket could zoom from bottom left to top right, and back down again. This will be relevant in about 500 words. Confronting reality I’m a terrible artist, as you can see from my hand-drawn rocket. I have no eye for design. After toying with trying to draw the assets myself, I decided to pre-buy them. The pack I got from Envato, however, came as a PNG and a file I couldn’t open. So, I had to hack the PNG (puts on shades): I used Pixlr and magic-wanded the other planets away, so I was left with a pretty dirty version of the planet I wanted. After I had hand-painted the edges, I realised that I could just magic-wand the planet I wanted straight out. This wouldn’t be the first 2 hours I wasted. I then had to get my rocket in order. Another asset paid for, and this time I decided to try and do it professionally. I got Inkscape, which is baffling, and pressed buttons until my rocket looked like it had come to rest. So this: After some tweaking, became this: After flipping the light sources around, I was ready to charge triumphantly on to the next stage of my quest; the fell beast of design was slain. Development was going to be the easy part. My rocket would soar across the page, against a twinkling backdrop, and land upon my carefully crafted assets. Act II: Development, or, ‘responsive design is hard’ My first test was to actually understand the Bootstrap column thingy… CSS transformations and animations would be taking a back seat in the rocket ship. These columns and rows were to hold my content. I added some rules to include the image of the planets and a background color of ‘space blue’ (that’s a thing, I assure you). My next problem was that the big planet wasn’t sitting at the bottom of the page. Nothing I could do would rectify this. The number of open tabs is increasing… This was where I learned the value of using the Chrome/Mozilla developer tools to write rules and see what works. Hours later, I figured out that ‘fixed position’ and ‘100% width’ seemed to do the trick. At this point, the responsive element of the site was handling itself. The planets generally seemed to be fine when scaling up and down. So, the basic premise was set up. Now I just had to add the rocket. Easy, right? Responsive design is really quite hard When I positioned my rocket neatly on my planet – using % spacing of course – I decided to resize the browser. It went literally everywhere. Up, down, to the side. This was bad. It was important to the integrity of my design for the rocket to sit astride the planet. The problem I was facing was that I just couldn’t get the element to stay in the same place whilst also adjusting its size. Viewing it on a 17-inch desktop, it looked like the rocket was stuck in mid-air. Not the desired effect. Act III: Refactoring, or, ‘sticking to plan == stupid results’ When I ‘wireframed’ my design (in pencil on an envelope), for some reason I drew two rows. Maybe it’s because I was watching TV, whilst playing Football Manager. I don’t know. Whatever the reason, the result of this added row was that when I resized, the moon stuck to its row, and the rocket went up with the top of the browser. Responsive design is as much about solid structure as it is about fancy CSS rules. Realising this point would cost me hours of my life. Back to the drawing board. After restructuring the HTML bits (copy/paste), I’d managed to get the rocket/moon in to the same div class. But it was all messed up, again. Why tiny moon? Why?! Again, I spent hours tweaking CSS styles in the browser until I had something closer to what I was looking for. Rocket on moon, no matter the size. I feel like a winner, listen to the Knight Rider theme song, and go to bed. Act IV: Epiphany, or, ‘expectations can be fault tolerant’ A website containing four elements had taken me about 15 hours of work to make look ‘passable’. To be honest, it’s still not great, but it does work. Part of this is my own ignorance of speedier development workflows (design in browser, use the magic wand, and so on). Another part of this was just how hard responsive design is. What I hadn’t realised was how much of responsive design depends on clever structure and markup. I hadn’t realised that this clever structure doesn’t even start with HTML – for me, it started with a terrible drawing on the back of an envelope. The CSS part enables your ‘things’ to resize nicely, but without your elements in the right places, no amount of {z-position: -11049;} will make it work properly. It’s what makes learning resources so valuable; time invested in understanding how to do it properly is time well spent. It’s also why Bootstrap will help make my stuff look better, but will never on its own make me a better designer.

In this post I am not going to show you any game engine, nor framework, nor library. This post is a more general write-up that aims to give you a more general overview of the technology that powers some of these frameworks : WebGL. Introduction Back in the days, in 2011, 3D in the browser was not really a thing outside of the realm of Flash, and the websites didn't make much use of the canvas element like they do today. During that year, the Khronos Group started an initiative called WebGL. This project was about creating an implementation of OpenGL ES 2.0 in a royalty free, standard, and cross browser API. Even though the canvas element can only draw 2d primitives, it actually is possible to render 3D graphics at a decent speed with this element.  By making a clever use of perspective and using a lot of optimizations, MrDoob with THREE.js managed to create a 3D canvas renderer, which quite frankly offers stunning results as you can see here and there. But, even though canvas can do the job, its speed and level of hardware-acceleration is nothing compared to the one WebGL benefits from, especially when you take into account the browsers on lower-end devices such as our mobile phones. Fast-forward in time, when Apple officially announced the support of WebGL for mobile Safari in IOS 8, the main goal was reached, since most of the recent browsers were able to use this 3D technology natively. Can I have 3D ? It's very likely that you can now, although there are still some graphics cards that were not made to support WebGL, but the global support is very good now. If you are interested in learning how to make 3D graphics in the browser, I recommend you do some research about a library called THREE.js. This library has been around for a while and is usually what most people choose to get started with, as this library is just a 3D library and nothing more. If you want to interact with the mouse, or create a bowling game, you will have to use some additional plugins and/or libraries. 3D in the gaming landscape As the support and the awareness around WebGL started rising, some entrepreneurs and companies saw it as a way to create a business or wanted to take part in this 3D adventure. As a result, several products are available to you if you want to delve into 3D gaming. Playcanvas This company likes saying that they re-created "Unity in the browser", which is not far from the truth really. Their in-browser editor is very complete, and mimics the entity-component system that exists in Unity. However, I think the best thing they have created among their products is their real-time collaboration feature. It allows you to work on a project with a team and instantly updates the editor and the visuals for everyone currently viewing it. The whole engine was also open sourced a few months ago, which has given us beautiful demos like this one:  http://codepen.io/playcanvas/pen/ctxoD Feel free to check out their website and give their editor a try:  https://playcanvas.com Goo technology Goo technology is an environment that encompasses a 3D engine, the Goo engine, an editor and a development environment. Goo create is also a very nicely designed 3D editor in the browser. What I really like about Goo is their cartoony mascot, "Goon" that you can see in a lot of their demos and branding, which adds a lot of fun and humanity to them. Have fun watching this little dude in his adventures and learn more about the company in these links:  http://www.goocreate.com Babylonjs I wasn't sure if this one was worth including, Babylon is a contestant to THREE.js created by Microsoft that doesn't want to be "just a rendering engine," but wants to add some useful components available out-of-the-box such as camera controls, a physics engine, and some audio capabilities. Babylon is relatively new and definitely not as battle-tested as THREE.js, but they created a set of tools that help you get started with it that I like, namely the playground and the shader editor. 2D ? Yes, there is a major point that I haven't mentioned yet. WebGL has been used across more 2D games that you might imagine. Yes, there is no reason why 2D games shouldn’t have this level of hardware-acceleration. The first games that used WebGL for their 2D needs were Rovio and ZeptoLabs for the ports of their respective multi-million-dollar hits that are Angry Birds and Cut the Rope to JavaScript. When pixi.js came out, a lot of people started using it for their games. The major HTML5 game framework, Phaser is also using it. Play ! This is the end of this post, I hope you enjoyed it and that you want to get started with these technologies. There is no time to waste -- it's all in your hands. About the author Alvin Ourrad is a web developer fond of the web and the power of open standards. A lover of open source, he likes experimenting with interactivity in the browser. He currently works as an HTML5 game developer.

Let me give you a quick disclaimer. This is a bit of a manifesto. Last year I started a little technology company with some friends of mine. We were lucky enough to get a solid client for web development right away. He was an author in need of a blogging app to communicate with the fans of his upcoming book. In another post I have detailed how I used Angular.js, among other tools, to build this responsive, dynamic web app. Using Angular.js is a wonderful experience and I would recommend it to anyone. However, Angular.js really only looks good by comparison. By this I mean, if we allow any web framework to exist in a vacuum and not simply rank them against one another, they are all pretty bad. Before you gather your pitchforks and torches to defend your favorite flavor let me explain myself. What I am arguing in this post is that many of the frameworks we use are not worth their weight in code. In other words, we add a whole lot of code to our apps when we import the frameworks, and then in practice using the framework is only a little bit better than using jQuery, or even pure JavaScript. And yes I know that using jQuery means including a whole bunch of code into your web app, but frameworks like Angular.js are many times built on top of jQuery anyway. So, the weight of jQuery seems to be a necessary evil. Let’s start with a simple http request for information from the backend. This is what it looks like in Angular.js: $http.get('/dataSource').success(function(data) { $scope.pageData = data; }); Here is a similar request using Ember.js: App.DataRoute = Ember.Route.extend({ model: function(params) { return this.store.find('data', params.data_id); } }); Here is a similar jQuery request: $.get( "ajax/stuff.html", function( data ) { $( ".result" ).html( data ); alert( "Load was performed." ); }); It's important for readers to remember that I am a front-end web developer. By this, I mean I am sure there are complicated, technical, and valid reasons why Ember.js and Angular.js are far superior to using jQuery. But, as a front-end developer, I am interested in speed and simplicity. When I look at these http requests and see that they are overwhelmingly similar I begin to wonder if these frameworks are actually getting any better. One of the big draws to Angular.js and Ember.js is the use of handlebars to ease the creation of dynamic content. Angular.js using handlebars looks something like this: <h1> {{ dynamicStuff }} </h1> This is great because I can go into my controller and make changes to the dynamicStuff variable and it shows up on my page. However, the following accomplishes a similar task using jQuery. $(function () { var dynamicStuff = “This is dog”; $(‘h1’).html( dynamicStuff ); }); I admit that there are many ways in which Angular.js or Ember.js make developing easier. DOM manipulation definitely takes less code and overall the development process is faster. However, there are many times that the limitations of the framework drive the development process. This means that developers sacrifice or change functionality simply to fit the framework. Of course, this is somewhat expected. What I am trying to say with this post is that if we are going to sacrifice load-times and constrict our development methods in order to use the framework of our choice can they at least be simpler to use? So, just for the sake of advancement lets think about what the perfect web framework would be able to do. First of all, there needs to be less set up. The brevity and simplicity of the http request in Angular.js is great, but it requires injecting the correct dependencies in multiple files. This adds stress, opportunities to make mistakes and development time. So, instead of requiring the developer to grab each specific tool for each specific implementation what if the framework took care of that for you? By this I mean if I were to make an http request like this: http( ‘targetURL’ , get , data) When the source is compiled or interpreted the needed dependencies for this http request are dynamically brought into the mix. This way we can make a simpler http request and we can avoid the hassle of setting up the dependencies. As far as DOM manipulation goes, the handlebars seem to be about as good as it gets. However, there needs to be better ways to target individual instances of a repeated elements such as <p> tags holding the captions in a photo gallery. The current solutions for problems like this one are overly complex. Especially when this issue involves one of the most common things on the internet, a photo gallery. About the Author As you can see, I am more of a critic than a problem solver. I believe the issues I bring up here are valid. As we all become more and more entrenched in the Internet of Things, it would be nice if the development process caught up with the standards of ease that end users demand.

Kicked into overdrive by Apple's iOS9 infamously coming with adblocking options for Safari, the content creators of the Internet have woken up to the serious challenge of ad-blocking tech. The AdBlock+ Chrome extension boasts over 50 million active users. I'm one of them. I'm willing to bet that you might be one too. AdBlock use is rising massively and globally and shows no sign of slowing down. Commentators have blamed the web-reading public, have declared web publishers have brought this on themselves and even made worryingly convincing arguments that adblocking is a conspiracy by corporate supergiants to kill the web as we know it. They all agree on one point though - the way we present and consume web content is going to have to evolve or die. So how might adblocking change the web? We All Go Native One of the most proposed and most popular solutions to the adblocking crisis is to embrace "native" advertising. Similar to sponsorship or product placement in other media, native advertising interweaves its sponsor into the body of the content piece. By doing so, an advert is made immune to the traditional scripts and methods that identify and block net ads. This might be a thank you note to a sponsor at the end of a blog, an 'advertorial' upsell of a product or service, or corporate content marketing where a company produces and promotes their own content in a bid to garner your attention for their paid products. (Just like this blog. I'm afraid it's content marketing. Would you like to buy a quality tech eBook? How about the Web Developer's Reference guide - your Bible for everything you need to know about web dev! Help keep this Millennial creative in a Netflix account and pop culture tee-shirts.) The Inevitable Downsides Turns out nobody wants to read sponsored content - only 24% of readers scroll down on a native ad. A 2014 survey by Contently revealed two-thirds of respondents saying they felt deceived by sponsored advertising. We may see this changing. As the practice becomes more mainstream, readers come to realize it does not impact on quality or journalistic integrity. But it's a worrying set of statistics for anyone who hoped direct advertising might save them from the scourge of adblock. The Great App Exodus There's a increasingly popular prediction that adblocking may lead to a great exodus of content from browser-based websites to exist more and more in a scattered app-based ecosystem. We can already see the start of this movement. Every major content site bugs you to download its dedicated app, where ads can live free of fear. If you consume most of your mobile media through Snapchat Discover channels, through Facebook mobile sharing, or even through IM services like Telegram, you'll be reading your web content in that apps dedicated built-in reader. That reader is, of course, free of adblocking extensions. The Inevitable Downsides The issue here is one of corporate monopoly. Some journalists have criticized Facebook Instant (the tech which has Facebook host articles from popular news sites for increased load times) for giving Facebook too much power over the news business. Vox's Matthew Yglesias's predicts restructuring where "instead of digital media brands being companies that build websites, they will operate more like television studios — bringing together teams that collaborate on the creation of content, which is then distributed through diverse channels that are not themselves controlled by the studio." The control that these platforms could exert raises troubling concerns for the future of the Internet as a bastion of free and public speech. User Experience with Added Guilt Alongside adding advertising <script> tags, web developers are increasingly creating sites that detect if you're using AdBlocking software and punishing you accordingly. This can take many forms - from a simple plea to be put on your whitelist in order to keep the servers running, to the cruel and inhuman: Some sites are going as far as actively blocking content for users using adblockers. Trying accessing an article on the likes of Forbes or CityAM with an adblocker turned on. You'll find yourself greeted with an officious note and a scrambled page that refuses to show you the goods unless you switch off the blocker. The Inevitable Downsides No website wants to be in a position where it has to beg or bully their visitors. Whilst your committed readers might be happy to whitelist your URL, antagonizing new users is a surefire way to get them to bounce from the site. Sadly, sabotaging their own sites for ad blocking visitors might be one of the most effective ways for 'traditional' web content providers to survive. After all, most users block ads in order to improve their browsing experience. If the UX of a site on the whitelist is vastly superior to the UX under adblock, it might end up being more pleasant to browse with the extension off. An Uneasy Truce between Adblockers and Content In many ways adblocking was a war that web adverts started. From the pop-up to the autoplaying video, web ad software has been built to be aggressive. The response of adblockers is an indiscriminate and all-or-nothing approach. As Marco Arment, creator of the Peace adblocking app, notes "Today’s web readers [are so] fed up that they disable all ads, or even all Javascript. Web developers and standards bodies couldn’t be more out of touch with this issue, racing ahead to give browsers and Javascript even more capabilities without adequately addressing the fundamental problems that will drive many people to disable huge chunks of their browser’s functionality." Both sides need to learn to trust one another again. The AdBlock+ Chrome extension now comes with an automatic whitelist of sites; 'guilt' website UX works to remind us that a few banner ads might be the vital price we pay to keep our favorite mid-sized content site free and accessible. If content providers work to restore sanity to the web on their ends, then our need for adblocking software as users will diminish accordingly. It's a complex balance that will need a lot of good will from both 'sides' - but if we're going to save the web as we know it, then a truce might be necessary. Building a better web? How about checking out our Essential Web Dev? Get five titles for only $50!  

Despite living in a world dominated by streaming video and visual social networks, the web is still primarily a place for reading. This means there is a tremendous amount of value in having solid, readable typography on your site. With the advances in CSS over the past few years, we are finally able to tackle a variety of typographical issues that print has long solved. In addition, we are also able to address a lot of challenges that are unique to the web. Never have we had more control over web typography. Here are 6 quick snippets that can take yours to the next level. Responsive Font Sizing Not every screen is created equal. With a vast array of screen sizes, resolutions, and pixel densities it is crucial that our typography adjusts itself to fit the user's screen. While we've had access to relative font measurements for awhile, they have been cumbersome to work with. Now with rem we can have relative font-sizing without all the headaches. Let's take a look at how easy it is to scale typography for different screens. html { font-size: 62.5%; } h1 { font-size: 2.1rem // Equals 21px; p { font-size: 1.6rem; // Equals 16px } By setting font-size to 62.5% it allows use base 10 for setting our font-size using rem. This means a font set to 1.6rem is the same as setting it to 16px. This makes it easy to tell what size our text is actually going to be, something that is often an issue when using em. Browser support for rem is really good at this stage, so you shouldn't need a fallback. However, if you need to support older IE it is simple as creating a second font-size rule set in px after the line you set it in rem. All that is left is to scale our text based on screen size or resolution. By using media queries, we can keep the relative sizing of type elements the same without having to manually adjust each element for every breakpoint. // Scale Font Based On Screen Resolution @media only screen and (min-device-pixel-ratio: 2), only screen and (min-resolution: 192dpi) { html { font-size: 125%; } } // Scale Font Based On Screen Size @media only screen and (max-device-width : 667px) { html { font-size: 31.25%; } } This will scale all the type on the page with just one property per breakpoint, there is now no excuse not to adjust font-size based on your users' screens. Relative Line Height Leading, or the space between baselines in a paragraph, is an important typographical attribute that directly affects the readability of your content. The right line height provides a distinction between lines of text, allowing a reader to scan a block of testing quickly. An easy tip a lot of us miss is setting a unitless line-height. By setting line-height in this way, it acts as a ratio to the size of your type. This scales your leading with your font-size, making it a perfect compliment to using rem: p { font-size: 1.6rem; line-height: 1.4; } This will set our line-height at a ratio of 1.4 times our font-size. Consequently, 1.4 is a good value to start with when tweaking your leading, but your ratio will ultimately depend on the font you are using. Rendering Control The way type renders on a web page is affected not only by the properties of a user's screen, but also by their operating system and browser. Different font-rendering implementations can mean the difference between your web fonts loading quickly and clearly or chugging along and rendering into a pixelated mess. Font services like TypeKit recognize this problem and provide you a way to preview how a font will appear in different operating system/browser combinations. Luckily though, you don't have to leave it completely up to chance. Some browser engines, like WebKit, give us some extra control over how a font renders. text-rendering controls how a font is rendered by the browser. If your goal is optimal legibility, setting text-rendering to optimizeLegibility will make use of additional information provided in certain fonts to enhance kerning and make use of built-in ligatures. p.legibility { text-rendering: optimizeLegibility; } While this sounds perfect, there are scenarios where you don't want to use it. It can crush rendering times on less powerful machines, especially mobile browsers. It is best to use it sparingly on your content, and not just apply to every piece of text on a page. All browsers support this property except Internet Explorer. This is not the only way you can optimize font rendering. Webkit browsers also allow you to adjust the type of anti-aliasing they use to render fonts. Chrome is notoriously polarizing in how fonts look, so this is a welcome addition. It is best to experiment with the different options, as it really comes down to the font you've chosen and your personal taste. p { webkit-font-smoothing: none; webkit-font-smoothing: antialiased; webkit-font-smoothing: subpixel-antialiased; } Lastly, if you don't find that the font-smoothing options aren't enough, you can had a bit of boldness to your fonts in WebKit, with the following snippet. The result isn't for everyone, but if you find your font is rendering a bit on the light side, it does the trick. p { -webkit-text-stroke 0.35px; } Hanging Punctuation Hanging punctuation is a typographical technique that keeps punctuation at the begging of a paragraph from disrupting the flow of the text. By utilizing the left margin, punctuation like open quotes and list bullets are able to be displayed while still allowing text to be left justified. This makes it easier for the reader to scan a paragraph. We can achieve this effect by applying the following snippet to elements where we lead with punctuation or bullets. p:first-child { text-indent: -0.5rem; } ul { padding: 0px; } ul li { list-style-position: outside; } One note with bulleted lists is to make sure its container does not have overflow set to hidden as this will hide the bullets when they are set to outside if you want to be super forward-looking. Work is being done on giving us even more control over hanging punctuation, including character detection and support for leading and trailing punctuation. Proper Hyphenation One of the most frustrating things on the web for typography purists is the ragged right edge on blocks of text. Books solve this through carefully justified text. This, unfortunately, is not an option for us yet on the web, and while a lot of libraries attempt to solve this with JavaScript, there are some things you can do to handle this with CSS alone. .hyphenation { -ms-word-break: break-all; word-break: break-all; // Non standard for webkit word-break: break-word; -webkit-hyphens: auto; -moz-hyphens: auto; hyphens: auto; } .no-hyphenation { -ms-word-break: none; word-break: none; // Non standard for webkit word-break: none; -webkit-hyphens: none; -moz-hyphens: none; hyphens: none; } Browser support is pretty solid, with Chrome being the notable exception. You must set a language attribute on the parent element, as the browser leverages this to determine hyphenation rules. Also, note if you are using Autoprefixer, it will not add all the appropriate variations to the hyphens property. Descender-Aware Underlining This is a newer trick I first noticed in iMessage on iOS. It makes underlined text a bit more readable by protecting descenders (the parts of a letter that drop before the baseline) from being obscured by the underline. This makes it an especially good fit for links. .underline { text-decoration: none; text-shadow: .03rem 0 #FFFFFF,-.03rem 0 #FFFFFF,0 .03rem #FFFFFF,0 -.03rem #FFFFFF,.06rem 0 #FFFFFF,-.06rem 0 #FFFFFF,.09rem 0 #FFFFFF,-.09rem 0 #FFFFFF; color: #000000; background-image: linear-gradient(#FFFFFF,#FFFFFF),linear-gradient(#FFFFFF,#FFFFFF),linear-gradient(#000000,#000000); background-size: .05rem 1px,.05rem 1px,1px 1px; background-repeat: no-repeat,no-repeat,repeat-x; background-position: 0 90%,100% 90%,0 90%; } First, we create a text-shadow the same color as our background (in this case white) around the content we want to be underlined. The key is that the shadow is thin enough to obscure things behind it, without overlapping other letters. Next, we use a background gradient to recreate our underline. The text shadow alone is not enough as a normal text-decoration: underline is actually placed over the type. The gradient will appear just like a normal underline, but now the text-shadow will obscure the underline where the descenders overlap it. By using rem, this effect also scales based on our font-size. Conclusion Users still spend a tremendous amount of time reading online. Making that as frictionless as possible should be one of the top priorities for any site with written content. With just a little bit of CSS, we can drastically improve the readability of our content with little to no overhead. About The Author Brian is a Front-End Architect, Designer, and Product Manager at Piqora. By day, he is working to prove that the days of bad Enterprise User Experiences are a thing of the past. By night, he obsesses about ways to bring designers and developers together using technology. He blogs about his early stage startup experience at lostinpixelation.com, or you can read his general musings on twitter @b_hough.

2016 will be the year of AngularJS 2.0 and it’s going to be awesome. AngularJS has been a known quantity to Packt for about 4 years, and has been around for 6. In the last 24 months, we’ve really seen it gain massive adoption amongst our user base. Conferences are held in its name. It will come as no surprise that it’s one of our best-selling topics. Thousands of apps have been deployed and created with it. People, do in fact, love it. So the decision to rewrite the entire project seems odd. A lot has been written about this already from developers who know their stuff. Some are for it, some against it, and some are a little more balanced. For a technically reasoned article, Rob Eisenberg’s blog about AngularJS 2.0 is the best of many I’ve read. For one that quotes Shakespeare, read on. At Packt I’ve been the commissioning editor on a fair number of products. You may remember me from such hits as MEAN Web Development and Mastering D3.js. While I may not have the developer nous, creating a product is the same process whether it is a good framework or a good book. And part of this process understanding when you’ve got a good product, and when you had a good product that needs ripping up, and starting over. What’s past is prologue AngularJS’s design was emergent from increased adoption. It started life as a tool to aid designers throw up a quick online form. It was an internal tool at Google. They didn’t realise that every Joe Web Developer would be using it to power their client’s not-so-SEO-friendly bespoke applications. It’s the equivalent of what would happen if people started using this blog as a template for all future blogs. I’d enjoy it for the first few years, living the blogosphere high-life, then people would start moaning to me, and I would hate it. I’d have to start again, for my own health as much as for the health of the millions of bloggers who were using my formatting to try and contain their vastness. So we’re agreed that they need to change things. Good. Oh brave new world/That has such features in’t Many frameworks change things whilst maintaining backwards compatibility. WordPress is a famous example of doing everything possible to avoid introducing breaking-changes at any major update. The result is, by now, a pretty bloated application that much like Angular, started out serving a very different purpose to how it now finds itself being deployed. It’s what gave rise to smaller, lighter-weight platforms like Ghost, designed purely for blogging. AngularJS however is not an example of developers maintaining backwards compatibility. It takes pleasure in starting over. In fact, you can just about rip up your old Angular apps now. It’s for your own good. By starting from a clean slate, the Angular team have the chance to design AngularJS in to what it should be rather than what it ended up being. It may not make sense to the developers who are using Angular 1.x at the moment, but to be frank Google doesn’t care. It cares about good products. It’s planning a product that will endeavour to remain relevant in to the future, rather than spending its time trying to patch up something that was a result of rushed 2010 thinking. Part of this attempt at continued relevance is TypeScript. TypeScript extends the capabilities of ES6; moving to AngularJS 2.0 before ES7 is released means that it’s recommended that TypeScript is used to make the most of what Angular offers. This is a big move, but it’s an attempt at moving the capabilities forward. Doing something is always preferable to doing nothing. The other headline act, and related to the ES6 features is the move to make Angular compatible with Web Components. Web Components will redefine what web development means, in time, and making sure that their framework is on hand to help deliver them safely to developers is again a smart product decision. The temporary pain of the rewrite will be rewarded by increased ease of use and longevity for the developers and clients who build and consume AngularJS applications. There are a whole host more features; a move to mobile-first design, which I understand, and lots of technical and syntax improvements, which I don’t; increased performance, and plenty more too. Every decision is being made to make Angular a better product for everyone who uses it. Gentle breath of yours my sails/Must fill, or else my project fails AngularJS 2.0 has been a divisive figure in the web development world. I’ve been at Packt for three years and can’t remember a time when such a popular and well-used technology completely ripped up everything they had and started again. It will set a precedent in software that will shape the future, either way it ‘goes down’. What we should focus on is that this wholesale change is designed to make the product better – not just now, but in to the future - and that decision should be applauded. It’s not unheard of for Google to stop/start/abandon high-profile projects (cough Google Glass cough), but they should be recognised nonetheless for their dedication in trying to make this a more accessible and useful platform long term. Ultimately though, it will be the users who decide if they won or lost. The team are bringing a different project in the hope that people see its advantages, but no matter the intent a product is only useful if the consumers find it useful. Through our ‘gentle breath’, the Angular project will fly or fail. Let’s embrace it.

The following infographic is taken from our comprehensive Skill Up IT industry salary reports, with data from over 20,000 developers. Download the full size infographic here.