Tech Guides - Web Development

Static sites are back and stronger than ever. A large number of businesses have realized the importance of sticking to trendy, beautiful, static websites which have less hassle of server maintenance and security exploits. For example, Nest and MailChimp, prominent design companies, are using static site generators for their primary websites. Vox Media has built an entire publishing system around Middleman static site generator. A static website contains Web pages coded in HTML, with fixed content, so they look same to every user. These websites are made using static site generators, which automate the process of creating websites, with minimal coding required from developers. If you’re looking to implement static sites in your next business project, we have compiled a list of the top 5 static site generators to help you design interactive and fast websites. Before we dive in, first let’s understand when choosing static sites makes sense. Why choose static sites? Static sites typically take the content stored in flat files as opposed to dynamic sites where databases serve as content stores. This content is applied against templates and is used to generate a structure of static HTML files. These static files function as the website for the users. Agreed, they lack real-time content and have limited functionalities. But these static sites come in real handy when you want to avoid the hassle of server maintenance while also keeping your pocket light. Not to mention, they are the best option available when your product doesn’t require timely upgrades. Another important factor which contributes to their popularity is the ability to be indexed easily by Google search engines. Since Google has indicated site speed to be one of the signals used to rank pages, static sites have truly shined through. With pure HTML static websites, you have total control over your SEO, and the HTML and CSS are fully understood by search engines. Unlike dynamic websites, you don’t need a special plugin to manage your SEO or need to optimize page load time. Static sites are fast loading, secure, and most importantly, well prepared for traffic surges. This is why their popularity is only surging with the growth of publishing content online. Now that I have ignited your interest to make your next website static, let’s look at some frameworks for building these sites. Static site generators have exploded in popularity in recent years, with a total of more than 100,000 stars for static website generator repositories. Hence, navigating the wide range of choices can be difficult. Here are my top five picks to get you started. Jekyll: The most mature player Jekyll is perhaps the most mature and popular static site generator (Quite obvious from the Github stars). It is built with Ruby and is typically used for transforming plain texts into static websites and blogs. It takes a directory filled with text files, renders that content with Markdown and Liquid templates, and generates a publish-ready static website. Jekyll comes with a big bonus of being natively supported by GitHub pages. So you can easily deploy your site using GitHub for absolutely free. It also has a huge community and wide array of plugins, making it easier for Wordpress and Drupal developers to import content. Hugo: The fastest player Blazingly fast, Hugo is a static HTML and CSS website generator built around Google’s Go programming language. It is optimized for speed, ease of use, and configurability. As with Jekyll, Hugo takes a directory of text files and templates, albeit written in Go, and generates them into a full HTML website. It is extremely fast with build times less than 1 ms per page It is cross-platform, with easy installation on macOS, Linux, Windows, and more. It renders changes on the fly with LiveReload as you develop. It provides full i18n support for multi-language sites. Hexo: The One-command player Hexo is a powerful framework built with Node.js. It offers super fast rendering even for extremely large sites. Hexo is highly extensible as it offers support for GitHub flavored Markdown and most Octopress plugins. It has a One-command deployment to GitHub Pages, Heroku, and other sites. Hexo also features a powerful plugin system. You can install more plugins for Jade, CoffeeScript plugins and many Jekyll plugins with minor adjustments. Gatsby: The multi-tasker Gatsby is a static site generator for React. It is optimized for speed as it loads only critical parts for fast loading. Once loaded, Gatsby prefetches resources for other pages so that clicking around the site feels incredibly fast. Gatsby.js can also be used to generate static Progressive Web apps. It does automatic routing based on the directory structure. The HTML code is generated server-side and additional code need not be included for configuring the router. Gatsby has a pre-configured Webpack-based build system and allows easy data integration from CMSs, SaaS services, APIs, databases, and file systems. VuePress: The new player VuePress, the new player in town, is a minimalistic static site generator powered by Vue.js. VuePress creates a single-page application with pre-rendered static HTML from a Markdown file. This markdown file is powered by Vue, VueRouter, and Webpack. It is composed of two parts: A theming system A default theme optimized for writing technical documentation. This default theme has a header-based search, customizable navbar and sidebar, optional homepage, auto-generated Github link and Page edit links. VuePress also comes with integrated Google Analytics and multi-language support. Here's a short table summarising all static site generators. Static Site Generator GitHub stars Languages Templates Features Jekyll 34k + Ruby Liquid - Most mature and popular - Supported by GitHub pages - A wide array of Plugins Hugo 25k + Go Go - Extremely fast - Cross-platform - Renders changes on the fly - Full i18n support for multi-language sites. Hexo 22k + Javascript EJS, Pug - Highly extensible - One-command deployment - Powerful plugin system Gatsby 21k + Javascript React - Optimized for speed - Generates static PWA - A pre-configured Webpack-based build system VuePress 7k + (growing fast) Javascript Vue - Theming system - Default theme - Google analytics support - Multi-Language support   Apart from these, you also have Next, GitBook, Nuxt, Pelican, among others as some of the other static site generators to choose from. Before going with your choice of static site generator, you need to first make an informed decision on whether or not a static site is right for your next project. Consider your website needs and the kind of business you’re running. If your website has too much going on, it may be killing your traffic. In such cases having a fast, secure and beautiful static site is much more beneficial than a massive, unwieldy dynamic website. Firefox 60 arrives with exciting updates for web developers: Quantum CSS engine, new Web APIs and more [news] Get ready for Bootstrap v4.1; Web developers to strap up their boots [news] How to create a generic reusable section for a single page based website [tutorial]

