Tech Guides - Web Development

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.

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.)

  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."

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!

By this point, I’m sure almost everyone has heard of the news about Microsoft’s decision to open source the .NET framework. This blog will cover what the benefits of this decision are for developers and what it means. Remember this is just an opinion and I’m sure there are differing views out there in the wider community. More variety People no longer have to stick with Windows to develop .NET applications. They can choose between operating systems and this doesn’t lock developers down. It makes it more competitive and ultimately, opens .NET up to a wider audience. The primary advantage of this announcement is that .NET developers can build more apps to run in more places, on more platforms. It means a more competitive marketplace, and improves developers and opens them up to one of the largest growing operating systems in the world, Linux. Innovate .NET Making .NET open source allows the code to be revised and rewritten. This will have dramatic outcomes for .NET and it will be interesting to see what developers do with the code as they continually look for new functionalities with .NET. Cross-platform development The ability to cross-develop on different operating systems is now massive. Previously, this was only available with the Mono project, Xamarin. With Microsoft looking to add more Xamarin tech to Visual Studio, this will be an interesting development to watch moving into 2015. A new direction for Microsoft By opening .NET up as open source software, Microsoft seems to have adopted a more "developer-friendly" approach under the new CEO, Satya Nadella. That’s not to say the previous CEO ignored developers, but by being more open as a company, and changing its view on open source, has allowed Microsoft to reach out to communities easier and quicker. Take the recent deal Microsoft made with Docker and it looks like Microsoft is heading in the right direction in terms of closing the gap between the company and developers. Acknowledgement of other operating systems When .NET first came around, around 2002, the entire world ran on Windows—it was the head operating system, certainly in terms of the mass audience. Today, that simply isn’t the case—you have Mac OSX, you have Linux—there is much more variety, and as a result .NET, by going open source, have acknowledged that Windows is no longer the number one option in workplaces.

This month the Meteor framework hit version 1.0. We’ve been waiting to see this for a while here at Packt, and have definitely not been disappointed. Meteor celebrated their launch with a bang – Meteor Day saw old hands and n00bs from around the globe gather together to try out the software and build new things. You might have experienced the reverberations across the Web. Was it a carefully crafted and clever bit of marketing? Obviously. But in Meteor’s case, we can forgive a little fanfare. Maybe you’re jaded and worn out with a barrage of new tools for web development. You should make an exception for Meteor. Maybe JavaScript isn’t your thing, and you don’t have any interest in working with Node on the backend. You should make an exception for Meteor. I’m not trying to shill anything here – every resource I’ll mention in the course of this post is entirely free. I just think the Meteor web application stack is something special. Why does Meteor matter for a modern Web? If you haven’t come across it before, Meteor is a full stack JavaScript framework for the modern Web. It’s agnostic about how you want to structure your app – MVC, MVVM, MVW, stick everything in one folder with filenames such as TestTemplate(2).js –hey, man, you do you! As long as you keep your client and server concerns separate (there are special built-in rules for the client, server, and public folders to help it do its synchronous magic), Meteor won’t judge. The framework’s clarion cry is that creating application software should be radically simple . We all know that the Web looks different now than it did even a couple of years ago. The app is queen. Single-page web apps have made the Internet programmatic and reactive. The proliferation of mobile apps redefining the online path between customers and businesses are moving us even further away from treating the Internet as a static point of reference. “Pages” are a less and less an accurate metaphor for the visualization of our shared digital realm. Today’s Internet is deep, receptive, active, and aware. Given that, it’s hard to argue against making JavaScript app development simpler. Simple doesn’t mean shoddy, or hacky. It comes from thinking about the Web as it exists now and making the right demands of a framework. Meteor.js lives its philosophy – a multi-user, real-time web-app can be put together in a couple of hours with time to spare for pretty UI design and to window shop for packages. Don’t believe me? Try it out for yourself! Throwing down the gauntlet Originally, we wanted to do a Meteor challenge for the staff here in our Birmingham offices. The winner would have gotten something sweet – perhaps an extra turn on the water slide or an exemption from her turn feeding the Packt scorpions. Alas, in the end the obligation to get on with our actual jobs (helping you guys learn software) got in the way of making this happen. So I’m outsourcing the challenge to you, dear reader. Your mission: Download Meteor 1.0. Prototype an app. Use the time left over to feel pleased with yourself. You get extra credit if: The app has a particular appeal for book lovers (like us!) or It contains a good pun If you’re a Linux or Mac user you can get started right away. If you’re on Windows, you’ll need to use a virtual environment, either in your browser or using something like Vagrant. Don’t worry, the Meteor site has tutorials to get you started in a trice. After that, you can check out all kinds of great learning resources made available by the devs and the community. Get started with the official docs and tutorial, then move on to more hardcore tips and tricks at BulletProof Meteor. The more aurally inclined and those of you who like to code while you drive might prefer to check out the Meteor Podcast. (Please do not code while you drive! – The Legal Team.) When you get stuck, hit up the community on the G+ group. Or browse MeteorHelp for a collation of other sources of information. Most importantly, let me know how you get on with it! We’re excited to see what you come up with. Do you see yourself making Meteor part of your workflow in future? Check out our JavaScript Tech Page for more insight into Meteor and full-stack JS development.

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.

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.

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

