Tech Guides - Front-End Web Development

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.

When I started at Packt, I was an English grad with a passion for working with authors, editorial rule, and really wanted to get to work structuring great learning materials for consumers. I’d edited the largest Chinese-English dictionary ever compiled without speaking a word of Chinese, so what was tech but a means to an end that would allow me to work on my life’s ambition? Fast forward 2 years, and hours of independent research and reading Hacker News, and I’m more or less able to engage in a high level discussion about any technology in the world, from Enterprise class CMIS to big data platforms. I can identify their friends and enemies, who uses what, why they’re used, and what learning materials are available on the market. I can talk in a more nebulous way of their advantages, and how they ”revolutionized” that specific technology type. But, other than hacking CSS in WordPress, I can’t use these technologies. My specialization has always been in research, analysis, and editorial know-how. In April, after deploying my first WordPress site (exploration-online.com), I decided to change this. Being pretty taken with Python, and having spent a lot of time researching why it’s awesome (mostly watching Monty Python YouTube clips), I decided to try it out on Codecademy. I loved the straightforward syntax, and was getting pretty handy at the simple things. Then Booleans started (a simple premise), and I realised that Python was far too data intensive. Here’s an example: · Set bool_two equal to the result of-(-(-(-2))) == -2 and 4 >= 16**0.5 · Set bool_three equal to the result of 19 % 4 != 300 / 10 / 10 and False This is meant to explain to a beginner how the Boolean operator “and” returns “TRUE” when statements on either side are true. This is a fairly simple thing to get, so I don’t really see why they need to use expressions that I can barely read, let alone compute... I quickly decided Python wasn’t for me. I jumped ship to JavaScript. The first thing I realised was that all programming languages are pretty much the same. Variables are more or less the same. Functions do a thing. The syntax changes, but it isn’t like changing from English to Spanish. It’s more like changing from American English to British English. We’re all talking the same, but there are just slightly different rules. The second thing I realized was that JavaScript is going to be entirely more useful to me in to the future than Python. As the lingua franca of the Internet, and the browser, it’s going to be more and more influential as adoption of browser over native apps increases. I’ve never been a particularly “mathsy” guy, so Python machine learning isn’t something I’m desperate to master. It also means that I can, in the future, work with all the awesome tools that I’ve spent time researching: MongoDB, Express, Angular, Node, and so on. I bought Head First JavaScript Programming, Eric T. Freeman, Elisabeth Robson, O’Reilly Media, and aside from the 30 different fonts used that are making my head ache, I’m finding the pace and learning narrative far better than various free solutions that I’ve used, and I actually feel I’m starting to progress. I can read things now and hack stuff on W3 schools examples. I still don’t know what things do, but I no longer feel like I’m standing reading a sign in a completely foreign language. What I’ve found that books are great at is reducing the copy/paste mind-set that creeps in to online learning tools. C/P I think is fine when you actually know what it is you’re copying. To learn something, and be comfortable using it in to the future, I want to be able to say that I can write it when needed. So far, I’ve learned how to log the entire “99 Bottles of Beer on the Wall” to the console. I’ve rewritten a 12 line code block to 6 lines (felt like a winner). I’ve made some boilerplate code that I’ve got no doubt I’ll be using for the next dozen years. All in all, it feels like progress. It’s all come from books. I’ll be updating this series regularly when I’ve dipped my toe into the hundreds of tools that JavaScript supports within the web developer’s workflow, but for now I’m going to crack on with the next chapter. For all things JavaScript, check out our dedicated page! Packed with more content, opinions and tutorials, it's the go-to place for fans of the leading language of the web. 