Today we will explain what a responsive web design is, how it benefits websites, and what the core concepts are. The topics covered are: Responsive design philosophy, principles, grid & columns Smooth user experience & user friendly website Understanding responsive grid systems Adaptive design and methodologies Elegant mobile experience This article is an excerpt taken from the book, Responsive Web Design by Example, written by Frahaan Hussain. Responsive design philosophy There was a time when most web surfing occurred on a computer with a standard-sized/ratio monitor. It was more than adequate to create websites with a non-responsive layout in mind. But over the last 10 years, there has been an exponential boom of new devices in a plethora of form factors, from mobile phones, tablets, watches and a wide range of screen sizes. This growth has created a huge fragmentation problem, so creating websites with a single layout is no longer acceptable. A website with a lot of content that works great on desktops doesn't work very well on a mobile device that has a significantly smaller screen. Such content is unreadable, forcing the user to zoom in and out constantly. One might try making everything bigger so it looks good on mobiles, but then on a desktop, the content doesn't take advantage of the immense real estate offered by bigger screens. Responsive Web Design is a method that allows the design to respond based on the user's input and environment and thus based on the size of the screen, the device, and its orientation. This philosophy blends elements of flexible grids and layouts, images, and media queries in CSS. Enter Responsive Web Design. This alleviates this problem by allowing developers and designers to create websites that adapt to all screen sizes/ratios. There are various approaches that different websites take, but the core concept is illustrated in the following figure: The preceding figure shows how the same website's layout can be adapted to suit different devices. On the desktop, there is a lot more real estate, so the content is bigger and more can fit on a single row. But, as the screen size shrinks and its orientation changes, the content readjusts itself to accommodate this change. This provides a seamless and elegant experience for the user on all form factors. If you look closely at the preceding figure and at modern websites, you will see a grid that the content conforms to. The grid is used to lay out the content of a website, and both of these elements go hand in hand. This grid system is one of the most important aspects of how Responsive Web Design works. Responsive design principles This section will cover the main principles behind designing responsive websites. Though these aren't set in stone and will change over time, they will provide a great foundation. Should you go Responsive or Adaptive? Responsive designs constantly change website layouts depending on their size and orientation. A single pixel resize will tend to have an effect on the layout, usually not by a lot. Adaptive schemes, on the other hand, have preset layouts, which are loaded depending on the size of the screen. This technique doesn't look as fluid and seamless as do responsive designs. Modern-day Responsive Web Design usually incorporates both methods. Set layouts will be provided, as can be seen in the previous figure. But any changes made to a website's size will have an impact in real time through responsive scaling. What are Breakpoints? Breakpoints are points at which a website's layout is no longer fit for the screen size, device, and/or orientation, and we are able to use different and unique layouts to accommodate the various changes that can occur to screens. When these points occur, the current layout is switched to a more suitable layout. For example, a mobile device in portrait mode will not effectively be able to use a layout that is designed for a widescreen desktop display; this just isn't possible. However, by using breakpoints a single website can serve many screen variations whilst making the website feel like it was designed with the user's current screen, device, and/or orientation in mind. This does not occur when reloading the web page, but content moves around dynamically and is scaled accordingly. Without breakpoints, the website would appear with the same layout on all form factors and browser sizes, which using the example we just mentioned, would not be fit for purpose. These breakpoints usually occur when the width of the browser changes and falls into the category of another more appropriate layout. There are a few fundamentals that should be mentioned regarding the philosophy of Responsive Web Design: Why is screen resolution important for responsive design? This is immensely influential in responsive design. The first thought for many designers is to design based on the resolution of the screen. But modern-day phones have resolutions of 1080p and beyond, which for the most part is still the de facto standard for desktops with some exceptions in 4K and ultrawide displays. This would prevent us from fully targeting all devices, as there is so much crossover in resolutions between devices. That is the reason why pixel density is very important when deciding which layout should be used as a 5-inch 1080p mobile display will be cramming the pixels in a lot closer than a 32-inch 1080p display. They both have the same resolution for the mobile device and they have a significantly higher pixel density, which helps distinguish between the device types. The viewport should also be taken into consideration, which is the user's visible area of a web page. This would allow us to rearrange content based on how much content should be displayed. What are media queries? These are amazing facets within CSS that allow us to actually detect changes in a screen such as its size and an event device type. These are the things used to specify code for a specific layout, such as a mobile or desktop display. You can think of media queries as conditional statements, just as an "if" statement would only run a piece of code if the condition was true. A media query is the same, it's far more limited, but as are many things in CSS. I'm positive you will have used a website and noticed that it looks different on a computer compared to a mobile phone, or even a tablet. This is thanks to the use of breakpoints, which are very similar to conditional statements in other languages such as C++. When a certain condition is met, such as screen size range, or, change in form factor, different CSS is applied to provide a better-suited layout. What are Relative units? Relative units take into account the other content and more specifically the content's size, whereas static units do not and have an absolute value regardless of the amount of content. If relative units are not used then static units would be used, which essentially lays the content using fixed units such as pixels. With this method, a box with a width of 400px on an 800px screen would take half the width. But, if the screen size changes to 300px, the box will now be partially off-screen. Again, this would not provide the reader with that seamless experience, which we aim to provide. The units simply display your content relative to everything else, or, more specifically, the screen size or viewport. This allows us, as creators, to display content consistently. Take the previous example, if we would like to display the box at half the screen width, on an 800px screen the box would be 400px wide, and on a 600px screen the box would be 300px wide. Using percentages we can set the width to 50%, which forces the box to always be half the width of its parent container, making its size relative to the rest of the page's content. Why Maximum and minimum values are important? Scaling our content is greatly dependent on the screen size. But with screens such as ultrawide monitors, scaling the content may make it too big, or even too small, on mobile devices. Using maximum and minimum values, we are able to set upper and lower limits providing us with readable and clear results. What are Nested objects? If we displayed every object individually, we would have to make them all adjust accordingly, but nesting allows us to wrap elements using containers. Nested objects are like a paragraph tag, as they contain text, and any changes made to the paragraph tag, such as its position or color, also affect its contents. Objects nested within each other are affected by any change made to their parent containers. An object can be anything from text and images to HTML tags/elements. Take a look at the following example: In this example, there are four elements—a div, paragraph, span, and image tag. The paragraph, span, and image tags are nested within the div tag. If the div tag's maximum width and background color were changed, this would affect all its child objects/tags. But if we were to make a change to the paragraph tag, such as changing its text color, this would not affect any other sibling tags or its parent tag. It would only have an effect on its contents/objects. So, for example, if a container is moved or scaled, the content within the container is also updated. This is where pixels come in use. You may not always want a container to be displayed 10% from the right as, on mobile devices, 10% equates to a lot of real estate potentially being wasted; you could specify 50px instead for example. Should you go Mobile first or desktop first? You can design a website from a small screen such as a phone and scale it up or go the other way round and design it with a large screen in mind. There is actually no right or wrong answer. Depending on the intended target audience and the website's purpose, this will become clear to you. Usually, considering both angles at the same time is the best route to go down. Most responsive frameworks on the market have been designed with a mobile-first philosophy, but that doesn't mean you cannot use it for a desktop-first design; it is on you as the designer to decide how content should be displayed. Should you use Bitmaps or vectors for your images? Bitmaps are great for images with a lot of detail, such as backgrounds and usually logos. Common bitmap formats include .png and .jpg. But these images can be large in file size and require more bandwidth and time to load. On desktop devices, this isn't too much of a problem, but on mobile devices that are heavily reliant on cellular services that don't always provide unlimited data, this can be problematic. Also, when scaling bitmaps, there is a loss in quality, which results in jagged and blurry images. Vectors, on the other hand, are small in size and don't lose quality when scaling. I know you'll be tempted to scream, "Hail vectors!" at this book, but they do have their drawbacks. They are only useful for simple content such as icons. Also, some older browsers do not fully support vectors. Again there is no "right choice"; depending on the content to be displayed, bitmaps or vectors should be used. Understanding Responsive grids and columns The grid system is one of the universal concepts of Responsive Web Design, regardless of the framework a website is built upon. To put it simply, websites are split into rows and columns, and if an object/element occupies half the number of columns, it will always occupy that many regardless of the screen's size. So an element that occupies 3 of the 12 rows will occupy 25% of the width of its parent container, hence providing a responsive design. This is great for small variations in screen sizes, but when a website is viewed on platforms varying from desktops to mobiles, then breakpoints are introduced as covered previously. Though there is no fixed number of columns that a responsive website should have, 12 is a common number used by some of the most popular and widespread frameworks. A framework in this context is anything built on top of the built-in web features. JavaScript is a web feature, but jQuery is a framework built on top of that to allow easier manipulation of the website using prewritten libraries/code. Though a framework isn't absolutely necessary, neither is using an off-the-shelf web browser. You could create your own, but it would be an immense waste of time, and the case for using a responsive framework is essentially the same. The following is an example of a basic responsive grid: Rows allow us as developers to group content together, though there will be a fixed number of columns, not all columns have to be filled to go to the next row. A new row can be used explicitly, as can be seen in the following example: This may be different to how you have developed websites in the past, but if there is anything you are unsure about don’t worry, as things will become clearer when we start working on projects in future chapters. To summarize, we covered responsive design philosophy and principles that are essential to creating an intuitive user experience. If you have enjoyed this excerpt, check out Responsive Web Design by Example to learn how to build engaging responsive websites. What UX designers can teach Machine Learning Engineers? To start with: Model Interpretability 5 things to consider when developing an eCommerce website Responsive Web Design with WordPress  