AngularJS is, like, so 2014. Already the rumblings have started that there are better ways of doing things. I thought it prudent to look into the future to see what libraries are on the horizon for web developers now, and in the future. 5. Famo.us “Animation can explain whatever the mind of man can conceive.” - Walt Disney Famo.us is a clever library. It’s designed to help developers create application user interfaces that perform well; as well, in fact, as native applications. In a moment of spectacular out-of-the-box thinking, Famo.us brings with it its own rendering engine to replace the engine that browsers supply. To get the increase in performance from HTML5 apps that they wanted, Famo.us looked at which tech does rendering best, namely game technologies, such as Unity and Unreal Engine.  CSS is moved into the framework and written in JavaScript instead. It makes transformations and animations quicker. It’s a new way of thinking for web developers, so you best dust off the Unity Rendering tutorials… Famo.us makes things running in the browser as sleek as they’re likely to be over the next few years, and it’s massively exciting for web developers. 4. Ractive “The meeting of two personalities is like the contact of two chemical substances: if there is any reaction, both are transformed.” - Carl Jung Manipulating the Document Object Model (which ties together all the webpages we visit) has been the major foe of web developers for years. Mootools, YUI, jQuery, AngularJS, Famo.us, and everything between have offered developers productivity solutions to enable them to manipulate the DOM to their client’s needs in a more expedient manner. One of the latest libraries to help DOM manipulators at large is Ractive.js, developed by the team at The Guardian (well, mainly one guy – Rich Harris). Its focus remains on UI, so while it borrows heavily from Angular (it was initially called AngularBars), it’s a simpler tool at heart. Or at least, it approaches the problems of DOM manipulation in as simple a way as possible. Ractive is part of the reactive programming direction that JavaScript (and programming, generally) seems to be heading in at the moment. 3. DC.js “A map does not just chart, it unlocks and formulates meaning; it forms bridges between here and there, between disparate ideas that we did not know were previously connected.” ― Reif Larsen, The Selected Works of T.S. Spivet DC.js, borrowing heavily from both D3 and Crossfilter, enables you to visualize linked data through reactive (a theme developing in this list) charts. I could try and explain the benefits in text, but sometimes, it’s worth just going to have a play around (after you’ve finished this post). It uses D3 for the visualization bit, so everything’s in SVG, and uses Crossfilter to handle the underlying linkage of data. For a world of growing data, it provides users with immediate and actionable insight, and is well worth a look. This is the future of data visualization on the web. 2. Lo-dash "The true crime fighter always carries everything he needs in his utility belt, Robin." - Batman There’s something appealing about a utility belt; something that’s called to all walks of life, from builders to Batman, since man had more than one tool at his disposal. Lo-dash, and Underscore.js that came before it, is no different. It’s a library of useful JavaScript functions that abstract some of the pain away of JS development, whilst boosting performance over Underscore.js. It’s actually based around Underscore, which at the time of writing is the most depended upon library used in Node, but builds on the good parts, and gets rid of the not so good. Lo-dash will take over from Underscore in the near future. Watch this space. 1. Polymer “We are dwarfs astride the shoulders of giants. We master their wisdom and move beyond it. Due to their wisdom we grow wise and are able to say all that we say, but not because we are greater than they.” - Isaiah di Trani As with a lot of things, rather than trying to reinvent solutions to existing problems, Google is trying to just reinvent the things that lead to the problem. Web Components is a W3 standard that’s going to change the way we build web applications for the better, and Polymer is the framework that allows you to build these Web Components now. Web Components envision a world where, as a developer, you can select a component from the massive developer shelf of the Internet, call it, and use it without any issues. Polymer provides access to these components; UI components such as a clock – JavaScript that’s beyond my ability to write at least, and a time-sink for normal JS developers – can be called with: <polymer-ui-clock></polymer-ui-clock> Which gives you a pretty clock that you can actually go and customize further if you want. Essentially, they put you in a dialog with the larger development world, no longer needing to craft solutions for your single project; you can use and reuse components that others have developed. It allows us to stand on the shoulders of giants. It’s still some way off standardization, but it’s going to redefine what application development means for a lot of people, and enable a wider range applications to be created quickly and efficiently. “There's always a bigger fish.” - Qui-Gon Jin There will always be a new challenger, an older guard, and a bigger fish, but these libraries represent the continually changing face of web development. For now, at least!

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.

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.