AngularJS stands at the apex of the way we think about web development today. Even as we look ahead to Angular 2.0, the framework serves as a useful starting point for thinking about the formation of contemporary expectations about what a web developer actually does and the products and services they create. Notably (for me at least) Angular is closely tied up with Packt’s development over the past few years. It’s had an impact on our strategic focus, forcing us to think about our customers in new ways. Let’s think back to the world before AngularJS. This was back in the days when Backbone.js meant something, when Knockout was doing the rounds. As this article from October has it, AngularJS effectively took advantage of a world suffering from ‘Framework fatigue’. It’s as if there was a ‘framework bubble’, and it’s only when that bubble burst that the way forward becomes clearer. This was a period of experimentation and exploration; improvement and efficiency were paramount, but a symptom of this was the way in which trends – some might say fads – took hold of the collective imagination. This period was a ‘framework’ bubble which, I’d suggest, prefigures the startup bubble, a period in which we’re living today. Developers were looking for new ways of doing things; they wanted to be more efficient, their projects more scalable, fast, and robust. All those words that are attached to development (in both senses of the word) took on particular urgency. As you might expect, this unbelievable pace of growth and change was like catnip for Packt. This insatiable desire for new tools was something that we could tapped into, delivering information and learning materials on even the most niche new tools. It was exciting. But it couldn’t last. It was thanks to AngularJS that this changed. Ironically, if AngularJS burst the framework bubble, ending what seemed like an endless stream of potential topics to cover, it also supplied us with some of our most popular titles. AngularJS Web Application Development Cookbook, for example, was a huge success. Written by Matt Frisbie, it helped us to forge a stronger relationship with the AngularJS world. It was weird – its success also brought an end to a very exciting period of growth, where Packt was able to reach out to new customers, small communities that other publishers could not. But we had to grow up. AngularJS was like a friend’s wedding; it made us realise that we needed to become more mature, more stable. But why, we should ask, was AngularJS so popular? Everyone is likely to have their own different story, their own experience of adopting AngularJS, and that, perhaps, is precisely the point. Brian Rinaldi, in the piece to which I refer above, notes a couple of things that made Angular a framework to which people could commit. Its ties with Google, for example gave it a mark of authority and reliability, while its ability to integrate with other frameworks means developers still have the flexibility to use the tools they want to while still having a single place to which they could return. Brian writes: The point is, all these integrations not only made the choice of Angular easier, but make leaving harder. It’s no longer just about the code I write, but Angular is tied into my entire development experience. Experience is fundamental here. If the framework bubble was all about different ways of doing the same thing faster and more effectively, today the reverse is true. Developers want to work in one way, but to be able to do lots of things. It’s a change in priorities; the focus of the modern web developer in 2016 has changed. The challenges are different, as mobile devices, SPAs, cloud, personalization, have become fundamental issues for web developers to reckon with. Good web developers looks beyond the immediacy of their project, and need to think carefully about users and about how they can deliver a great product or service. That’s what we’ve found at Packt. The challenges faced by the customers we serve are no longer quite so transparent or simple. If, just a few years ago, we relied upon the simple need to access information about a new framework, today the situation is more nuanced. Many of the challenges are due to changing user behaviour, a fragmentation of needs and contexts. For example, maybe you want to learn responsive web design? Or need to build a mobile app? Of course, these problems haven’t just appeared in the last 12 months, but they are no longer additional extras, but central to success. It’s these problems that have had a part in causing the startup bubble – businesses solving (or, if they’re really good, disrupting) customer needs with software. A framework such as React might be seen as challenging AngularJS. But despite its dedicated, almost evangelical core of support, it’s nevertheless relatively small. And it would also be wrong to see the emergence of React (alongside other tools, including Meteor), as a return to the heady days of the framework bubble. Instead it has grown out of a world inculcated by Angular – it is, remember, a tool designed to build a very specific type of application. The virtual DOM, after all, is an innovation that helps deliver a truly immediate and fast user experience. The very thing that makes React great is why it won’t supplant Angular – why would it even want to? If you do one thing, and do it well, you’re adding value that people couldn’t get from anywhere else. Fear of obsolescence – that’s the world in which AngularJS entered, and the world in which Packt grew. But today, the greatest fear isn’t so much obsolescence, it’s ‘Am I doing the right thing for my users? Are my customers going to like this website – this new app?’ So, as we await Angular 2.0, don’t forget what AngularJS does for you – don’t forget the development experience and don’t forget to think about your users. Packt will be ready when you want to learn 2.0 – but we’ll also still have the insights and guidance you need to do something new with AngularJS. Progress and development isn’t linear; it’s never a straight line. So don’t be scared to explore, rediscover what works. It’s not always about what’s new, it’s about what’s right for you. Save up to 70% on some of our very best web development titles from 11th to 17th April. From Flask to React to Angular 2, it's the perfect opportunity to push your web development skills forward. Find them here.

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.