Build a product experience strategy around the needs of stakeholders Product experience strategists need to conduct thorough research to ensure that the products being developed and launched align with the goals and needs of the business. Alignment is a bit of a buzzword that you're likely to see in HBR and other publications, but don't dismiss it - it isn't a trivial thing, and it certainly isn't an abstract thing. One of the pitfalls of product experience strategy - and product management more generally - is that understanding the needs of the business isn't actually that straightforward. There's lots of moving parts, lots of stakeholders. And while everyone should be on the same page, even subtle differences can make life difficult. This is why product experience strategists do detailed internal research. It: Helps designers to understand the company's vision and objectives for the product. It allows them to understand what's at stake. Based on this, they work with stakeholders to align product objectives and reach a shared understanding on the goals of design. Once organizational alignment is achieved, the strategist uses research insights to develop a product experience strategy. The research is simply a way of validating and supporting that strategy. The included research activities are: Stakeholder and subject-matter expert (SME) interviews Documents review Competitive research Expert product reviews   Talk to key stakeholders Stakeholders are typically senior executives who have a direct responsibility for, or influence on, the product. Stakeholders include product managers, who manage the planning and day-to-day activities associated with their product, and have a direct decision-making authority over its development. In projects that are important to the company, it is not uncommon for the executive leadership from the chief executive and down to be among the stakeholders due to their influence and authority to the direct overall product strategy. The purpose of stakeholder interviews is to gather and understand the perspective of each individual stakeholder and align the perspectives of all stakeholders around a unified vision around the scope, purpose, outcomes, opportunities and obstacles involved in undertaking a new product development project. Gaps among stakeholders on fundamental project objectives and priorities, will lead to serious trouble down the road. It is best to surfaces such deviations as early as possible, and help stakeholders reach a productive alignment. The purpose of subject-matter experts (SMEs) interviews is to balance the strategic high- level thinking provided by stakeholders, with detailed insights of experienced employees who are recognized for their deep domain expertise. Sales, customer service, and technical support employees have a wealth of operational knowledge of products and customers, which makes them invaluable when analyzing current processes and challenges. Prior to the interviews, the experience strategist prepares an interview guide. The purpose of the guide is to ensure the following: All stakeholders can respond to the same questions All research topics are covered if interviews are conducted by different interviewers Interviews make the best use of stakeholders' valuable time Some of the questions in the guide are general and directed at all participants, others are more specific and focus on the stakeholders specific areas of responsibility. Similar guides are developed for SME interviews. In-person interviews are the best, because they take place at the onset of the project and provide a good opportunity to build rapport and trust between the designer and interviewee. After a formal introduction regarding the purpose of the interview and general questions regarding the person's role and professional experience, the person is asked for their personal assessment and opinions on various topics. Here is a sample of different topics: Objectives and obstacles Prioritized goals for the project What does success look like What kind of obstacles the project is facing, and suggestions to overcome them Competition Who are your top competitors Strength and weaknesses relative to the competition Product features and functionality Which features are missing Differentiating features Features to avoid The interviews are designed to last no more than an hour and are documented with notes and audio recordings, if possible. The answers are compiled and analyzed and the result is presented in a report. The report suggests a unified list of prioritized objectives, and highlights gaps and other risks that have been reported. The report is one of the inputs into the development of the overall product experience strategy. Experts understand product experience better than anyone Product expert reviews, sometimes referred to as heuristic evaluations, are professional assessments of a current product, which are performed by design experts for the purpose of identifying usability and user experience issues. The thinking behind the expert review technique is very practical. Experience designers have the expertise to assess the experience quality of a product in a systematic way, using a set of accepted heuristics. A heuristic is a rule of thumb for assessing products. For example, the error prevention heuristic deals with how well the evaluated product prevents the user from making errors. The word heuristic often raises questions about its meaning, and the method has been criticized for its inherent weaknesses due to the following: Subjectivity of the evaluator Expertise and domain knowledge of the evaluator Cultural and demographic background of the evaluator These weaknesses increase the probability that the outcome of an expert evaluation will reflect the biases and preferences of the evaluator, resulting in potentially different conclusions about the same product. Still, expert evaluations, especially if conducted by two evaluators, and their aligned findings, have proven to be an effective tool for experience practitioners who need a fast and cost-effective assessment of a product, particularly digital interfaces. Jacob Nielsen developed the method in the early 1990s. Although there are other sets of heuristics, Nielsen's are probably the most known and commonly used. His initial set of heuristics was first published in his book, Usability Engineering, and is brought here verbatim, as there is no need for modification: Visibility of system status: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Match between system and the real world: The system should speak the user's language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. User control and freedom: Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Consistency and standards: Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Error prevention: Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. Recognition rather than recall: Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Flexibility and efficiency of use: Accelerators--unseen by the novice user--may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Aesthetic and minimalist design: Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, diagnose, and recover from errors: Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Help and documentation: Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. Every product experience strategy needs solid competitor research Most companies operate in a competitive marketplace, and having a deep understanding of the competition is critical to the success and survival. Here are few of the questions that a competitive research helps addresses: How does a product or service compare to the competition? What are the strength and weaknesses of competing offerings? What alternatives and choices does the target audience have? Experience strategists use several methods to collect and analyze competitive information. From interviews with stakeholder and SMEs, they know who the direct competition is. In some product categories, such as automobiles and consumer products, companies can reverse-engineer competitive products and try to match or surpass their capabilities. Additionally, designers can develop extensive experience analysis of such competitive products, because they can have a first-hand experience with it. With some hi-tech products, however, some capabilities are cocooned within proprietary software or secret production processes. In these cases, designers can glean the capabilities from an indirect evidence of use. The Internet is a main source of competitive information, from the ability to have a direct access to a product online, to reading help manuals, user guides, bulletin boards, reviews, and analysis in trade publications. Occasionally, unauthorized photos or documents are leaked to the public domain, and they provide clues, sometimes real and sometimes bogus, about a secret upcoming product. Social media too is an important source of competitive data in the form of customers reviews on Yelp, Amazon, or Facebook. With the wealth of this information, a practical strategy to surpass the competition and delivering a better experience can be developed. For example, Uber has been a favorite car hailing service for a while. This service has also generated public controversy and had dissatisfied riders and drivers who are not happy with its policies, including its resistance for tips. By design, a tipping function is not available in the app, which is the primary transaction method between the rider, company and, driver. Research indicates, however, that tipping for the service is a common social norm and that most people tip because it makes them feel better. Not being able to tip places riders in an uncomfortable social setting and stirs negative emotions against Uber. The evidence of dissatisfaction can be easily collected from numerous web sources and from interviewing actual riders and drivers. For Uber competitors, such as Lyft and Curb, by making tipping an integrated part of their apps, provides an immediate competitive edge that improves the experience of both riders, who have an option to reward the driver for their good service, and drivers, who benefit from an increased income. This, and additional improvements over the inferior Uber experience, become a part of an overall experience strategy that is focused on improving the likelihood that riders and drivers will dump Uber in their favor. [box type="note" align="" class="" width=""]You read an extract from the book Exploring Experience Design written by Ezra Schwartz. This book will help you unify Customer Experience, User Experience and more to shape lasting customer engagement in a world of rapid change.[/box] 10 tools that will improve your web development workflow 5 things to consider when developing an eCommerce website RESTful Java Web Services Design  

