Tech Guides - Front-End Web Development

It's been a year of change and innovation in web development. We've seen Angular shifting quickly, React rising to dominate, and the surprising success of Vue.js. We've discussed what 'things' will matter in web development in 2018 here, but let's get down to the key tools you might be using or learning. Read what 5 trends and issues we think will matter in 2018 in web development here. 1. Vue.js If you remember back to 2016, the JavaScript framework debate centred on React and Angular. Which one was better? You didn't have to look hard to find Quora and Reddit threads, or Medium posts comparing and contrasting the virtues of one or the other. But in 2017, Vue has started to pick up pace to enter the running as a real competitor to the two hyped tools. What's most notable about Vue.js is simply how much people enjoy using it. The State of Vue.js report reported that 96% of users would use it for their next project. While it's clearly pointless to say that one tool is 'better' than another, the developer experience offered by Vue says a lot about what's important to developers - it's only likely to become more popular in 2018. Explore Vue eBooks and videos. 2.Webpack Webpack is a tool that's been around for a number of years but has recently seen its popularity grow. Again, this is likely down to the increased emphasis on improving the development experience - making development easier and more enjoyable. Webpack, is, quite simply brings all the assets you need in front end development - like JavaScript, fonts, and images, in one place. This is particularly useful if you're developing complicated front ends. So, if you're looking for something that's going to make complexity more manageable in 2018, we certainly recommend spending some time with Webpack. Learn Webpack with Deploying Web Applications with Webpack. 3. React Okay, you were probably expecting to see React. But why not include it? It's gone from strength to strength throughout 2017 and is only going to continue to grow in popularity throughout 2018. It's important though that we don't get caught up in the hype - that, after all, is one of the primary reasons we've seen JavaScript fatigue dominate the conversation. Instead, React's success is dependent on how we integrate it within our wider tech stacks - tools like webpack, for example. Ultimately, if React continues to allow developers to build incredible UI in a way that's relatively stress-free it won't be disappearing any time soon. Discover React content here. 4. GraphQL GraphQL might seem a little left field, but this tool built by Facebook has quietly been infiltrating its way into development toolchains since it was made public back in 2015. It's seen by some as software that's going to transform the way we build APIs. This article explains everything you need to know about GraphQL incredibly well, but to put it simply, GraphQL "is about designing your APIs more effectively and getting very specific about how clients access your data". Being built by Facebook, it's a tool that integrates very well with React - if you're interested, this case study by the New York Times explains how GraphQL and React played a part in their website redesign in 2017. Learn GraphQL with React and Relay. Download or stream our video. 5. WebAssembly While we don't want to get sucked into the depths of the hype cycle, WebAssembly is one of the newest and most exciting things in web development. WebAssembly is, according to the project site, "a new portable size- and load-time-efficient format suitable for the web". The most important thing you need to know is that it's fast - faster than JavaScript. "Unlike other approaches that require plug-ins to achieve near-native performance in the browser, WebAssembly runs entirely within the Web Platform. This means that developers can integrate WebAssembly libraries for CPU-intensive calculations (e.g. compression, face detection, physics) into existing web apps that use JavaScript for less intensive work" explains Mozilla fellow David Bryant in this Medium post. We think 2018 will be the year WebAssembly finally breaks through and makes it big - and perhaps offering a way to move past conversations around JavaScript fatigue.

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