Happy New Year, Web Devians. We've just finished off quite a year for web technologies, haven't we? 2014 was categorised by a growth in diversity – nowadays there’s an embarrassment of riches when it comes to making the most of CSS and JavaScript. We’re firmly past the days when jQuery was considered fancy. This year it wasn’t a question of whether we were using a framework – instead we’ve mostly been tearing our hair out trying to decide which one fits where. But whether you’re pinning your colours to Backbone or Angular, Node or PHP, there have been some clear trends in how the web is changing. Here’s Packt’s countdown of the top seven ways web tech has grown this year. If you weren’t thinking about these things in 2014, then it might be time to get up to speed before 2015 overtakes you! Angular We saw it coming in 2013, but in 2014 Angular basically ate everything. It’s the go-to framework for a subset of JavaScript projects that we’re going to refer to here as [“All Projects Ever”].  This is a sign of the times for where front-end development is right now. The single-page web application is now the heart of the new internet, which is deep, reactive, and aware. 2014 may go down as the year we officially moved the party to the client side. Responsive Web Design Here at Packt we’ve seen a big increase in people thinking about responsive design right from the beginning of their projects, and no wonder. In 2014 mobile devices crossed the line and outstripped traditional computers as the main way in which people browse the web. We glimpse the web now through many screens in a digital hall of mirrors. The sites we built in 2014 had to be equally accessible whether users were on IE8 at the library, or tweeting from their Android while base jumping. The MEAN stack 2014 put to rest for good the idea that JavaScript was a minor-league language that just couldn’t hack it on the back end. In the last twelve months MEAN development has shown us just how streamlined and powerful Node can be when harnessed with front-end JavaScript and JSON data storage. 2014 was for MongoDB, Express, Angular and Node had their break-out year this year as the hottest band in web dev. Data visualisation Did you know that all the knowledge available in the whole world before 1800 compresses to fewer bytes than Twitter streams in a minute? Actually, I just made that up. But it is true that we are generating and storing data at an increasingly hectic rate. When it comes to making visual sense of it, web tech has had a big role to play. D3 continued to hold its own as one of the most important tools in web development this year. We’ve all been thinking visually about charts and infographics. Which brings us to… Flat design The internet we built in 2014 was flat and stripy, and it’s wonderful.  Google’s unveiling of Material Design at this year’s I/O conference cemented the trend we’d all been seeing. Simple vector graphics, CSS animations and a mature code-based approach to visuals has swept the scene. There are naysayers of course (and genuine questions about accessibility, which we’ll be blogging about next year) but overall this aesthetic feels mature. Like moments in traditional architecture, 2014 felt like a year in which we cemented a recognisable design era. Testing and build tools Yes, we know. The least fun part of JavaScript – testing it and building, rebuilding, rebuilding. Chances are though that if you were involved in any large-scale web development this year you’ve now got a truly impressive Bat-utility belt of tools to work with. From Yeoman, to Gulp or Grunt, to Jasmine, to PhantomJS, updates have made everything a little more sophisticated. Cross-platform hybrid apps For decades we’ve thought about HTML/CSS/JavaScript as browser languages. With mobile technology though, we’ve broadened thinking and bit by bit JS has leaked out of the browser. When you think about it, our phones and tablets are full of little browser-like mutants, gleefully playing with servers and streaming data while downplaying the fact that their grandparents were Netscape and IE6. This year the number of hybrid mobile apps – and their level of sophistication – has exploded. We woke up to the fact that going online on mobile devices can be repackaged in all kinds of ways while still using web-tech to do all the heavy lifting. All in all, it’s been an exciting year. Happy New Year, and here’s to our new adventures in 2015!

  Sample Code You can find the sample code on Simon's Github repository.   About The Author Simon Højberg is a Senior UI Engineer at Swipely in Providence, RI. He is the co-organizer of the Providence JS Meetup group and former JavaScript instructor at Startup Institute Boston. He spends his time building functional User Interfaces with JavaScript, and hacking on side projects like cssarrowplease.com. Simon recently co-authored "Developing a React Edge."