Progressive Web Apps (PWA) are a progression to web apps and native apps. So you get the experience of a native app from a mobile’s browser. They take up less storage space (the pitfall of native apps) and reduce loading time (the main reason why people leave a website). In the past few years, PWA has taken everything that is great about a native app – the functionality, touch gestures, user experience, push notifications – and transferred it into a web browser. Antonio Cucciniello’s article on ‘What is PWA?’ highlights some of their characteristics with details on how they affect you as a developer. Many companies have already started with their PWAs and are reaping benefits of this reliable, fast, and engaging approach. Twitter, for instance, introduced Twitter Lite and achieved 65% increase in pages per session, 75% increase in Tweets sent and 20% decrease in bounce rate. Lancôme has rebuilt their mobile website as a PWA and increased conversions by 17%. Most recently, George.com, a leading UK clothing brand, after upgrading their site to a Progressive Web App, saw a 31% increase in mobile conversion. Still not convinced? Here are 5 reasons why your next app should be a Progressive Web App. PWAs are device-agnostic What this means is that PWAs can work with various systems without requiring any special adaptations. As PWAs are hosted online, they are hyper-connected and work across all devices.  Developers will no longer need to develop multiple apps across multiple mobile platforms meaning huge savings in app development time and effort. PWAs have a Seamless UX The user experience provided by a PWA across different devices is the same. You could use a PWA on your phone,  switch to a tablet and notice no difference. They offer a complete full-screen experience with help from a web app manifest file. Smooth animations, scrolling, and navigation keep the user experience smooth.Additionally, Web push notifications show relevant and timely notifications even when the browser is closed, making it easy to re-engage with users. PWAs are frictionless Native apps take a lot of time to download. With a PWA, users won’t have to wait to install and download the app. PWAs use Service Workers and Javascript separately from the main thread to allow apps to load near instantly and reliably no matter the kind of network connection. Moreover, PWAs have improved app cross-functionality. So switching between apps, and sharing information between them becomes less intrusive. The user experience is faster and more intuitive. PWAs are secure PWAs are secured using HTTPS. HTTPS secures the connection between a PWA and the user-base by preventing intruders from actively tampering with the communications between your PWA and your users’ browsers. It also prevents intruders from being able to passively listen to communications between your PWA and your users. PWAs have better SEO According to a report, over 60 percent of searches now occur on mobile devices. This makes PWA very powerful from an SEO perspective as a simple google search might pull up your website and then launch the visitor into your PWA. PWAs can be indexed easily by search engines, making them more likely to appear in search results. The PWA fever is on and as long as PWAs increase app functionality and offer more offline capabilities, the list of reasons to consider them will only grow. Perhaps even more than a native app. Read More Windows launches progressive web apps… that don’t yet work on mobile 5 things that will matter in web development in 2018  