To answer this question, let’s start by defining what exactly JavaScript fatigue is. JavaScript fatigue is best described as viewing the onslaught of new JavaScript tools, frameworks or packages as a relentless stream of shaggy dog stories instead of an endless stream of creativity and enhanced productivity. I must admit, I myself have a serious case of JavaScript fatigue. Anyone who is plugged into the tech world knows that JavaScript has been having a moment since the release of Node.js in 2009. Obviously, JavaScript was not new in 2009. Its monopoly on web scripting had already made it an old hand in the development world, but with the advent of Node.js, JavaScript began to creep out of web browsers into desktop applications and mobile apps. Pretty soon there was the MEAN stack, a web app architecture that allows for the developer to run a web app end-to-end with only JavaScript, and tools like PhoneGap allowing developers to create mobile apps with good old fashioned HTML, CSS and, you guessed it, JavaScript. I think JavaScript fatigue asks the question, should we really be excited about the emergence of ‘new’ tech based on or built for a scripting language that has been in use for almost 30 years? How did JavaScript fatigue happen? Before I answer the title question, let’s discuss how this happened. Obviously, just the creation/emergence of Node.js cannot be considered the complete explanation of JavaScript fatigue. But, when you consider that JavaScript happens to be a relatively ‘easy’ language, and the language that many people start their development journeys with, a new platform that extended the functionality of such a language (Node.js) easily became a catalyst for the JavaScript wave that has been rolling for the last few years. So, the really simple answer is that JavaScript is easy, so a bunch of people are using it. But who cares? Why is it that a bunch of people using a language that most of us already know is a bad thing? To me that sounds a lot like a good thing. The reason this is problematic actually has nothing to do with JavaScript. There is a difference between using a common language because it is productively advantageous and using a common language because of laziness. Many developers are guilty of the latter. And when a developer is lazy about one thing, they’re probably lazy about all the other things as well. Is it fair to blame JavaScript? So why are there so many lazily created frameworks, APIs, web apps and desktop applications created in JavaScript? Is it really fair to blame the language? No it is not fair. People are not really fed up with JavaScript, they’re fed up with lazy developers, and that is nothing new. Outside of literal laziness in the writing of JS code, there is a laziness based around picking the tools to solve problems. I’ve heard it said that web development or any development for that matter is really not about development tools or process, it's about the results. Regular people don’t care what technologies Amazon uses on their website, while everybody cares about using Amazon to buy things or stream videos. There has been a lot of use of JavaScript for the sake of using JavaScript. This is probably the most specific reason people are talking about JavaScript fatigue. When hammering a nail into a board, a carpenter doesn’t choose a screwdriver because the screwdriver is the newest tool in their toolbox, they choose a hammer, because it's the right tool. Sure, you could use the handle of the screwdriver to bang in that nail, and it would basically work, and then you would get to use your new tool. This is clearly a stupid way to operate. Unfortunately, many of the choices made in the development world today are centered on finding the newest JavaScript tool to solve a problem instead of finding the best tool to solve a problem. If developers eat up new tools like candy, other developers are going to keep creating them. This is the downward spiral we find ourselves in. Using technology to solve problems So, why is everyone talking about JavaScript fatigue? Because it is a real problem, and it's getting real annoying. As has been the case before, many developers have become Narcissus, admiring their code in the reflective pool of the Internet, until they turn to stone. Let’s keep an eye on the prize: using technology to solve problems. If JavaScript is used in this way, nobody would have any qualms with the current JavaScript renaissance. It's when we start developing for the sake of developing that things get a little weird.

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

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

Earlier this year, Google and Mozilla released a version of Chrome and Firefox that has full support for WebGL 2.0. While some of the previous versions of their browsers also have support for WebGL 2.0, those versions by default disable the WebGL 2.0 feature. By enabling WebGL 2.0 in their latest browser version, it seems both Google and Mozilla are confident that this bleeding edge web technology can finally be used by most users without any problems.  So, what is WebGL 2.0? How does it differ from the previous version of WebGL? What, in fact, is WebGL?  To answer those questions, let's go back in time a little bit. In the early 1990s, graphics intensive applications were expensive to create because the software had to be customized for each type of graphic processing hardware. Imagine having to write an app for each smartphone vendor separately; it would cost many man hours. So, to mitigate this problem, a standard for graphics computing was introduced. This standard is called OpenGL (which stands for Open Graphics Library).  When mobile phones with display screens were introduced, people realized that mobile technology also needed a standard for graphics computing. However, OpenGL is a standard primarily for desktop-class hardware, so they realized that they would need a different standard that could work with the limited capability of mobile hardware. And thus OpenGL ES (Embedded System) was branched out from OpenGL, and the initial version was released in the early 2000s.  The same progression happened to web technology. In 2009, web applications became increasingly graphic-intensive, so a graphical standard called WebGL was introduced to help software developers. One thing noted, however, was that users could access web applications from both desktop and mobile devices, so WebGL needed to work on both platforms. To accommodate that, WebGL was created based on the OpenGL ES specification instead of the desktop-focused OpenGL.  Technology keeps advancing. As graphics hardware becomes more capable, additional features get added to the graphical standards. The latest version of OpenGL ES, version 3.0, was released in 2012 to keep up with the advancement in mobile GPU. WebGL 1.0, however, was still based on OpenGL ES 2.0. So in 2017, the specification for WebGL 2.0, which was based on OpenGL ES 3.0, was finally released.  As we can see from the timeline, WebGL 2.0 is really fresh out the oven. In fact, it's so new, that at the time of writing this article, the only browsers that support the standards are Google Chrome, Mozilla Firefox, and the Opera browser. WebGL 2.0 support on Safari is still under development. Also, it's worth noting that no mobile browser supports WebGL 2.0 by default (WebGL 2.0 support on Chrome for Android can be enabled via a hidden menu).  Considering the limited number of compatible platforms, as developers, we really can't rely on the user to have the necessary browser for our apps. So, with that limitation in mind, we have to always check for the browser's capability and prepare a fallback method in the event that the browser does not support WebGL 2.0.  So, how does WebGL version 2.0 differ from version 1.0? Fortunately, nothing major has changed with the way the library is used. This latest version of WebGL simply adds additional features and also makes some optional extensions of the library to be included by default.  One of the WebGL 1.0 extensions that have been made mandatory on WebGL 2.0 is the Instancing extension, which enables developers to render multiple copies of the same mesh efficiently. This feature is very useful for drawing decorative objects, like grass. Another extension that has been included in WebGL 2.0 is Depth Texture, which is used a lot for computing lighting and creating shadow maps.  Another major addition to WebGL 2.0 is the support for GLSL 3.0 ES, the latest programming language for the OpenGL shader. With this version of GLSL, a loop in the shader is no longer restricted to a constant integer. Not just that, GLSL 3.0 ES also brings additional matrix operations (like an inverse function) that will make coding a shader much easier.  WebGL 2.0 also offers much better support for textures. With version 2.0, the non-power of 2D textures are finally supported, which means the size of your texture image is no longer limited to 32, 64, 128, 256, and such. 3D textures are also supported now, which is pretty useful for volumetric effects such as light rays and smoke, as well as for storing medical scans.  WebGL 2.0 also adds support for more texture formats such as RGBA32, RGBA16, R11F_G11F_B10F, SRGB8, and others. More compressed texture formats that are not platform-specific are also supported, including: COMPRESSED_RGB8_ETC2, COMPRESSED_RGBA8_ETC2_EAC, and more.  There are other additions to WebGL 2.0, such as Multiple Draw Buffer, Transform Feedback, Uniform Buffer Object, and more. To learn about these and much more, see the official WebGL 2.0 specifications to check out all those additions in detail.  About this author Raka Mahesa is a game developer at Chocoarts: http://chocoarts.com/, who is interested in digital technology in general. Outside of work hours, he likes to work on his own projects, with Corridoom VR being his latest released game. Raka also regularly tweets as @legacy99. 