“As a Service” services (service2?) generally allow younger companies to scale quickly and efficiently. A lot of the hassle is abstracted away from the pain of implementation, and they allow start-ups to focus on the key drivers of any company – product quality and product availability. For less than the cost of proper infrastructure investment, you can have highly-available, fully distributed, buzzword enabled things at your fingertips to start running wild with. However, “as a Service” providers feel like they’re filling a short-term void rather than building long-term viable option for companies. Here’s why. 1. Cost The main driver of SaaS is that there’s lower upfront costs. But it’s a bit like the debit card versus credit card debate; if you have the money you can pay for it upfront and never worry about it again. If you don’t have the money but need it now, then credit is the answer – and the associated continued costs. For start-ups, a perceived low-cost model is ideal at first glance. With that, there’s the downside that you’ll be paying out of your aaS for the rest of your service with them, and moving out of the ecosystem that you thought looked so robust 4 years ago will give the sys admin that you have to hire in to fix it nightmares. Cost is a difficult thing to balance, but there’s still companies still happily running on SQL Server 2005 without any problems; a high upfront cost normally means that it’s going to stick around for ages (you’ll make it work!). To be honest, for most small businesses, investment in a developer who can stitch together open source technologies to suit your needs will be better than running to the closest spangly Service provider. However, aaS does mean you don’t need System Administrators stressing about ORM-generated queries. 2. Ownership of data An under-discussed but vital issue that lies behind the aaS movement is the ownership of data, and what this means to companies. How secure are the bank details of your clients? How does the aaS provider secure against attacks? Where does this fit in terms of compliance? To me, the risks associated with giving your data for another company to keep is too high to justify, even if it’s backed up by license agreements and all types of unhackable SSL things (#Heartbleed). After all, a bank is more appealing to thieves than a safe behind a picture in your living room. Probably*. As a company, regardless of size, your integrity is all. I think you should own that. 3. The Internet as kingmaker We once had an issue at the Packt office where, during a desk move, someone plugged an Internet cable (that’s the correct term for them, right?) from one port to another, rather than into their computer. The Internet went down for half the day without anyone really knowing what was going on. Luckily, we still had local access to stuff – chapters, databases, schedules, and so on. If we were fully bought into the cloud we would have lost a collective 240 man hours from one office because of an honest mistake. Using the Internet as your only connection point to the data you work with can, and will, have consequences for businesses who work with time-critical pieces of data. This leaves an interesting space open that, as far as I’m aware, very few “as a Service” providers have explored; hybrid cloud. If the issue, basically, is the Internet and what cloud storage means to you operationally and in terms of data compliance, then a world where you can keep sensitive and “critical” data local while keeping bulk data with your cloud provider, then you can leverage the benefits of both worlds. The advantages of speed and lack of overheads would still be there, as well as the added security of knowing that you’re still “owning” your data and your brand reputation. Hybrid clouds generally seem to be an emergent solution in the market at large. There are even solutions now on Kickstarter that provide you with a “cloud” where you own your data. Lovely. Hell, you can even make your own PaaS with Chef and Docker. I could go on. The quite clear popularity of “as a Service” products means there’s value in the services they’re offering. At the moment though, there’s enough problems inherent in adoption to believe that they’re a stop-gap to something more finite. The future, I think, lies away from the black and white of aaS and on-premises software. There’s advantages in both, and as we continue to develop services and solutions that blend the two, I think we’re going to end up at a more permanent solution to the argument. *I don’t actually advocate the safe behind a picture method. More of a loose floorboard man myself. From 4th-10th April, save 50% on 20 of out top cloud titles. From AWS to Azure and OpenStack - and even Docker for good measure - learn how to build the services of tomorrow. If one isn't enough, grab 5 for just $50! Find them here.

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.

Pornography is one of, if not, the most common forms of media on the Internet, if you go by the number of websites or amount of data transferred. Despite this fact, Internet pornography is rarely discussed or written about in positive terms. This is somewhat unexpected, given that pornography has spurned many technological advances throughout its history. Many of the advances in video capture and display were driven by the need to make and display pornography better. The desire to purchase pornography on the Internet with more anonymity was one of the ways PayPal drew, and continues to draw, customers to its services. This blog will look into some of the tools being used by some of the more popular Internet pornography sites today. We will be examining the HTML source for some of the largest websites in this industry. The content of this blog will not be explicit, and the intention is not titillation. YouPorn is one of the top 100 accessed websites on the Internet; so, I believe it is relevant to have a serious conversation about the technologies used by these sites. This conversation does not have to be explicit in anyway, and it will not be. Much of what is in the <head> tag in the YouPorn HTML source is related to loading assets, such as stylesheets. After several <meta> tags, most designed to enhance the website’s SEO, a very large chunk of JavaScript appears. It is hard to say, at this point, whether or not YouPorn is using a common frontend framework, or if this JavaScript was wholly written by a developer somewhere. It certainly was minified before it was sent to the frontend, which is the least you would expect. This script does a variety of things. It handles that lovely popup that occurs as soon as a viewer clicks anywhere on the page; this is handled with vanilla JavaScript. The script also collects a large amount of information about the viewer’s viewing device. This includes information about the operating system, the browser, the device type, device brand, and even some information about the CPU. This information is used to optimize the viewer’s experience. The script also identifies whether or not the viewer is using AdBlock, and then modifies the page as such. Two third-party tools that are in this script are jQuery and AJAX. These two tools would be very necessary for a website that’s main purpose is the display of pornographic content. This is because AJAX can help expedite the movement of the content from backend to frontend, and jQuery can enhance DOM manipulation in order to improve the viewer’s user interface. AJAX and jQuery can also be seen in the source code of the PornHub website. Again, this is really the least you would expect from a website that serves as much content as any of the porn websites that are currently popular. The source code for these pages show that YouPorn and PornHub both use Google Analytics tools, presumably, to assist in their content targeting. This is a part of how pornography websites begin to grow more and more geared toward a specific viewer over time. PornHub and YouPorn spend a lot of lines of code building what could be considered a profile of their viewers. This way, viewers can see what they want immediately, which ought to enhance their experience and keep them online. xHamster follows a similar template as it identifies information about the user’s device and uses Google Analytics to target the viewer with specific content. Layout and navigation of any website is important. Although pornography is very desirable to some, websites that display it have so many competitors that they must all try very hard to satisfy their viewers. This makes every detail very important. YouPorn and PornHub appear to use BootStrap as the foundation of their frontend design. There is quite a bit of customization performed by the sites, but BootStrap is still in the foundation. Although it is somewhat less clear, it seems that xHamster also uses BootStrap as its design foundation. Now, let’s choose a video and see what the source code tells us about what happens when viewers attempt to interact with the content. On PornHub, there are a series of view previews that, when rolled over, a video sprite appears in order to give the viewer a preview of the video. Once the video is clicked on, the viewer is sent to a new page to view the specific video. In the case of PornHub, this is done through the execution of a PHP script that uses the video’s ID and an AJAX request to get the user onto the right page with the right video. Once we are on the video’s page, we can see that PornHub, and probably xHamster and YouPorn as well, are using Flash Video. I am viewing these websites on a MacBook, so it is likely that the video type is different when viewed on a device that does not support Flash Video. This is part of the reason so much information about a viewer’s device is collected upon visiting these websites. This short investigation into the tools used by these websites has revealed that, although pornographers have been on the cutting edge of web technology in the past, some of the current pornography providers are using tools that are somewhat unimpressive, or at least run of the mill. That being said, there is never a good reason to reinvent the wheel, and these websites are clearly doing fine in terms of viewership. For the aspiring developers out there, I would take it to heart that some of the most viewed websites on the Internet are using some of the most basic tools to provide their users with content. This confirms what I have often found to be true, that is, getting it done right is far more important than getting it done in a fancy way. I have only scratched the surface of this topic. I hope that others will investigate more into the type of technologies used by this very large portion of the modern Internet. Erik Kappelman is a transportation modeler for the Montana Department of Transportation. He is also the CEO of Duplovici, a technology consulting and web design company.

Virtual reality technology is right in the middle of becoming massively available. But it has been considered farfetched—a distant holy grail largely confined to fiction—for long enough that it is still too easy to harbor certain myths: Working within this medium must require a long and difficult journey to pick up a lot of prerequisite expertise. It must exist beyond the power and scope of the web browser, which was not intended for such rich media experiences. Does VR belong in a Web Browser? The Internet is, of course, an astoundingly open and democratic communications medium, operating at an incredible scale. Browsers, considered as general software for delivering media content over the Internet, have steadily gained functionality and rendering power, and have been extraordinarily successful in combining media content with the values of the internet. The native rendering mechanism at work in the browser environment consumes descriptions of: * Structure and content in HTML: simple, static, and declarative * Styling in CSS (optionally embedded in HTML) * Behavior in JavaScript (optionally embedded in HTML): powerful but complex and loosely structured (oddly too powerful in some ways, and abuses such as pop-up ads were originally its most noticeable applications) The primary metaphor of the Web as people first came to know it focused on traveling from place to place along connected pathways, reinforced by terms like "navigate", "explore", and "site". In this light, it is apparent that the next logical step is right inside of the images, videos and games that have proliferated around the world thanks to the web platform, and that this is no departure from the ongoing evolution of that platform. On social media, we share a lot of content, but interact using low-bandwidth channels (limited media snippets—mostly text). Going forward, these will increasingly blend into shared virtual interactions of unlimited sensory richness and creativity. This has existed to a small extent for some time in the realm of first-person online games, and will see its true potential with the scale and generality of the Web and the immersive power of VR. A quick aside on compatibility and accessiblity: the consequence of such a widely available Web is that your audience has a vast range of different devices, as well as a vast range of different sensorimotor capabilities. It is quite relevant when pushing the limits of the platform, and always wise to consider this: how the experience degrades when certain things are missing, and how best to fall back to an acceptable (not broken) variant of the content in these cases. I believe that VR and the Web will accelerate each other's growth in this third decade of the Web, just as we saw with earlier media: images in its first decade and video in its second. Hyperlinks, essential to the experience of the Web, will teleport us from one site to another: this is one of many research avenues that has been explored by eleVR, a pioneering research team led by Vi Hart and funded by Y Combinator Research. Adopted enthusiastically by the Chrome and Firefox browsers, and with Microsoft recently announcing support in its Edge browser, it is fair to say that widespread support for WebVR is imminent. For browsers that are not likely to support the technology natively in the near future (for example, Safari), there is a polyfill you can include so that you can use it anyway, and this is one of the things A-Frame takes care of for you. A-Frame A-Frame is a framework from Mozilla that: Provides a bundle of conveniences that automatically prepares your client-side app environment for VR. Exposes a declarative interface for the composition of modules (aspects of appearance of functionality). Exposes a simple interface for writing your own modules, and encourages sharing and reusability of modules in the A-Frame community. The only essential structural elements are: * <a-scene>, the container * <a-entity>, an empty shell with transform attributes like position, rotation, and scale, but with neither appearance nor behavior. HTML was designed to make web design accessible to non-programmers and opened up the ability for those without prior technical skills to learn to build a home page. A-Frame brings this power and simplicity to VR, making the creation of virtual environments accessible to all regardless of their experience level with 3D graphics and programming. The A-Frame Inspector also provides a powerful UI for VR creation using A-Frame. Example: Visualization Some stars are in fact extremely bright while others appear bright because they are so near (such as the brightest star in the sky, Sirius). I will describe just one possible use of VR to communicate these differences in star distance effectively. Setting the scene: <a-scene> <a-sky color="black"></a-sky> <a-light type="ambient" color="white"></a-light> </a-scene> A default camera is automatically configured for us, but if we want a different perspective we could add and position an <a-camera> element. Using a dataset of stars' coordinates and visual magnitudes, we can plot the brightest stars in the sky to create a simulated sky view (a virtual stellarium), but scaled so as to be able to perceive the distances with our eyes, immediately and intuitively. The role of VR in this example is to hook into our familiar experience of looking around at the sky and our hardwired depth perceptivity. This approach has potential to foster a deeper and more lasting appreciation of the data than numbers in a spreadsheet can, and then abstract one- or two-dimensional depictions can, for that matter. Inside the scene, per star: <a-sphere position="100 120 -60" radius="1" color="white"> The position would be derived from the coordinates of the star, and the radius could reflect the absolute visual magnitude of the star. We could also have the color reflect the spectral range of the star. A-Frame includes basic interaction handlers that work with a variety of rendering modes. While hovering over (or in VR, gazing at) a star, we could set up JavaScript handlers to view more information about it. By clicking on (in VR, pressing the button while gazing at) one of these stars, we could perhaps transform the view by shifting the camera and looking at the sky from that star's point of view. Or we could zoom in to a detailed view of that star, visualizing its planetary system, and so on. Now, if we were to treat this visualization as a possible depiction of abstract data points or concepts, we can represent. For instance, the points in space could be people, and the distance could represent, perhaps, any combination of weighted criteria. You would see with the full power of your vision how near or far others are in terms of these criteria. This simple perspective enables immersive data storytelling, allowing you to examine entities in any given domain space. My team at TWO-N makes heavy use of D3 and React in our work (among many other open source tools), both of which work seamlessly and automatically with A-Frame due to the nature of the interface that A-Frame provides. Whether you're writing or generating literal HTML, or relying on tools to help you manage the DOM dynamically, it's ultimately all about attaching elements to the document and setting their attributes; this is the browser's native content rendering engine, around which the client-side JavaScript ecosystem is built. About the author Paul Dechov is a visualization engineer at [TWO-N].

This started off as an article about building a simple ScrollSpy module. Simplicity got away from me however, so I'll focus on some of the more interesting bits and pieces that make this module tick! You may wish to have the completed code with you as you read this to see how it fits together as a whole - as well as the missing code and logic. Modular applications are those that are "composed of a set of highly decoupled, distinct pieces of functionality stored in modules" (Addy Osmani). By having loose coupling between modules, the application becomes easier to maintain and functionality can be easily swapped in and out. As such, the functionality of our module will be strictly limited to the activation of one element when another is deemed to be viewable by the user. Linking, smooth scrolling, and other features that navigation elements might have, won’t be covered. Let's build a ScrollSpy module! Let's start by defining a new module. Using a chained sequence rather than declaring a variable for the module is preferable so you don't pollute the global scope. This also saves you when other modules have used the same var. 'use strict'; angular.module('ngScrollSpy', []); I'm all about making modules that are dead simple to implement for the developer. We don’t need superfluous parents, attributes, and controller requirements! All we need is: A directive (scrollspyBroadcast) that sits on each content section and determines whether it's been scrolled to (active and added to stack) or not. A directive (scrollspyListen) that sits on each navigation (or whatever) element and listens for changes to the stack—triggering a class if it is the current active element. We'll use a factory (SpyFactory) to deal with the stack (adding to, removing from, and broadcasting change). The major issue with a ScrollSpy module (particularly in Angular) is dynamic content. We could use MutationObservers —but they aren't widely supported and polling is just bad form. Let's just leverage scrolling itself to update element positions. We could also take advantage of $rootScope.$watch to watch for any digest calls received by $rootScope, but it hasn't been included in the version this article will link to. To save every single scrollspyBroadcast directive from calculating documentHeight and window positions/heights, another factory (PositionFactory) will deal with these changes. This will be done via a scroll event in a run block. This is a basic visualization of how our module is going to interact: Adding module-wide configuration By using value, provider, and config blocks, module-wide configuration can be implemented without littering our view with data attributes, having a superfluous parent wrapper, or the developer needing to alter the module file. The value block acts as the default configuration for the module. .value('config', { 'offset': 200, 'throttle': true, 'delay': 100 }) The provider block allows us to expose API for application-wide configuration. Here we are exposing config, which the developer will be able to set in the config block. .provider('scrollspyConfig', function() { var self = this; this.config = {}; this.$get = function() { var extend = {}; extend.config = self.config; return extend; }; return this; }); The user of the ScrollSpy module can now implement a config block in their application. The scrollspyConfig provider is injected into it (note, the injected name requires "Provider" on the end)—giving the user access to manipulate the modules configuration from their own codebase. theDevelopersFancyApp.config(['scrollspyConfigProvider', function(scrollspyConfigProvider) { scrollspyConfigProvider.config = { offset: 500, throttle: false, delay: 100 }; }]); The value and provider blocks are injected into the necessary directive—config being extended upon by the application settings. (scrollspyConfig.config). .directive('scrollspyBroadcast', ['config', 'scrollspyConfig', function(config, scrollspyConfig) { return { link: function() { angular.extend(config, scrollspyConfig.config); console.log(config.offset) //500 ... Updating module-wide properties It wouldn't be efficient for all directives to calculate generic values such as the document height and position of the window. We can put this functionality into a service, inject it into a run block, and have it call for updates upon scrolling. .run(['PositionFactory', function(PositionFactory) { PositionFactory.refreshPositions(); angular.element(window).bind('scroll', function() { PositionFactory.refreshPositions(); }); }]) .factory('PositionFactory', [ function(){ return { 'position': [], 'refreshPositions': function() { this.position.documentHeight = //logic this.position.windowTop = //logic this.position.windowBottom = //logic } } }]) PositionFactory can now be injected into the required directive. .directive('scrollspyBroadcast', ['config', 'scrollspyConfig', 'PositionFactory', function(config, scrollspyConfig, PositionFactory) { return { link: function() { console.log(PositionFactory.documentHeight); //1337 ... Using original element types <a data-scrollspyListen>Some text!</a> <span data-scrollspyListen>Some text!</span> <li data-scrollspyListen>Some text!</li> <h1 data-scrollspyListen>Some text!</h1> These should all be valid. The developer shouldn't be forced to use a specific element when using the scrollspyListendirective. Nor should the view fill with superfluous wrappers to allow the developer to retain their original elements. Fortunately, the template property can take a function (which takes two arguments tElement and tAttrs). This gives access to the element prior to replacement. In this example, transclusion could also be replaced by using element[0].innerText instead. This would remove the added child span that gets created. .directive('scrollspyListen', ['$timeout', 'SpyFactory', function($timeout, SpyFactory) { return { replace: true, transclude: true, template: function(element) { var tag = element[0].nodeName; return '<' + tag + ' data-ng-transclude></' + tag + '>'; }, ... Show me all of it! The completed codebase can be found over on GitHub. The version at the time of writing is v3.0.0. About the Author Patrick Marabeas is a freelance frontend developer who loves learning and working with cutting edge web technologies. He spends much of his free time developing Angular Modules, such as ng-FitText, ng-Slider, and ng-YouTubeAPI. You can follow him on Twitter @patrickmarabeas.

Most businesses don’t have websites... Seriously, it’s true. More than half of all small businesses have no dedicated web space, and those make up the vast majority of all actual enterprises. Despite the talented companies offering affordable services for businesses. Despite every high-traffic business blog and magazine haranguing, cajoling, or gawping in dismay at how stupid this looks to anyone who knows anything about the modern customer. Despite it all, adoption still remains staggeringly low. I could link you to lots of statistics on this but I won’t. I don’t need to – you already know. We’ve all been there. Where’s the nearest fishmonger? Is the florist open after five? Maybe you need a dohicky to make the washing machine connect to the whatsit. So you take a 45 minute round trip to the big hardware store. Later you find out that there was a Google-dodging shop selling the whatsit-dohickies two minutes away from your house. (Go on, ask me how I spent my weekend.) Why is there still such a huge disparity between how customers and businesses behave? Well, let’s look at it from the other side. What can you – yes, you, person with techy acumen – do to help local businesses in a global and virtual world? I’m beginning to think we could change the world in a lunch break simply by being lazier. First, think small - really small There are a lot of fantastic sites out there offering hassle-free website solutions for medium and large businesses. But chances are the store or service you’re going out of your mind trying to track down is really tiny. One man with a van kind of tiny. The number of employees in your average small business in America? Probably three. They’re busy. They have a full workflow already. So why aren’t we offering them the bare-bones solutions they need? Lose the backend A lot of boxed solutions offer a simple CMS even in their most basic standard sites. And I’ll own up to it myself – when my sister needed a website for her start-up and turned to me because I “know e-mail stuff” I groused, complained, and did my sisterly duty with a quick WordPress setup. But here’s the thing – to somebody already out of their element, a CMS is effort to learn and work to maintain. It becomes a hassle and then a point of guilt and resentment. Very quickly it’s a bug, not a feature, as the site’s year-round Christmas greeting remains trapped in a mire of forgotten logins. A lot of businesses know they need a website. What we forget to tell them is that securing their own domain with a basic single page is better than nothing. At least until they’re ready to level up. Embrace the human database E-commerce software offers fantastic options for stock control and listing services. Seriously – it’d make you weep with pride how awesome the things developers have created for business websites are. Carousels, lightboxes, stock-tracking, integration with ordering systems: web developers are so damn clever. Be proud, be inspired. Now put that all aside and embrace the fact that small businesses are more likely to succeed running “LoisDB”.  “Lois” is the woman who has worked there since the start. She answers the phones. She knows where they put that stock that they had to move because it was blocking the door. Lois doesn’t scale and has terrible latency issues around lunchtime. But on the other hand, she’s ahead of the game on natural-language recognition and ad-hoc querying. Ditch the database and make Lois part of your design plan. Which takes us to: The single most important element of any tiny business website When you cut through it all, there’s really only one indispensable element of a tiny business website: It’s the work of a minute to make a responsive button that will ring a business from your mobile device, and yet it is the simplest way to gain all the information you need without fiddling around with any clunky UI or anachronistic Christmas greetings. If you’ve got an extra thirty seconds to spare you could even add a “callto” option for Skype. Let Google do the rest of the work for you Okay, there may be one other crucial element for a bricks and mortar store – a map. So add it to the front (and possibly only) page. But use the Google Maps API and let the search engine that let you down so bitterly in the first place do the hard work. As an extra bonus, Google will also turn up any Twitter feed or Facebook account the business might be running on the side in the same search. Maybe that’s close enough without any need to integrate them at all. The idea of such bad practice might bring you out in hives. It’s not a replacement for good websites. But it’s a way of on-boarding the stubbornly intractable with a bare minimum of effort on everyone’s part. Later we can stir ambitions with words like SEO and dynamic content. For now, if those with the talent and skill were sometimes willing to do a patchy job, we might change the world for the benefit of all customer-kind*. *Me

Sometimes it seems like AngularJS is the only frontend game in town. There are reasons for that. It’s sophisticated, it’s a game-changer for web design that makes things better right now, and the phenomenal rate of adoption has also led to all kinds of innovative integrations. However, when all you have is a directive, every problem starts to look like an ng-, as they say. Now and again, we all like the novelty of change. As the first signs of spring emerge from the snow, our techie fancies lightly turn to thoughts of components. So, like a veritable Sam-I-Am, let me press you to try something you may not have tried before.* Today’s the day to take ReactJS for a test drive. So what’s the deal with React, then? ReactJS was developed by Facebook, then open sourced last year. Lately, it’s been picking up speed. Integrations have improved, and now that Facebook have also open sourced Flux, we’re hearing a lot of buzz about what React can do for your UI design. (Flux is an application pattern. You can read more about its controller-free philosophy at Facebook’s GitHub page.) Like so many things, React isn’t quite a framework and it isn’t quite a library. Where React excels is in generating UI components that refresh with data changes. With disarming modesty, React communicates the smallest changes on the server side to the browser quickly, without having to re-render anything except the part of the display that needs to change. Here’s a quick run through of React’s most pleasing features. (ReactJS also has a good sense of humour, and enjoys long walks along the beach at sunset.) Hierarchical components ReactJS is built around components: the new black of web dev. Individual components bundle together the markup and logic as handy reusable treats. Everyone has their own style when developing their apps, but React’s feel and rhythm encourages you to think in components. React’s components are also hierarchical – you can nest them and have them inherit properties and state. There are those who are adamant that this is the future of all good web-app code. Minimal re-rendering Did you catch my mention of ‘state’ up there? React components can have state. Let the wars begin right now about that, but it brings me to the heart of React’s power. React reacts. Any change triggers a refresh, but with minimal re-rendering. With its hierarchical components, React is smart enough to only ever refresh and supply new display data to the part of the component that needs it, not the entire thing. That’s good news for speed and overhead. Speedy little virtual dom In fact, ReactJS is light in every sense. And it owes a lot of its power to its virtual DOM. Rather than plug into the DOM directly, React renders every change into a virtual DOM and then compares it against the current DOM. If it sees something that needs to be changed in the view, React gets to work on changing just that part, leaving everything else untouched. Fun to write React mixes HTML and JavaScript, so you can refer to HTML elements right there inside your <script>. Yes, okay, that’s ‘fun’ for a given value of fun. The kind where dorks get a little giddy about pleasing syntax. But we’re all in this together, so we might as well accept ourselves and each other. For example, here’s a simple component rendering from an official tutorial: // tutorial1.js var CommentBox = React.createClass({ render: function() {    return (      <div className="commentBox">        Hello, world! I am a CommentBox.      </div>    ); } }); React.renderComponent( <CommentBox />, document.getElementById('content') ); This is JSX syntax, which React uses instead of defining templates within a string. Pretty, right? Reactive charts and pictures With luck, at this point, your coffee has kicked in and you’re beginning to think about possible use cases where React might be a shiny new part of your toolkit. Obviously, React’s going to be useful for anything with lots of real-time activity. As a frontend for a chat client, streaming news, or a dashboard, it’s got obvious powers. But think a little further and you’ll see a world of other possibilities. React can also handle SVG for graphics and charts, with the potential to create dynamic and malleable visualisations even without D3. SEO One last-but-not-least selling point: web apps built with this framework don’t scare the Google Spiders. Because everything’s passed to the client side and into the DOM having already had its shoes shined by the virtual DOM, it’s very easy to make apps legible for search engines as well as for people, allowing your stored data to be indexed and boost your SEO by reflecting your actual content. Give it a shot and do some experimenting. Have you had any wins or unexpected problems with React? Or are you thinking of giving it a whirl for your next app? We’re going to try it out for some in-house data viz, and may possibly even report back. What about you? *Do not try ReactJS with a goat on a boat without taking proper safety precautions. (With a mouse in a house is fine and, indeed, encouraged.)

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.

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.