Concern around GDPR is palpable, but time is running out. It appears that many businesses don’t really know what they’re doing. At his Congressional hearing, Mark Zuckerberg’s notes read “don’t say we’re already GDPR compliant” - if Facebook aren’t ready yet, how could the average medium sized business be? But the truth is that GDPR couldn’t have come at a better time. Thanks in part to the Facebook and Cambridge Analytica scandal, the question of user data and online privacy has never been so audible within public discourse. That level of public interest wasn’t around a year ago. Ultimately, GDPR is the best way to tackle these issues. It forces businesses to adopt a different level of focus - and care - towards its users. It forces everyone to ask: what counts as personal data? who has access to it? who is accountable for the security of that data? These aren’t just points of interest for EU bureaucrats. They are fundamental questions about how businesses own and manage relationships with customers. GDPR is good news for web developers In turn, this means GDPR is good news for those working in development too. If you work in web development or UX it’s likely that you’ve experienced frustration when working against the requirements and feedback of senior stakeholders. Often, the needs of users are misunderstood or even ignored at the expense of what the business needs. This is especially true when management lacks technical knowledge and makes too many assumptions. At its worst, it can lead down the path of ‘dark patterns’ where UX is designed in such a way to ‘trick’ customers in behaving in a certain way. But even when intentions aren’t that evil, the mindset that refuses to take user privacy - and simple user desires - seriously can be damaging. Ironically, the problems this sort of negligence is causing isn’t just leading to legal issues. It’s also bad for business. That’s because when you engineer everything around what’s best for the business in a crude and thoughtless way, you make life hard for users and customers. This means: Customers simply have a bad experience and could get a better one elsewhere Customers lose trust Your brand is damaged GDPR will force businesses to get out of the habit of lazy thinking. It makes issues around UX, data protection so much more important than it otherwise would be. It also forces businesses to start taking the way software is built and managed much more seriously. GDPR will change bad habits in businesses What GDPR does, then, is it will force businesses to get out of the habit of lazy thinking. It makes issues around UX, data protection so much more important than it otherwise would be. It also forces businesses to start taking the way software is built and managed much more seriously. This could mean a change in the way that developers work within their businesses in the future. Siloes won’t just be inefficient, they might just lead to a legal crisis. Development teams will have to work closely with legal, management and data teams to ensure that the software they are developing is GDPR compliant. Of course, this will also require a good deal of developer training to be fully briefed on the new landscape. It also means we might see new roles like Chief Data Officer becoming more prominent. But it’s worth remembering that for non-developers, GDPR is going to also require much more technical understanding. If recent scandals have shown us anything, it’s that a lot of people don’t fully understand the capabilities that even the smallest organizations have at their disposal. GDPR will force the non-technical to become more informed about how software and data interact - and most importantly how software can sometimes exploit or protect users. GDPR will give developers a renewed focus on the code they write Equally, for developers, GDPR also forces a renewed focus on the code they write. Discussions around standards have been a central point of contention in the open source world for some time. There has always been an unavoidable, quiet tension between innovation and standard compliance. Writing in Smashing Magazine, digital law expert Heather Burns has some very advice on this: "Your coding standards must be preventive as well. You should disable unsafe or unnecessary modules, particularly in APIs and third-party libraries. An audit of what constitutes an unsafe module should be about privacy by design, such as the unnecessary capture and retention of personal data, as well as security vulnerabilities. Likewise, code reviews should include an audit for privacy by design principles, including mapping where data is physically and virtually stored, and how that data is protected, encrypted, and sandboxed." Sure, all of this seems like a headache, but all of this should make life better for users and customers. And while it might seem frustrating to not be able to track users in the way that we might have in the old world, by forcing everyone to focus on what users really want  - not what we want them to want - we’ll ultimately get to a place that’s better for everyone.