Experienced web developers reveal what’s needed to get ahead of the curve – and stay there!  We’ve asked eight members of Packt’s author community to weigh in on what developers who are just starting their careers can do to get that competitive edge. These experienced developers have some useful tips for the web devs of tomorrow:  Find your niche and dig in Harold Dost, Principal Consultant at Raastech, recommends that fledgling developers should take time to see what tools are available – these will help you build a strong knowledge foundation and pave the way to becoming an expert. Mapt, a skill learning platform for developers, is one of the best resources out there witha growing library of over 4,000 tech eBooks and video courses. As far as building your skillset goes, Harold says that you should “hone a core skill (maybe two or three), and then diversify on the rest. This will allow you to specialise and give you the in-depth knowledge which will be necessary as you go further in your career.” This doesn’t mean you should just pick a few things and then that’s that for the rest of your career though. You have to be on the lookout for new opportunities and directions to expand your skillset. Haroldagrees, saying that, “at the same time as specialising, be sure to keep learning about new technologies to allow you to grow and improve the work you produce.” Keep learning and start writing Luis Augusto Weir, Oracle ACEDirector and Principal at Capgemini UK, encourages web devs to “be to be passionate about learning and, of course, about coding.” There are so many ways to educate yourself, but he thinks that reading books is still the best thing you can do to further your education. “Reading books is surely a way to get ahead,” Luis says, “as well as lots of other interactive ways to learn like YouTube, blogs, online courses and so on.Not only does a huge amount of effort go into writing books, but nothing beats a good book to read whilst on the train, or bus. Bringing a book with you wherever you go means you’re always equipped to learn.” Adrian Ward, who is an Oracle ACE Associate and runs the Addidici OBIEE consultancy, affirms that in addition to reading, writing was also a crucial part of his education. Adrian says that writing anything, including “blogs, articles, books or presentations,” will give you a better understanding of the topics you are learning and compel you to keep learning new things. “If you’re writing about something, you certainly have to learn about it first!” Belén Cruz Zapata, a Mobile Software Engineer at Groupon, advises developers to “keep learning new thing.”She has first-hand experience with the benefits of blog writing, showing that writing can create opportunities for developers. Belén recounts how she came to write a book for us, saying, “I have a blog that I used to write a review about Android Studio when it was announced for the first time. Packt found my article and contacted me to write a book about it.” Recharge your batteries Sten Vesterli, Senior Principle Consultant at Scott/Tiger, says that as a developer you need “to manage your energy, and find ways to replenish it when it's running low." This is such an important skill that developers need to learn. Stenreasons that “if you have high energy, you can learn any skill and it will remain employable. If you have low energy, you will have a hard time learning something new and will be in danger of being left behind by technological changes.” Every developer will have to figure out their own recharging strategy. Sten says, “I've found that meditation and triathlons work for me, but others will have different things that give them energy.”There is no wrong way to recharge – whether it’s binge watching your favorite show, going for a run, hanging out with friends, or something else – so make sure you block out some time for you to do you. Do what works Phil Wilkins, Senior Consultant at Capgemini, urges graduates and fledgling web devs to challenge both fads and the status quo by thinking critically about the work they are doing and the tools they are using. You need to ensure that you’re not solely using a piece of tech out of habitor prioritizing novelty for novelty’s sake. Make sure that the direction you’re going is relevant and the tools you’re using are the ones best suited for the job. Phil says, “Many will consider me a heretic, but the industry is sometimes a little quick with the next shiny thing and some 'not-invented-here' thinking. I think you should challenge those around you to really understand the tools they’re using, and question whether they’re the right tools to do the job well. Reflecting on what you’re doing and challenging yourself, or being challenged by someone else, to do something better will drive better understanding and insight that can then be applied in later life.” Stay curious; ask questions Phil also advocates for developers to keep their sense of curiosity. He says, “Questioning why something is a good answer to a problem is as important as to how to answer the problem.” Phil adds that “understanding this may not make you a guru, but it will give you a foundation to work with peers in an engaging manner and set you up for future success. Ultimately IT is here to solve problems, and knowing why certain things are good answers rather than that they simply are good answers, means you stand the best chance of developing good solutions.” Network your face off Adrian Ward, who earlier emphasized the importance of writing, has another crucial piece of advice for those getting started with web development. It can be summed up in a single word: Network. You’ve probably heard it a million times already, but networking can really help you get a foot in the door. Many of Packt’s experts confirm that getting out there and connecting with people within your industry is an effective tactic for getting ahead. “Just get involved with the community,” Adrian says. There are so many ways to connect with people these days, so you can start with a method that you’re most comfortable with and then go from there. You can go to events organized by your university or college, go to conferences or local tech meet-ups, or even look for people to connect with on LinkedIn. Apply for jobs that will help you grow Robert van Mölken, Senior Integration and Cloud Specialist for AMIS, advises graduates and fledgling web devs who are looking for jobs to actively seek out employers that invest in their employees. As a developer, this means that the company has training and incentives to keep you up to date with the latest tech and ideas. “Things are changing so fast these days that you can’t sit still if you want to be relevant in two years time," Robert says. "Companies that allow their developers to go to conferences, both locally and further afield, will find that they will learn upcoming skills much faster, going beyond the point of knowledge you can get from investing in and learning from books.” Robert recommends that you, “invest some personal time to experiment with new technologies and IT innovations. Don’t fall behind on stuff just because you are comfortable with what you do every day at work. Find opportunities to speak up, to give presentation about what you learned, and share your experiences. Then you will get noticed, and a world of possibilities will open up to you.” Remember: You’ve got this Sreelatha Sankaranarayanan, Information Developer at IBM, thinks that the young developers of today have generally got it together. She says, “I think they are doing things right. They are willing to learn, explore and experiment. They have fewer inhibitions, are more confident and are willing to go all out. Good luck is all that I would like to say to them.” No developer is an island. Learn from our global author community and enjoy unlimited access to eBooks and Video Courses with a Mapt subscription.

Since React Native[1] came out, the core group of developers, as well as the community, kept on improving its framework, including the performance and stability of the technology. In this article, we talk about React Native's performance. This blog post is aimed at those people who want to learn more about React Native, but it might be a bit too complex for beginners. How does it work? In order to understand how to optimize our application, we have to understand how React Native works. But don't worry; it's not too hard. Let’s take the following piece of code into consideration: st=>start: Javascript e=>end: Natif op=>operation: Bridge st->op->e Let's discuss what it represents. React Native bases itself on two environments: a JS (Javascript) environment and a Native environment. These two entities communicate together with a bridge. The JS is our "organizer." This is where we will run our algorithms, moderate our views, run network calls, and so on. The Native is there for the display and the physical link part. It senses physical events as well as some virtuals if we ask it to do so, and then sends it to the JS part. The bridge exists as a link, as shown in the following code:       render(): ReactElement<*> {     return ( <TextInput           value={''}           onChangeText={() => { /* Here we handle native event */ } />     );  } Here, we simply have a Text Input. Most of the component involves all the branches of the React Native stack. This Text Input is called in JS, but is displayed on the device in Native. Every character typed in the Native component involves the physical event, transforms it in letter or action, and then transmits it by the bridge to the JS component. In all of the transactions of data between JS and Native, the Bridge always intervenes so that the data is included in both parts. The bridge has to serialize the data. The bridge is simple. It's a bit stupid, and it has only one job, but... it is the one that will bother us the most. The Bridge and other losses of performance Bridge Imagine that you are in an airport. You get your ticket online in five minutes; you are already in the plane and the flight will take the time that it's supposed to. However, before that, there's the regulation of the flight—the checking in. It will take horribly long to find the right flight, drop-down your luggage at the right place, go through security and get yourself checked, and so on. Well, this is our Bridge. Js is fast even though it is the main thread. Native is also fast, but the Bridge is slow. Actually, it's more like it has so much data to serialize that it takes it so much time to serialize that he can't improve its performance. Or... It is slow, simply because you made it go slow! The Bridge is optimized to batch the data[2]. Therefore, we can't send it data too fast; and, if we really have to, then we have to minimize to the maximum. Let's take for example an animation. We want to make a square go from left to the right in 10 seconds. The pure JS versions:       /* on top of class */ let i = 0; loadTimer = () => {     if (i < 100) {         i += 1;         setTimeout(loadTimer, 100);     } }; ... componentDidMount(): void {     loadTimer(); } ... render(): ReactElement<*> {     let animationStyle = {         transform: [             {                 translateX: i * Dimensions.get('window').width / 100,             },         ],     };     return ( <View             style={[animationStyle, { height: 50, width: 50, backgroundColor: 'red' }] }         />     ); } Here is an implementation in pure JS of a pseudo animation. This version, where we make raw data go through the bridge, is dirty. It's dirty code and very slow, TO BAN! Animated Version:       ... componentDidMount(): void {     this.state.animatedValue.setValue(0);     Animated.spring(this.state.animatedValue, {         toValue: 1,     }); } ... render(): ReactElement<*> {     let animationStyle = {         transform: [             {                 translateX: this.state.animatedValue.interpolate({                     inputRange: [0, 1],                     outputRange: [0, Dimensions.get('window').width],                 }),             },         ],     };     return ( <Animated.View             style={[animationStyle, { height: 50, width: 50, backgroundColor: 'red' }] }         />     ); } It's already much more understandable. The Animated library has been created to improve the performance of the animations, and its objective is to lighten the use of the bridge by sending predictions of the data to the native before starting the animation. The animation will be much softer and successful with the rightful library. The general perfomance of the app will automatically be improved. However, the animation is not the only one at fault here. You have to take time to verify that you don't have too much unnecessary data going through the bridge. Other Factors Thankfully, the Bridge isn't the only one at fault, and there are many other ways to optimize a React Native application.Therefore, here is an exhaustive list of why and/or how you can optimize your application: Do not neglect your business logic; even if JS and native are supposed to be fast; you have to optimize them. Ban the while or synchronize functions, which takes time in your application. Blocking the JS is the same as blocking the application. The rendering of a view is costly, and it is done most of the time without anything changing! It's why you MUST use the 'shouldComponentUpdate' method in your components. If you do not manage to optimize a JavaScript component, then it means that it would be good to transduce it in Native. The transactions with the bridge should be minimized. There are many states in a React Native application. A debug stage, which is a release state. The release state increases the performance of the app greatly with the flags of compilation while taking out the dev mode. On the other hand, it doesn't solve everything. The 'debugger mode' will slow down your application because the JS will turn on your browser and won't do it on your phone. Tools The React Native "tooling" is not yet very developed, but a great part of the toolset is that itis coming from the application. A hundred percentof the functionality is native. Here is a short list of some of the important tools that should help you out: Tools Platform Description react-addons-perf Both This is a tool that allows simple benchmarks to render components; it also gives the wasted time (the time loss to give the components), which didn't change. Systrace Android This is hard to use but useful to detect big bottlenecks. Xcode iOS This function of Xcode allows you to understand how our application is rendered (great to use if you have unnecessary views). rn-snoopy Both Snoopy is a softwarethatallows you to spy on the bridge. The main utility of this tool is the debug, but it can be used in order to optimize. You now have some more tricks and tools to optimize your React Native application. However,there is no hidden recipeor magic potion...It will take some time and research. The performance of a React Native application is very important. The joy of creating a mobile application in JavaScript must at least be equal to the experience of the user testing it. About the Author Pierre Monge is an IT student from Bordeaux, France. His interests include C, JS, Node, React, React Native, and more. He can be found on GitHub @azendoo. [1]React Native allows you to build mobile apps using only JavaScript. It uses the same design as React, allowing you to compose a rich mobile UI from declarative components. [2]Batch processing

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.

One of the great challenges of JavaScript development has been wrangling your code for both the server- and the client-side of your site or app. Fullstack JS Devs have worked to master the skills to work on both the front and backend, and numerous JS libraries and frameworks have been created to make your life easier. That's why Isomorphic JavaScript is your Next Big Thing to learn for 2017. What even is Isomorphic JavaScript? Isomorphic JavaScript are JavaScript applications that run on both the client and the server-side. The term comes from a mathematical concept, whereby a property remains constant even as its context changes. Isomorphic JavaScript therefore shares the same code, whether it's running in the context of the backend or the frontend. It's often called the 'holy grail' of web app development. Why should I use Isomorphic JavaScript? "[Isomorphic JavaScript] provides several advantages over how things were done 'traditionally'. Faster perceived load times and simplified code maintenance, to name just two," says Google Engineer and Packt author Matt Frisbie in our 2017 Developer Talk Report. Netflix, Facebook and Airbnb have all adopted Isomorphic libraries for building their JS apps. Isomorphic JS apps are *fast*, operating off one base of code means that no time is spent loading and parsing any client-side JavaScript when a page is accessed. It might only be a second - but that slow load time can be all it takes to frustrate and lose a user. But Isomorphic apps are faster to render HTML content directly in browser, ensuring a better user experience overall. Isomorphic JavaScript isn't just quick for your users, it's also quick for you. By utilizing one framework that runs on both the client and the server, you'll open yourself up to a world of faster development times and easier code maintenance. What tools should I learn for Isomorphic JavaScript? The premier and most powerful tool for Isomorphic JS is probably Meteor - the fullstack JavaScript platform. With 10 lines of JavaScript in Meteor, you can do what will take you 1000s elsewhere. No need to worry about building your own stack of libraries and tools - Meteor does it all in one single package. Other Isomorphic-focused libraries include Rendr, created by Airbnb. Rendr allows you to build a Backbone.js + Handlebars.js single-page app that can also be fully rendered on the server-side - and was used to build the Airbnb mobile web app for drastically improved page load times. Rendr also strives to be a library, rather than a framework, meaning that it can be slotted into your stack as you like and gives you a bit more flexibility than a complete solution such as Meteor.

As a web developer, you have to adapt every year to new technologies. In the last four years, the JavaScript world has exploded, and their toolsets are changing very fast. In this blog post, I will describe my experience of changing from a web developer to an app developer. My start in the Mobile App World My first attempt at creating a mobile app was a simple JavaScript one-page app, which was just a website designed for mobile devices. It wasn’t very impressive, but at the time, there was no React-Native or Ionic Framework. It was nice, but it wasn't great. Ionic Framework Later, I developed apps using the Ionic/Angular Framework, which uses Cordova as a wrapper. Ionic apps run in a web-view on the device. To work with Ionic was pretty easy, and the performance increased over time, so I found it to be a good toolset. If you need an app that is running on a broad spectrum of devices, Ionic is a good choice. React-Native A while ago, I made the change to React-Native. React-Native was supported only by iOS at the start, but then it also supported Android, so I thought that the time was right to switch to React-Native. The React-Native world is a bit different than the Ionic world. React-Native is still newish, and many modules are a work-in-progress; so, React-Native itself is released every two weeks with a new version. Working with React-Native is bleeding edge development. React-Native and Firebase are what I use right now. When I was working with Ionic, I was using a SQLite database to cache on the device, and I used Ajax to get data from a remote API. For notifications, I used Google GCM and Pushwoosh, and for uploads, AWS S3. With React-Native, I chose the new Firebase v3, which came out earlier this year. Firebase offers a real-time database, authentication, cloud messaging, storage, analytics, offline data capability, and much more. Firebase can replace all of the third-party tools I have used before. For further information, check out here. Google Firebase supports three platforms: iOS, Android, and the Web. Unfortunately, the web platform does not support offline capabilities, notifications, and some other features. If you want to use all the features Firebase has to offer, there is a React-Native module that is wrapping the IOS and Android native platforms. The JavaScript API module is identical to the Firebase web platform JavaScript API. So, you can use the Firebase web docs on this. Developing with React-Native, you come in touch with a lot of different technologies and programming languages. You have to deal with Xcode, and with Android, you have to add/change the Java code and deal with Gradle, permanent google-service upgrades, and many other things. It is fun to work with React-Native, but it can also be frustrating regarding unfinished modules or outdated documentation on the web. It pushes you into new areas, so you learn Java, Objective-C, or both. So, why not? Firebase V3 Features Let’s look at some of the Firebase V3 features. Firebase Authentication One of the great features that Firebase offers is authentication. They have, ready to go, Facebook login, Twitter login, Google login, Github login, anonymous login, and email/password sign up. OK, to get the Facebook login running, you will still need a third-party module. For Facebook login, I have recently used this module. And, for a Google login, I have recently used this module. Firebase Cloud Messages You can receive notifications on the device, but the differences are depending on the state of the app. For instance, is the app open or closed. Read up here. Firebase Cloud Messages Server You may want to send messages to all or particular users/devices, and you can do this via the FCM Server. I use a NodeJS script as the FCM Server, and I use this module to do so Here. You can read more at Here. Firebase Real-Time Database You can subscribe to database queries; so, as soon as data is changing, your app is getting the new data without a reload. However, you can only call the data once. The real-time database uses web sockets to deliver data. Conclusion As a developer, you have to evolve with technology and keep up with upcoming development tools. I think that mobile development is more exciting than web development these days, and this is the reason why I would like to focus more on app development. About the author Oliver Blumanski is a developer based out of Townsville, Australia. He has been a software developer since 2000, and can be found on GitHub @ blumanski.

Brutalist web design is a somewhat new design philosophy in web development. Brutalist web design is characterised by websites that are intentionally difficult to navigate and use, lack of smooth lines or templates, and hyper-individualization and uniqueness. Some examples of Brutalist websites include the websites for Adult Swim, The Drudge Report, and Hacker News. These and other websites like them are termed ‘Brutalist’ in reference to a mid-20th century architectural movement of the same name. Brutalist buildings use exposed concrete, are modular in design, and choose function over form in most cases. Brutalist buildings are imposing, and can loom menacingly. With this in mind, Brutalist web design is well named. Both styles are appreciated for their economically sound foundations, artistic ‘honesty,’ and anti-elitist undertones. So, that's what Brutalist web design is, but what does Brutalist web design mean for the year 2016 and years to come? In order to answer this question, I think it is good to take a look back at the origins of the Internet. At its core, the Internet is a set of protocols used to seamlessly connect networks with other networks, allowing individuals to instantly share information. One of the fundamental tools for the network of networks is a universal way of displaying information—enter HTML, and eventually CSS. HTML and CSS have held up the design end of the greatest technological renaissance in human history from the years 1993 through present day. Information is displayed in new ways, in new places, and at new speeds. All this took was an incredible amount of work by designers and developers. Today, despite the latest versions of HTML and CSS still being behind the front-end of basically every website on the planet, any web designer looking for a job knows that mastering tools that wrap around HTML and CSS like WordPress, Bootstrap and Sass is more important than improving the ability to hard-code HTML and CSS. WordPress and Bootstrap and tools like them were born of necessity. People began to demand more and more ornate websites as the Internet proliferated, and certain schemas and templates began to become more popular than others. Designers created tools that allowed them to create flashy websites fast, in order to meet demand. The end of this story is the modern Internet—extremely well designed websites that are almost indistinguishable from one another. Brutalist web design is a response to this evolution. Brutalism demands what a website can do be the measure of the website’s value, instead of how it looks. Also, principles of Brutalist web design would suggest that templates are the antithesis to creativity. As someone who has some experience with web design, I understand where Brutalism is coming from. It's difficult when a client is wrapped up in whether or not a menu bounces off the top of the pane as the user scrolls, but shrugs off a site’s ability to change content based on a user’s physical location. That said, is 2016 the beginning of the Brutalist web design revolution? Well I would ask, did the Brutalist architectural movement last? Given that Brutalist buildings were only built for about 20 years, and the age of the Internet moves faster and faster every day, I would suggest that Brutalist web design will likely be unheard of in less than five years. I believe this for two reasons. First, it just seems too much like a fad to not be a fad. Websites that look like they came from the early nineties, websites that are hard to navigate, named after a niche architectural movement from the seventies… This all screams fad to me. Second, people like aesthetics, because people are lazy. Aesthetics themselves are a reflection of our own laziness. We like to be told what to like and what is beautiful. Greco-Roman architecture is still seen around the world after thousands of years, because the aesthetic is pleasing. The smooth lines of buildings like the Guggenheim in New York City or the color and form of Saint Basil's Cathedral in Moscow, show that many people like the meticulous design that is seen in websites like Twitter or FiveThirtyEight, and many others. But, I still haven’t answered the title question. I think that Brutalist web design means that in 2016 we are on the cusp of some real changes in the way that we view and share information. Ubiquitous wearable tech and the ‘Internet of Things’ are just two of the many big changes right around the corner. Brutalism feels like a step sideways rather than a step forward. We may be taking sidesteps, because steps forward are currently indeterminate or difficult. In the simplest terms, Brutalism means that in 2016 some people are trying to break out of a design system that has gotten better, but hasn’t fundamentally changed in over 20 years. Brutalist web design suggests that web design is likely to experience tremendous changes in the near future as the Internet itself changes. Traditional aesthetics will likely endure, but Brutalist web design suggests people are bored and want more. What exactly that is, only time will tell. Author: 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].

We as a society are on the road to mastering a powerful new medium. Even just by dipping your toes into the space of virtual reality, it is easy to find vast unexplored territory and a wealth of potential in this next stage of human communications. As with movies around the turn of the 20th century, there is a mix of elements borrowed from older media, combined with wild experimentation. Thanks to accelerating progress, it will not take too long to home in on the unique essence of immersive virtual worlds. Yet we know there are still so many untapped opportunities around creating, capturing, and delivering these worlds and shaping the experiences inside them. Chris Milk is a pioneer in both the content and technology aspects of virtual reality filmmaking. He produced a short film "Evolution of Verse", available (along with many others) through his company's app Within, that tells a story of the emergence of the VR medium in abstract form. It bravely tests the limits of immersive art, serves as an astounding introductory illustration of the potential for visual effects in virtual reality, and contains an exhilarating homage to the humanity's initial experience of the movies. On the Web—the platform that is the most open, connected, and accessible for both creators and audiences—we now have the opportunity to take our creations across the barrier of limitations established by the format of the screen and the norms of the platform. We can bring along those things that work well on a flat screen, and will come to rethink them as we experiment with the newfound ability of the audience to convincingly perceive our work in the first person. What is Virtual Reality? First, a quick survey of consumer head-mounted displays in rough order of increasing power and price: Mobile: Google Cardboard, Samsung Gear VR, Google Daydream (coming soon) Tethered: Sony PlayStation VR (coming soon), Oculus Rift, HTC Vive It would be helpful to analyze the medium of virtual reality in terms of its various immersive facets: Head-tracking: Most crucially, the angle of your head is mapped in real time to that of the virtual camera. A major hallmark of our visual experience of physical reality is turning your head in order to look around or to face something. This capability is leveraged by the category of 360° videos (note that the name evokes looking around in a circle, but generally you can look up and down as well). This is a radical departure in terms of cinematography, as directing attention via a rectangular frame is no longer an option. Stereoscopy: Seeing depth as a 3rd spatial dimension is a major sensory advantage for perceiving complex objects and local surroundings. Though there is a trade-off between depth perception and perspective distortion, 3D undeniably contributes a sense of presence, and therefore a strong element of immersion. 3D can be compared with stereo sound, which also was looked upon for decades as a novelty and a gimmick before achieving ubiquity in the 1960s (on that note, positional audio is another significant factor in delivering an immersive experience). Isolation: Blocking out ambient light noises and distractions that would dilute the visual experience, akin to noise-blocking or noise-canceling headphones. Motion tracking: Enables so-called "room-scale VR", which allows you to move through virtual environments and around virtual objects. This can greatly heighten the fidelity of experience, and comes with some interesting challenges. This capability is currently only available with the HTC Vive but we will soon see it on mobile, put forward by Google's Project Tango. Button: Works as a mouse click in combination with a cursor in the center of your field of view. Motion-tracked hand controller: Again, this is currently a feature of the HTC Vive only, but Oculus and Google's Daydream will be coming out with controllers, as will PlayStation VR using PlayStation Move controllers. Even fairly basic applications of these controllers like Tilt Brush have immense appeal. Immersive Graphics on the Web There is one sequence of "Evolution of Verse" that is reminiscent of one of my favorite THREE.js demos, of flocking birds. In pursuit of advanced hardware acceleration, this demo uses shaders in order to support the real-time navigation and animation of thousands of birds (i.e. boids) at once. A-Frame is a high-level wrapper around THREE.js that provides a simple, structured interface to immersive 3D graphics. An advanced feature of A-Frame materials allows you to register shaders (a low-level drawing subroutine), and attach these materials to entities. Aside from the material, any number of other components could be added to the entity (lights, sounds, cameras, etc.), including perhaps one that encapsulates the boid navigation logic using a custom component (which are simple to write). A-Frame has great support for importing 3D objects and scenes (downloaded from Sketchfab or clara.io, for instance) using the obj-model and collada-model components. An Asset Management System is also included, for caching and preprocessing assets like models and textures or images and videos. In the future it will also support the up-and-coming glTF standard runtime format for objects and scenes—comparable to the PNG format but for 3D content (with support for animation, however). This piece lives as an external component for now, one of many external resources available as part of the large A-Frame ecosystem. From flocks of birds to the many other techniques explored and validated by the WebGL community, immersive cinematic storytelling on the web has a bright future ahead. During the filming of "The Birds", Alfred Hitchcock found it necessary to insist on literally immersing his lead actress (and surrogate for the audience) in flocks of predatory birds. Perhaps in a more harmless way yet motivated by similar dramatic ambition, creators of web experiences will insist on staging their work to take full advantage of the new paradigm of simulated reality, and it is no longer too early to get started. Image credits: * left: cutestockfootage.com * right: NYT VR app About the author Paul Dechov is a visualization engineer at TWO-N.

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