What is React.js? React.js is one of the most talked about JavaScript web frameworks in years. Alongside Angular, and more recently Vue, React is a critical tool that has had a big impact on the way we build web applications. But it's hard to find a better description of React.js than the single sentence on the project's home page: A JavaScript library for building user interfaces. It's a library. For building user interfaces. This is perfect because, more often than not, this is all we want. The best part about this description is that it highlights React's simplicity. It's not a mega framework. It's not a full-stack solution that's going to handle everything from the database to real-time updates over web socket connections. We don't actually want most of these pre-packaged solutions, because in the end, they usually cause more problems than they solve. Facebook sure did listen to what we want. This is an extract from React and React Native by Adam Boduch. Learn more here. React.js is just the view. That's it. React.js is generally thought of as the view layer in an application. You might have used library like Handlebars, or jQuery in the past. Just as jQuery manipulates UI elements, or Handlebars templates are inserted onto the page, React components change what the user sees. The following diagram illustrates where React fits in our frontend code. This is literally all there is to React. We want to render this data to the UI, so we pass it to a React component which handles the job of getting the HTML into the page. You might be wondering what the big deal is. On the surface, React appears to be another rendering technology. But it's much more than that. It can make application development incredibly simple. That's why it's become so popular. React.js is simple React doesn't have many moving parts for us to learn about and understand. The advantage to having a small API to work with is that you can spend more time familiarizing yourself with it, experimenting with it, and so on. The opposite is true of large frameworks, where all your time is devoted to figuring out how everything works. The following diagram gives a rough idea of the APIs that we have to think about when programming with React. React is divided into two major APIs. First, there's the React DOM. This is the API that's used to perform the actual rendering on a web page. Second, there's the React component API. These are the parts of the page that are actually rendered by React DOM. Within a React component, we have the following areas to think about: Data: This is data that comes from somewhere (the component doesn't care where), and is rendered by the component. Lifecycle: These are methods that we implement that respond to changes in the lifecycle of the component. For example, the component is about to be rendered. Events: This is code that we write for responding to user interactions. JSX: This is the syntax of React components used to describe UI structures. Don't fixate on what these different areas of the React API represent just yet. The takeaway here is that React is simple. Just look at how little there is to figure out! This means that we don't have to spend a ton of time going through API details here. Instead, once you pick up on the basics, you can spend more time on nuanced React usage patterns. React has a declarative UI structure React newcomers have a hard time coming to grips with the idea that components mix markup in with their JavaScript. If you've looked at React examples and had the same adverse reaction, don't worry. Initially, we're all skeptical of this approach, and I think the reason is that we've been conditioned for decades by the separation of concerns principle. Now, whenever we see things mixed together, we automatically assume that this is bad and shouldn't happen. The syntax used by React components is called JSX (JavaScript XML). The idea is actually quite simple. A component renders content by returning some JSX. The JSX itself is usually HTML markup, mixed with custom tags for the React components. What's absolutely groundbreaking here is that we don't have to perform little micro-operations to change the content of a component. For example, think about using something like jQuery to build your application. You have a page with some content on it, and you want to add a class to a paragraph when a button is clicked. Performing these steps is easy enough, but the challenge is that there are steps to perform at all. This is called imperative programming, and it's problematic for UI development. While this example of changing the class of an element in response to an event is simple, real applications tend to involve more than 3 or 4 steps to make something happen. Read more: 5 reasons to learn React React components don't require executing steps in an imperative way to render content. This is why JSX is so central to React components. The XML-style syntax makes it easy to describe what the UI should look like. That is, what are the HTML elements that this component is going to render? This is called declarative programming, and is very well-suited for UI development. Time and data Another area that's difficult for React newcomers to grasp is the idea that JSX is like a static string, representing a chunk of rendered output. Are we just supposed to keep rendering this same view? This is where time and data come into play. React components rely on data being passed into them. This data represents the dynamic aspects of the UI. For example, a UI element that's rendered based on a Boolean value could change the next time the component is rendered. Here's an illustration of the idea. Each time the React component is rendered, it's like taking a snapshot of the JSX at that exact moment in time. As our application moves forward through time, we have an ordered collection of rendered user interface components. In addition to declaratively describing what a UI should be, re-rendering the same JSX content makes things much easier for developers. The challenge is making sure that React can handle the performance demands of this approach. Performance matters with React Using React to build user interfaces means that we can declare the structure of the UI with JSX. This is less error-prone than the imperative approach to assembling the UI piece by piece. However, the declarative approach does present us with one challenge—performance. For example, having a declarative UI structure is fine for the initial rendering, because there's nothing on the page yet. So the React renderer can look at the structure declared in JSX, and render it into the browser DOM. This is illustrated below. On the initial render, React components and their JSX are no different from other template libraries. For instance, Handlebars will render a template to HTML markup as a string, which is then inserted into the browser DOM. Where React is different from libraries like Handlebars is when data changes, and we need to re-render the component. Handlebars will just rebuild the entire HTML string, the same way it did on the initial render. Since this is problematic for performance, we often end up implementing imperative workarounds that manually update tiny bits of the DOM. What we end up with is a tangled mess of declarative templates, and imperative code to handle the dynamic aspects of the UI. We don't do this in React. This is what sets React apart from other view libraries. Components are declarative for the initial render, and they stay this way even as they're re-rendered. It's what React does under the hood that makes re-rendering declarative UI structures possible. React has something called the virtual DOM, which is used to keep a representation of the real DOM elements in memory. It does this so that each time we re-render a component, it can compare the new content, to the content that's already displayed on the page. Based on the difference, the virtual DOM can execute the imperative steps necessary to make the changes. So not only do we get to keep our declarative code when we need to update the UI, React will also make sure that it's done in a performant way. Here's what this process looks like: When you read about React, you'll often see words like diffing and patching. Diffing means comparing old content with new content to figure out what's changed. Patching means executing the necessary DOM operations to render the new content React.js has the right level of abstraction React.js doesn't have a great deal of abstraction, but the abstractions the framework does implement are crucial to its success. In the preceding section, you saw how JSX syntax translates to the low-level operations that we have no interest in maintaining. The more important way to look at how React translates our declarative UI components is the fact that we don't necessarily care what the render target is. The render target happens to be the browser DOM with React. But this is changing. We're only just starting to see this with React Native, but the possibilities are endless. I personally will not be surprised when React Toast becomes a thing, targeting toasters that can singe the rendered output of JSX on to bread. The abstraction level with React is at the right level, and it's in the right place. The following diagram gives you an idea of how React can target more than just the browser. From left to right, we have React Web (just plain React), React Native, React Desktop, and React Toast. As you can see, to target something new, the same pattern applies: Implement components specific to the target Implement a React renderer that can perform the platform-specific operations under the hood Profit This is obviously an oversimplification of what's actually implemented for any given React environment. But the details aren't so important to us. What's important is that we can use our React knowledge to focus on describing the structure of our user interface on any platform. Disclaimer: React Toast will probably never be a thing, unfortunately.

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

Web development is one part of a larger project. Devs work away in the background to make sure everything put together by designers, copywriters and marketers looks pretty and works well. Throughout each stage of a project, developers have to perform their own tasks efficiently while ensuring other members are kept in the loop. Therefore, any tools that can help improve your agency’s workflow management process and simplify task management are greatly valued. Every developer, as they move through the ranks from junior to senior status, relies on their stack — a collection of go-to tools to help them get stuff done. Here are 10 tools that you might want to incorporate into a stack of your own. Slack Slack is the outstanding platform for team communication. The tool is designed to simplify messaging allowing users to communicate between groups (Slack allows the creation of multiple conversation “channels” that can be used for different departments or certain aspects of a project) and upload files within conversations. Another great thing about the platform is its integration with other apps — over 600 of them, from bots to project management to developer tools. Apps mean you can perform tasks without having to leave the platform, which is a wonderful thing for productivity. Dropbox When it comes to cloud storage, Dropbox stands tall. It was the first major folder syncing platform and — despite obvious competition from the likes of Google Drive, iCloud, OneDrive and the rest — it remains the best. It's simple, secure, reliable, feature-packed, and great for collaboration. For developers that work in teams, across devices or remotely, Dropbox is essential for seamless access to files. Work can easily be shared, teams managed, and feedback provided from within the platform, improving productivity and ensuring tasks stay on track. It’s also one of the few platforms to work across iOS, Android, Windows, Linux and BlackBerry devices, so no one misses out. GitLab GitLab is one of the best Git repository managers around. The open-source platform provides a cloud-based location where development projects can be stored, tested and edited between teams. If you’re working with another dev on your code, this is the best place from which to do it. While GitHub is also popular with developers, GitLab’s additional features like snippet support (for sharing small parts of code without sharing the entire project), Work in Progress (WIP) labelling, project milestones, and authentication levels, as well as its slick user-interface, make it a superior choice. Postman for Chrome Postman is a free Chrome app designed to make testing and creating APIs easy. And it does a brilliant job at it. Hey, 3.5 million devs can’t be wrong! It’s GUI makes defining HTTP requests (and analyzing responses) more pleasant than it has any right to be, which can’t always be said of similar tools.   Use it in your own work, or when collaborating with larger teams. Just make sure you keep Postman handy whenever you’re working with web apps. Trello Trello is a project management tool that’ll help you keep everything in order, and on schedule. There’s nothing flashy about it, but that's its biggest selling point. By arranging tasks into lists and cards, it makes it easy to manage everything from solo projects to large-scale assignments involving multiple (up to 10) team members. Users can tag each other in cards, leave comments, create checklists, and set deadlines. And tasks can also be color coded for easy identification. Give it a try, you’ll be glad you did. Bitbucket The makers of Trello also created Bitbucket, a version control system that promotes collaboration and scales with your business. The best thing about Bitbucket, besides being able to work with team members (wherever in the world they happen to be), is the ability to leave comments directly in the source code — how about that for productivity? What’s more, it also integrates with Slack, so that Bitbucket notifications show up in channels. Clipy Clipy is a clipboard extension for Mac OS. Nothing special about that you might think. But it’s not until you use the tool that you appreciate its true value. Clipy lets you copy multiple plain text and image items to the clipboard, and offers a simple shortcut menu to bring up clipboard history in an instant. It’s simple, unobtrusive, and no other utility comes close. Plus, it’s free! Brackets Brackets is “a modern, open-source text editor that understands web design”. Most text editors are boring, this one isn’t. By using visual tools in the editor, Brackets makes writing and editing code an easier, more aesthetically pleasing task. It’s written in a combination of CSS, HTML and JavaScript, giving anyone looking to hack or extend it, the opportunity to work in a language they’re well versed in. If you work on front-end applications, makes this tool part of your development arsenal. Grunt Grunt is a JavaScript task runner that allows repetitive tasks to be automated. Time-consuming things like compilation, unit testing, and minification can all be automated without interfering with overall workflow, giving you more time to focus on other, more fun, aspects of a project. Grunt boasts hundreds of plugins and continues to grow by the day, giving you the chance to run every boring task you can think of without any effort. It’s a workflow essential! Yeoman Finally, there’s Yeoman, a development stack featuring all the tools you need to build and adapt web apps. Yeoman features three types of tools to make building easy, thus improving productivity. Firstly, the ‘yo’ scaffolding tool puts the, er, scaffolding in place, collating any build tasks and package manager dependencies that you need. Then, the build tool (Grunt) is used for the heavy lifting — building, previewing, and testing, while the package manager manages dependencies, remove the need for you to do that side of things manually. Of course, a web development stack can, and probably will, consist of more than just 10 tools. But by adding the tools listed here to any that you already use, you’ll notice a definite improvement in how efficiently and effectively work gets done.

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

If you have remotely been paying attention to what is going on in the web development space, you know that Node.js has become extremely popular and is many developers’ choice of backend technology. It all started in 2009 by Ryan Dahl. It is a JavaScript runtime that is built on Google Chrome's V8 JavaScript Engine.Over the past couple of years, more and more engineers have moved towards Node.js in many of the their web applications. With plenty of people using it now, how has Node.js changed web development? Scalability Scalability is the one thing that makes Node.js so popular. Node.js runs everything in a single thread. This single thread is event driven (due to JavaScript being the language that it is written with). It is also non-blocking. Now, when you spin up a server in your Node web app, every time a new user connects to the server, that launches an event. That event gets handled concurrently with the other events that are occurring or users that are connecting to the server. In web applications built with other technologies, this would slow down the server after a large amount of users. In contrast, with a Node application, and the non-blocking event driven nature, this allows for highly scalable applications. This now allows companies that are attempting to scale, to build their apps with Node, which will prevent any slowdowns they may have had. This also means they do not have to purchase as much server space as someone using a web app that was not developed with Node. Ease of Use As previously mentioned, Node.js is written with JavaScript. Now, JavaScript was always used to add functionality to the frontend of applications. But with the addition of Node.js, you can now write the entire application in JavaScript. This now makes it so much easier to be a frontend developer who can edit some backend code, or be a backend engineer who can play around with some frontend code. This in turn makes it so much easier to become a Full Stack Engineer. You do not really need to know anything new except the basic concepts of how things work in the backend. As a result, we have recently seen the rise in a full stack JavaScript developer. This also reduces the complexity of working with multiple languages; it minimizes any confusion that might arise when you have to switch from JavaScript on the front end to whatever language would have been used on the backend.  Open Source Community When Node was released, NPM, node package manager, was also given to the public. The Node package manager does exactly what it says on the tin: it allows developers to quickly add and use third party libraries and frameworks in their code. If you have used Node, then you can vouch for me here when I say there is almost always a package that you can use in your application that can make it easier to develop your application or automate a larger task. There are packages to help create http servers, help with image processing, and help with unit testing. If you need it, it’s probably been made. The even more awesome part about this community is that it’s growing by the day, and people are extremely active by contributing the many open source packages out there to help developers with various needs. This increases the productivity of all developers that are using Node in their application because they can shift the focus from something that is not that important in their application, to the main purpose of it. Aid in Frontend Development With the release of Node it did not only benefit the backend side of development, it also benefitted the frontend. With new frameworks that can be used on the frontend such as React.js or virtual-dom, these are all installed using NPM. With packages like browserify you can also use Node’s require to use packages on the frontend that normally would be used on the backend! You can be even more productive and develop things faster on the front end as well! Conclusion Node.js is definitely changing web development for the better. It is making engineers more productive with the use of one language across the entire stack. So, my question to you is, if you have not tried out Node in your application, what are you waiting for? Do you not like being more productive? If you enjoyed this post, tweet about your opinion of how Node.js changed web development. If you dislike Node.js, I would love to hear your opinion as well! 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. 

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.