Tech News - Front-End Web Development

Last week, Anthony Gore, a Vue Community Partner shared what he calls a "knowledge map" capturing the key areas of professional Vue.js development. This map lists key areas you should target if you are planning to develop Vue apps in 2019. The following diagram shows the developer map: Source: Vue.js Developers Basics of JavaScript and web development Vue.js is an open-source JavaScript framework, which is used for building user interfaces. As it is a JavaScript framework, developers need to have a basic understanding of JavaScript and also of web development. Essential concepts New Vue developers should first focus on the following concepts: Core features: To begin with, you will need to know how to install Vue in a web page and understand the lifecycle of a Vue instance. Also, learn key features of the core such as reactive data, directives, and interpolations. Components: Components are reusable and isolated UI elements. Learn how to declare components and communicate between them through props and events. To build robust and scalable applications you need to learn how to compose with components. Single-page applications (SPAs): In the SPA architecture a single web page acts like a traditional multi-page website. After creating the "pages" as components, you can map them to a unique path with Vue Router, a tool for building SPAs. State management: As your app grows, managing global state becomes difficult and components become bloated with props and event listeners. A design pattern called Flux keeps your data in a predictable and stable central store. The Vuex library helps you implement the Flux architecture in your app. Building real-world Vue apps The concepts in the previous part guide you in building apps that are high performing and efficient, but on the local server. To make your apps production ready you need to learn the following concepts: Project scaffolding: As you start building frequently in Vue, you will have to do the similar configurations and setups in many projects. To make this process easier, we have a tool called Vue CLI for quickly scaffolding single page applications. Full-stack/authenticated apps: Often apps in production will have data-driven user interfaces and the data will be sourced from a secure API. These API will be made with Node, Laravel, Rails, Django or some other server framework. So, you should also learn the common design patterns used to integrate Vue into a full-stack configuration. Testing: If you want your apps to be both maintainable and stable, you need to provide tests. For testing, you can utilize a tool called Vue Test Utils that enables you to create and run tests on isolated components. Optimization: Once your app is deployed on a remote server, it will not have the same speed and efficiency that it showed while testing. You need to optimize the app by using a variety of techniques including server-side rendering, async components, and render functions. Commonly used tools Senior developers should be familiar with the key tools that will be part of almost every Vue-based project. Some of these tools are: Modern JavaScript and Babel: To take advantage of new browser capabilities, you can build your apps using the latest JavaScript standard, ES2015, and proposed features from ES2016 and beyond. For supporting older browsers, you can use the tool named Babel. Its function is to transpile (translate and compile) your modern features into standard features. Webpack: If your code is written across different modules, you can use Webpack to build them into a single file that is readable by a browser. It also works as a build pipeline, allowing you to transform code before it is built and can also be used to optimize your app with a series of plugins. TypeScript: As reported in October, Vue 3 will be written entirely in TypeScript. This implies that to contribute and understand inner workings of Vue you will need to understand TypeScript as well. Important frameworks Many frameworks are available to automate common tasks and save time. Some of the most widely used and important ones are: Nuxt.js: This framework provides various cutting-edge features like component-based routing, server-side rendering, and code splitting out-of-the-box. Vuetify: It is a material framework for Vue, which is based on Google’s Material Design Spec. Vuetify provides an easy-to-remember semantic design to quickly build Vue apps with Material Design layout and styling. NativeScript-Vue: If you want to use Vue for native mobile interfaces, you can do so with the NativeScript-Vue framework. NativeScript is a JavaScript framework for building apps using native user interface components on iOS and Android. NativeScript-Vue is built on top of NativeScript, providing use of Vue syntax and components. After learning all these concepts and tools, you can develop plugins, learn about animations, or more advanced concepts like progressive web apps (PWAs). To know more in detail about the Vue knowledge map, check out Mr. Gore’s post. Introducing Vue Native for building native mobile apps with Vue.js React vs. Vue.js: JavaScript framework wars Evan You shares Vue.js 3.0 updates at VueConf Toronto 2018

Google Chrome team finally announced the release date for its Autoplay Policy, earlier this week. The policy had been delayed when it was released with the Chrome 66 stable release, back in May this year. The latest policy change is scheduled to come out along with Chrome 71, in the upcoming month. The Autoplay policy imposes restrictions that prevent videos and audios from autoplaying in the web browser. For websites that want to be able to autoplay their content, the new policy change will prevent playback by default. For most of the sites, playback will be resumed but a small code adjustment will be required in other cases to resume the audio. Additionally, Google has added a new approach to the policy that includes tracking users' past behavior with the sites that have autoplay enabled. So in case, if a user regularly lets an audio play for more than 7 seconds on a website, the autoplay gets enabled for that website. This is done with the help of a “Media Engagement Index” (MEI) i.e. an index stored locally per Chrome profile on a device. MEI tracks the number of visits to a site that includes audio playback of more than 7 seconds long. Each website gets a score between zero and one in MEI, where higher scores indicate that the user doesn’t mind audio playing on that website. For new user profiles or if a user clears their browsing data, a pre-seed list based on anonymized user aggregated MEI scores is used to track which websites can autoplay. The pre-seeded site list is algorithmically generated and only sites with enough users permitting autoplay on that site are added to the list. “We believe by learning from the user – and anticipating their intention on a per website basis – we can create the best user experience. If users tend to let content play from a website, we will autoplay content from that site in the future. Conversely, if users tend to stop autoplay content from a given website, we will prevent autoplay for that content by default”, mentions the Google team. The reason behind the delay The autoplay policy had been delayed by Google after receiving feedback from the Web Audio developer community, especially the web game developer and WebRTC developers. As per the feedback, the autoplay change was affecting many web games and audio experiences, especially on the sites that had not been updated for the change. Delaying the policy rollout gave web game developers enough time to update their websites. Moreover, Google also explored ways to reduce the negative impact of audio play policy on websites with audio enabled. Following this, Google has made an adjustment to its implementation of Web Audio to reduce the number of websites that had been originally impacted. New adjustments made for the developers As per new adjustments by Google in the autoplay policy, audio will get resumed automatically in case the user has interacted with a page and when the start() method of a source node is called. Source node represents individual audio snippets that most games play. One such example is that of a sound that gets played when a player collects a coin or the background music that plays in a particular stage within a game. Game developers call the start() function on source nodes more often than not in cases whenever any of these sounds are necessary for the game. These changes will enable the autoplay in most web games when the user starts playing the game. Google team has also introduced a mechanism for users that allows them to disable the autoplay policy for cases where the automatic learning doesn’t work as expected. Along with the new autoplay policy update,  Google will also stop showing existing annotations on the YouTube videos to viewers starting from January 15, 2019. All the other existing annotations will be removed. “We always put our users first but we also don’t want to let down the web development community. We believe that with our adjustments to the implementation of the policy, and the additional time we provided for web audio developers to update their code, that we will achieve this balance with Chrome 71”, says the Google team. For more information, check out Google’s official blog post. “ChromeOS is ready for web development” – A talk by Dan Dascalescu at the Chrome Web Summit 2018 Day 1 of Chrome Dev Summit 2018: new announcements and Google’s initiative to close the gap between web and native Meet Carlo, a web rendering surface for Node applications by the Google Chrome team

Yesterday, the React team published a roadmap for React 16.x releases. They have split the rollout of new React features into different milestones. The team has made it clear that they have a single vision for how all of these features fit together, but are releasing each part as soon as it is ready, for users to start testing them sooner. The expected milestone React 16.6: Suspense for Code Splitting (already shipped) This new feature can “suspend” rendering while components are waiting for something, and display a loading indicator. It is a convenient programming model that provides better user experience in Concurrent Mode  In React 16.6, Suspense for code splitting supports only one use case: lazy loading components with React.lazy() and <React.Suspense>. React 16.7: React Hooks (~Q1 2019) React Hooks allows users access to features like state and lifecycle from function components. They also let developers reuse stateful logic between components without introducing extra nesting in a tree. Hooks are only available in the 16.7 alpha versions of React. Some of their API is expected to change in the final 16.7 version. Hooks class support might possibly move to a separate package, reducing the default bundle size of React, in future releases. React 16.8: Concurrent Mode (~Q2 2019) Concurrent Mode lets React apps be more responsive by rendering component trees without blocking the main thread. It is opt-in and allows React to interrupt a long-running render to handle a high-priority event. Concurrent Mode was previously referred to as “async mode”. A name change happened to highlight React’s ability to perform work on different priority levels. This sets it apart from other approaches to async rendering. As of now, the team doesn’t expect many bugs in Concurrent Mode, but states that components that produce warnings in <React.StrictMode> may not work correctly. They plan to publish more guidance about diagnosing and fixing issues as part of the 16.8 release documentation. React 16.9: Suspense for Data Fetching (~mid 2019) In the already shipped React 16.6, the only supported use case for Suspense is code splitting. In the future 16.9 release, React will officially support ways to use Suspense for data fetching. The team will provide a reference implementation of a basic “React Cache” that’s compatible with Suspense. Data fetching libraries like Apollo and Relay will be able to integrate with Suspense by following a simple specification. The team  expects this feature to be adopted incrementally, and through layers like Apollo or Relay rather than directly. They also plan to complete two more projects Modernizing React DOM and Suspense for Server Rendering  in 2019. As these projects require more exploration, they aren’t tied to a particular release as of now. For more information, visit the React blog. React Conf 2018 highlights: Hooks, Concurrent React, and more React introduces Hooks, a JavaScript function to allow using React without classes React 16.6.0 releases with a new way of code splitting, and more!

ReX.js is a helper library written in TypeScript for writing Regular Expressions. Yesterday, ReX.js v1.0.0, the first major version was released. Being written in TypeScript, it provides great autocompletion and development experience across various modern code editors. One of the main advantages of using ReX.js is its ability to document every line of code without hassles. Anatomy of  ReX.js v1.0.0 ReX.js is structured as namespace consisting of the following modules: Matcher: It is the class used to construct and use matching expressions. Replacer: The Replacer class is used to construct and use replacement expressions. Operation: This class represents a basic operation that is applied to expressions constructors. Parser: The parser class used to parse and execute Regexps. It is used by Matcher and implements polyfills for named groups and partially for look behinds. ReXer: It is used to construct Regexps. The Matcher and Replacer classes inherit from ReXer. The GitHub page says that the Matcher and Replacer classes will be used more likely by developers. The other classes would more likely be used for extendability and advanced use cases. Advanced use of ReX.js v1.0.0 Beyond basic Regex operations, ReX.js also provides options for extending its functionality. Operations and channels Every method used in ReX.js is just adding a new Operation to ReXer. An Operation can then be stringified using its own stringify method. A concept of channels is introduced to construct linear Regexps from nested function expressions. A channel is simply an array of Operations. The channels themselves are stored as an array in ReXer. Snippets Snippets are available if you want to reuse any kind of Operation configuration. Snippets provide an option to assign the given config to a name for later reuse. Methods and extensions Methods are ways to reuse and apply custom operations while extensions are just arrays of methods. Installing ReX.js v1.0.0 ReX.js is available on NPM as a package. You can include it in your current project by using: npm install @areknawo/rex If you’re using Yarn, then use the following command: yarn add @areknawo/rex For more details and documentation, visit the ReX.js GitHub page. Manipulating text data using Python Regular Expressions (regex) Introducing Howler.js, a Javascript audio library with full cross-browser support low.js, a Node.js port for embedded systems

VueConf Toronto 2018 commenced on November 14th. This a three-day event starting from November 14 to 16. One of the speakers at the event was Evan You, the creator of Vue.js who shared what to expect from the yet to be released Vue 3.0. https://twitter.com/Ionicframework/status/1063244741343629313 Following are some of the updates that were announced at the conference: Faster and maintainable code architecture Vue 3.0 is re-written from the ground up to make its architecture cleaner and more maintainable. To provide better speed some internal functionalities are broken into individual packages in order to isolate the scope of complexity. We can expect 100% faster mounting and patching with this release. Improved slots mechanism Now all compiler-generated slots are functions and invoked during the child component’s render call. The dependencies in slots are collected as dependencies of the child instead of the parent. When slot content changes, only the child is re-rendered. And if the parent re-renders, the child does not have to if its slot content did not change. This change prevents useless re-renders by offering even more precise change detection at the component tree level. Proxy-based observation mechanism Vue 3.0 will come with a Proxy-based observer implementation that provides reactivity tracking with full language coverage. This will eliminate a number of limitations in the current implementation of Vue 2, which is based on Object.defineProperty: Detection of property addition / deletion Detection of Array index mutation / .length mutation Support for Map, Set, WeakMap and WeakSet Tree-shaking friendly The new codebase is tree-shaking friendly. Features such as built-in components and directive runtime helpers can be imported on-demand and tree-shakable. Tree-shakable features also allow the Vue developers to offer more built-in features in future without incurring payload penalties for users that don’t use them. Easily render-to-native with the Custom Renderer API Developers will be able to create custom renderers with the Custom Renderer API. They no longer need to fork the Vue codebase with custom modifications. This will allow easily keeping the render-to-native projects like Weex and NativeScript Vue to stay up-to-date with upstream changes. This API will also make it trivially easy to create custom renderers for various other purposes. In addition to these improvements, it will come with an experimental Hooks API, better warning traces, experimental time slicing support, supports IE11 and improved TypeScript with TSX. Read more about Vue 3.0 updates from the presentation shared by Evan You. Vue.js 3.0 is ditching JavaScript for TypeScript. What else is new? Vue CLI 3.0 is here as the standard build toolchain behind Vue applications React vs. Vue: JavaScript framework wars

Mozilla’s Firefox 63 comes with support for two Web Components: Custom Elements and Shadow DOM. Yesterday, Mozilla shared how these new capabilities and resources are helping web developers to create reusable and modular code. What are Web Components? Web components is a suite of web platform APIs that allow you to create new custom, reusable, and encapsulated HTML tags to use in web pages and web apps. Custom components and widgets built on the Web Component standards work across modern browsers and can be used with any JavaScript library or framework that works with HTML. Let’s discuss the two tent pole standards of Web Components v1: Custom Elements Custom Elements, as the name suggests, allows developers to create “customized” HTML tags. With Custom Elements, web developers can create new HTML tags, improve existing HTML tags, or extend the components created by other developers. It provides developers a web standards-based way to create reusable components using nothing more than vanilla JS/HTML/CSS. To prevent any future conflicts, all Custom Elements must contain a dash, for example, my-element. The following are the power Custom Elements provides: 1. Earlier, browsers didn’t allow extending the built-in HTMLElement class or its subclasses. You can now do that with Custom Elements. 2. For the existing tags such as a p tag, the browser is aware to map it with the HTMLParagraphElement class. But what happens in the case of Custom Elements? In addition to extending built-in classes, we now have a Custom Element Registry for declaring this mapping. It is the controller of custom elements on a web document, allowing you to register a custom element on the page, return information on what custom elements are registered, and so on. 3. Additional lifecycle callbacks such as connectedCallback, disconnectedCallback, and attributeChangeCallback are added for detecting element creation, insertion to the DOM, attribute changes, and more. Shadow DOM Shadow DOM gives you an elegant way to overlay the normal DOM subtree with a special document fragment that contains another subtree of nodes. It introduces a concept of shadow root. A shadow root has standard DOM methods, and can be appended to as any other DOM node but is rendered separately from a document's main DOM tree. Shadow DOM introduces scoped styles to the web platform. It allows you to bundle CSS with markup, hide implementation details, and author self-contained components in vanilla JavaScript without needing any tools or adhering to naming conventions. The underlying concept of Shadow DOM It is similar to the regular DOM, but differs in two ways: How it's created/used How it behaves in relation to the rest of the page Normally, DOM nodes are created and appended as children of another element. Using shadow DOM, you can create a scoped DOM tree that's attached to the element, but separate from its actual children. This scoped subtree is called a shadow tree. The element to which the shadow tree is attached to is called shadow host. Anything that is added in the shadows becomes local to the hosting element, including <style>. This is how CSS style scoping is achieved by the Shadow DOM. Read more in detail about Web Components on Mozilla’s website. Mozilla introduces new Firefox Test Pilot experiments: Price Wise and Email tabs Mozilla shares how AV1, the new open source royalty-free video codec, works This fun Mozilla tool rates products on a ‘creepy meter’ to help you shop safely this holiday season

At the Chrome Web Summit 2018, Dan Dascalescu, Partner Developer Advocate at Google provided a high-level overview of ChromeOS and discussed Chrome’s core and new features available to web developers. Topics included best practices for web development, including Progressive Web Apps, and optimizing input and touch for tablets while having desktop users in mind. He specified that Chromebooks are convergence machines that run Linux, Android, and Google Play natively without emulation. He explained why ChromeOS can be a good choice for web developers. It not only powers devices from sticks to tablets to desktops, but it can also run web, Android, and now Linux applications. ChromeOS brings together your own development workflow with a variety of form factors from mobiles, tablets, desktop, and browsers on Android and Linux. Run Linux apps on ChromeOS with Crostini Stephen Barber, an engineer on ChromeOS described Chrome’s container architecture which is based on Chrome’s principle of safety, security, and reliability.  By using lightweight containers and hardware virtualization support, Android and Linux code run natively in ChromeOS. Developers can run Linux apps on ChromeOS through Project Crostini. Crostini is based on Debian stable and uses both virtualization and containers to provide security in depth. For now, they are starting out targeting web developers by providing integration features like port forwarding to localhost as a secure origin. They also provide a penguin.linux.test DNS alias, to treat a container like a separate system. For supporting more developer workflows than just web, they are soon providing USB, GPU, audio, FUSE, and file sharing support in upcoming releases. Dan also shared how Crostini is actually used for developing web apps. He demonstrated how you can easily install Linux on your Chromebook. Although Crostini is still in development, most things work as expected. Developers can run IDEs, databases like MongoDB, or MySQL. Anything can be installed with an -apt. It also has a terminal. Dan also mentioned Carlo, which is a Google project that is essentially a helpful node app framework. It provides applications with Chrome rendering capabilities. It uses a locally detected instance of chrome and it connects to your process pipe and then exposes the high-level API to render in Chrome from your NodeScript. If you don’t need low-level features, you can make your app as a PWA which works without a LaunchBar once installed in ChromeOS. Windows Chrome desktop PWA support will be available from Chrome 70+ and Mac from Chrome 72+. Dan also conducted a demo on how to run a PWA. These were the steps: Set up Crostini Install the development environment (node, npm, VSCode) Checkout a PWA (Squoosh) from GitHub Open in VSCode Run the web server Open PWA from Linux and Android browsers He also provided guidance on optimizing forms, handling touch interactions, pointer events, and how to set up remote debugging. What does the future look like for ChromeOS? Chrome team is on improving the desktop PWA support. This includes support for keyboard shortcuts, badging for the launch icon, and link capturing. They are also working on low-latency canvas contexts which are introduced in Chrome 71 Beta. This context uses OpenGLES for rastering, writes directly to the Front Buffer, which bypasses several steps of the rendering process but risks tearing. It is used mainly for high-level interactive apps. View the full talk on YouTube. Day 1 of Chrome Dev Summit 2018: new announcements and Google’s initiative to close the gap between web and native. Meet Carlo, a web rendering surface for Node applications by the Google Chrome team. Google Chrome 70 now supports WebAssembly threads to build multi-threaded web applications.

DuckDuckGo, an internet privacy company, empowers users to seamlessly take control of their personal information online, without any tradeoffs. DuckDuckGo doesn’t store IP addresses and doesn’t create unique cookies. It doesn’t even collect or share any type of personal information. The Improvements Lately, the company came up with some improvements. If you ever happen to search for  DuckDuckGo, you might have come across a "&atb=" URL parameter in the web address at the top of your browser. This parameter allows DuckDuckGo to anonymously  A/B (split) test product changes. To explain this further, let’s take, for example, users in the A group would get blue links and users in the B group would get red links. From this, it would be easier for the team at DuckuckGo to measure how the usage of DuckDuckGo has been impacted by different color links. The team at DuckDuckGo also measures the engagement of specific events on the page (e.g. A misspelling message is displayed, when it is clicked). It allows them to run experiments where they can test different misspelling messages and use CTR (click through rate) to determine the message's efficacy. The requests made for improving DuckDuckGo are anonymous and the information is used only for improving the products. Similar "atb.js" or "exti" requests are made by browser extensions and mobile apps. The browser extensions and mobile apps will only send one type of these requests a day. This means an approximate count of the devices which accessed DuckDuckGo can be known. But this would be done without knowing anything about those devices or the searches made by users. These requests are all fully encrypted, such that nobody else can see them except for DuckDuckGo. There is no personal information attached to the request. So, DuckDuckGo cannot ever tell what individual people are doing since everyone is anonymous. The team has developed systems from scratch, instead of relying on third-party services. This is how they stick to their privacy promise of not collecting and leaking any personal information. This move by the company centered around anonymity might benefit a lot to the company, as data breach incidents on various organizations are trending lately.  With the daily searches crossing the 30 million mark, the company has already experienced 50% growth in the last year. These improvements prove to be cherry on the cake! Could DDG possibly pose a real threat to the leading search engine, Google? Read more about this news on the official website of DuckDuckGo. 10 great tools to stay completely anonymous online Google’s prototype Chinese search engine ‘Dragonfly’ reportedly links searches to phone numbers Google launches a Dataset Search Engine for finding Datasets on the Internet

Yesterday, the W3C GPU for the Web Community Group introduced a new graphics shading language for the WebGPU API called Web High Level Shading Language (WHLSL, pronounced “whistle”). The language extends HLSL to provide better security and safety. Last year, a W3C GPU for the Web Community Group was formed by the engineers from Apple, Mozilla, Microsoft, Google, and others. This group is working towards bringing in a low-level 3D graphics API to the Web called WebGPU. WebGPU, just like other modern 3D graphics API, uses shaders. Shaders are programs that take advantage of the specialized architecture of GPUs. For instance, apps designed for Metal use the Metal Shading Language, apps designed for Direct3D 12 use HLSL, and apps designed for Vulkan use SPIR-V or GLSL. That’s why the WebKit team introduced WHLSL for the WebGPU API. Here are some of the requirements WHLSL aims to fulfill: Need for a safe shader language Irrespective of what an application does, the shader should only be allowed to read or write data from the Web page’s domain. Without this safety insurance, malicious websites can run a shader that reads pixels out of other parts of the screen, even from native apps. Well-specified language To ensure interoperability between browsers, a shading language for the Web must be precisely specified. Also, often rendering teams write shaders in their own custom in-house language, and are later cross-compiled to whichever language is necessary. That is why the shader language should have a reasonably small set of unambiguous grammar and type checking rules that compiler writers can reference when emitting this language. Translatable to other languages As WebGPU is designed to work on top of Metal, Direct3D 12, and Vulkan, the shader should be translatable to Metal Shading Language, HLSL (or DXIL), and SPIR-V. There should be a provision to represent the shaders in a form that is acceptable to APIs other than WebGPU. Performant language To provide an overall improved performance the compiler needs to run quickly and programs produced by the compiler need to run efficiently on real GPUs. Easy to read and write The shader language should be easy to read and write for a developer. It should be familiar to both GPU and CPU programmers. GPU programmers are important clients as they have experience in writing shaders. As GPUs are now popularly being used in various fields other than rendering including machine learning, computer vision, and neural networks, the CPU programmers are also important clients. To learn more in detail about WLHSL, check out WebKit’s post. Working with shaders in C++ to create 3D games Torch AR, a 3D design platform for prototyping mobile AR Bokeh 1.0 released with a new scatter, patches with holes, and testing improvements

Test Pilot is an important part of Mozilla Firefox, and allows Mozilla to test out new features and tools that aim to improve the experience of Firefox users. Yesterday, the organization launched two new Test Pilot projects: Price Wise and Email Tabs. Price Wise allows users to track the price of items online, while Email Tabs makes it easier for people to share links via email. How Price Wise worksEssentially, Price Wise is a price-tracking tool. It allows users to add certain products to a watch list; Price Wise will send notifications when there are changes in price. The extension only works for eBay, Best Buy, Amazon, Walmart, and Home Depot, but there are apparently plans to extend its usage to other retailers and eCommerce sites. As holiday season is approaching, it makes sense for Mozilla to push it out to users. You can try it out here. How Email Tabs works Email Tabs is a tool which helps users to send links via email. Typically, you’d need to copy and paste links into your email, but with Email Tabs, you can share from a whole list of tabs. But that’s not all. Users can also choose how the content should be presented in the email. So, it could be a simple link, a screenshot, or even the full text. At the moment this only works with Gmail, but like Price Wise, Mozilla is looking to extend the roll out. You can try Email Tabs here. Both experiments are available for anybody who is signed up to the Test Pilot program. https://youtu.be/UpRLjTQmkW4 Mozilla previews Send, Color and Side View Mozilla also previewed other experiments that are due for release this year. Send allows you to encrypt and share large files up to 1GB, Color, allows users to customize the look of Firefox, while Side View makes comparison shopping easier, as one can look at two products without having to switch back and forth between two separate web pages. To learn more, visit the Firefox website of Firefox. Mozilla shares how AV1, the new the open source royalty-free video codec, works Mozilla announces WebRender, the experimental renderer for Servo, is now in beta Mozilla funds winners of the 2018 Creative Media Awards for highlighting unintended consequences of AI in society

The 6th Chrome Dev Summit 2018 is being hosted on the 12th and 13th of this month in San Francisco. Yesterday, Day 1 of the summit was opened by Ben Galbraith, the director of Chrome, to talk about “the web platform’s latest advancements and the evolving landscape.” Leading web developers described their modern web experiences as well. Major Chrome Dev Summit 2018 announcements included web.dev, a new developer resource website, and a demonstration of VisBug, a browser-based visual development tool. The summit also included a demo of a new web tool called Squoosh that can downsize, compress, and reformat images. The Chrome Dev Summit 2018 also highlighted some of the browser APIs currently in development, including Web Share Target, Wake Lock, WebHID and more. It also featured a Writable File API currently under development, which would allow web apps to edit local files. New web-based tools and resources web.dev The web.dev resource website provides an aggregation of information for modern Web APIs. It helps users monitor their sites over time to ensure that they can keep their site fast, resilient and accessible. web.dev is created in partnership with Glitch, and has a deep integration with Google’s Lighthouse tool. VisBug Another developer tool VisBug helps developers easily edit a web page using a simple point-and-click and drag and drop interface. This is an improvement over Firebug, Google’s previous tool, which used the website’s source code. VisBug is currently available as a Chrome extension that can be installed from the main Chrome Web Store. Squoosh The Squoosh tool allows you to encode images using best-in-class codecs like MozJPEG, WebP, and OptiPNG. It works cross-browser and offline, and ALL codecs supported even in a browser with no native support using WASM. The app is able to do 1:1 visual comparison of the original image and its compressed counterpart, to help users understand the pros and cons of each format. Closing the gap between web and native Google is also taking initiatives to close the gap between the web and native and make it easy for developers to build great experiences on the open web. Regarding this, Chrome will work with other browser vendors to ensure interoperability and get early developer feedback. Proposals will be submitted to the W3C Web Incubator Community Group for feedback. According to Google, this open development process will be “no different than how we develop every other web platform feature.” The first initiative in this aspect is the writable files API. The Writable Files API Currently, under development, the writable files API is designed to increase the interoperability of web applications with native applications. Users can choose files or directories that a web app can interact with on the native file system. They don’t have to use a native wrapper like Electron to ship their web app. With the Writable Files API, users can create a simple, single file editor that opens a file, allows the user to edit it, and save the changes back to the same file. People were surprised that it was Google who jumped on this process rather than Mozilla which has already implemented version of a lot of these APIs. A hacker news user said, “I guess maybe not having that skin in the game anymore prevented those APIs from becoming standardized? But these are also very useful for desktop applications. Anyways, this is a great initiative, it's about time a real effort was made to close that gap.” Here’s a video playlist of all the Chrome Dev Summit sessions so far. Tune into Google’s livestream to follow the rest of the sessions of the day and watch this space for more exciting announcements. Meet Carlo, a web rendering surface for Node applications by the Google Chrome team. Google Chrome 70 now supports WebAssembly threads to build multi-threaded web applications. #GoogleWalkout demanded a ‘truly equitable culture for everyone’; Pichai shares a “comprehensive” plan for employees to safely report sexual harassment

Yesterday, the Phoenix web framework announced the release of its latest version, Phoenix 1.4. This release includes new features such as an HTTP2 support, improved development experience with faster compile times, new error pages, and local SSL certificate generation. The community also shipped a new and improved Presence javascript API. Features in the Phoenix 1.4.0 phx_new archive via hex The mix phx.new archive can now be installed via hex, for a simpler, versioned installation experience. The existing Phoenix applications will continue to work on Elixir 1.4. However, the new phx.new archive requires Elixir 1.5+. Support HTTP2 by making a small change Thanks to the release of Cowboy 2, Phoenix 1.4 supports HTTP2 with a single line change to mix.exs. One needs to simply add {:plug_cowboy, "~> 2.0"} to their deps and Phoenix will run with the Cowboy 2 adapter. New phx.gen.cert to aid local SSL development Most browsers require connections over SSL for HTTP2 requests, failure of which can cause them to fallback to HTTP 1.1 requests. To aid local development over SSL, Phoenix now includes a new phx.gen.cert task which generates a self-signed certificate for HTTPS testing in development. Faster Development Compilation The new release has improved compilation speeds have improved due to the contributions to plug and compile-time changes. New Development 404 Page Phoenix’s 404 page (in development) now lists the available routes for the originating router, for example: A new UserSocket for connection info Access to more underlying transport information when using Phoenix channels has been a highly requested feature. The 1.4 release now provides a connect/3 UserSocket callback, which can provide connection information, such as the peer IP address, host information, and X-Headers of the HTTP request for WebSocket and Long-poll transports. New  ‘Presence JavaScript API’ A new, backward compatible Presence JavaScript API has been introduced to both resolve race conditions as well as simplify the usage. Previously, multiple channel callbacks against "presence_state” and "presence_diff" events were required on the client which dispatched to Presence.syncState and Presence.syncDiff functions. Now, the interface has been unified to a single onSync callback and the presence object tracks its own channel callbacks and state. To know more about Phoenix 1.4.0 visit its official website. Mojolicious 8.0, a web framework for Perl, released with new Promises and Roles Web Framework Behavior Tuning Beating jQuery: Making a Web Framework Worth its Weight in Code  

Developed by GoldFire Studios, Howler.js is an audio library for the modern web that makes working with audio in JavaScript easy and reliable across all platforms. It defaults to Web Audio API and falls back to HTML5 Audio to provide support for all browsers and platforms including IE9 and Cordova. Originally, it was developed for an HTML5 game engine, but it can also be used just as well for any other audio related function in web applications. Features of Howler.js Single API for all audio needs: It provides a simple and consistent API to make it easier to build audio experiences in your application. Audio sprites: For more precise playback and lower resources. you can define and control segments of files with audio sprites. Supports all codecs: It supports all codecs such as MP3, MPEG, OPUS, OGG, OGA, WAV, AAC, CAF, M4A, MP4, WEBA, WEBM, DOLBY, FLAC. Auto-caching for improved performance: It automatically caches loaded sounds that can be reused on subsequent calls for better performance and bandwidth. Modular architecture: Its modular architecture helps you to easily use and extend the library to add custom features. Which browsers does it support? Howler.js is compatible with the following: Google Chrome 7.0+ Internet Explorer 9.0+ Firefox 4.0+ Safari 5.1.4+ Mobile Safari 6.0+ Opera 12.0+ Microsoft Edge Read more about Howler.js on its official website and also check out its GitHub repository. npm at Node+JS Interactive 2018: npm 6, the rise and fall of JavaScript frameworks, and more InfernoJS v6.0.0, a React-like library for building high-performance user interfaces, is now out The Ember project releases version 3.5 of Ember.js, Ember Data, and Ember CLI

React Conf 2018 was held on October 25-26 in Henderson, Nevada USA. In this conference, the React team introduced Hooks, that allows you to use React without classes. On the second day, they spoke about time slicing, code-splitting, and introduced the React Cache and Scheduler APIs that we will see in the coming releases. Day 1: Unveiling Hooks React conf 2018 was kick-started by Sophie Alpert, Engineering Manager at Facebook. She highlighted that many big companies like Amazon, Apple, Facebook, Google are using React and that there has been a huge increase in npm downloads. React’s primary mission is to allow web developers to create great UIs. This is enabled by these three properties of React: Simplifying things that are difficult Focusing on performance Developer tooling But there are still few limitations in React that need to be addressed to achieve the mission React aims for. It doesn’t provide a stateful primitive that is simpler than class component. One of the earlier solutions to this was Mixins, but it has come to be known for introducing more problems than solving the problems. Here are the three limitations that were discussed in the talk: Reusing logic between multiple components: In React, sharing code is enabled by two mechanisms, which are higher-order components and render props. But to use them you will need to restructure your component hierarchy. Giant components: There are many cases when the components are simple but grow into an unmanageable mess of stateful logic and side effects. Also, very often we see the lifecycle methods ending up with a mix of unrelated logic. This makes it quite difficult to break these components into smaller ones because the stateful logic is all over the place. Confusing classes: Understanding classes in JavaScript is quite difficult. Classes in JavaScript work very differently from how they work in most languages. You have to remember to bind the event handlers. Also, classes make it difficult to implement hot-reloading reliably. In order to solve these problems in React, Dan Abramov introduced Hooks, followed by Ryan Florence demonstrating how to refactor an application to use them. Hooks allows you to “hook into” or use React state and other React features from function components. The biggest advantage is that Hooks don’t work inside classes and let you use React without classes. Day 2: Concurrent rendering in React On day 2 of the React Conf, Andrew Clark spoke about concurrent rendering in React. Concurrent rendering allows developers to invest less time thinking about code, and focus more on the user experience. But, what exactly is concurrent rendering? Concurrent rendering can work on multiple tasks at a time, switching between them according to their priority. With concurrent rendering, you can partially render a tree without committing the result to the DOM. It does not block the main thread and is designed to solve real-world problems commonly faced by UI developers. Concurrent rendering in React is enabled by the following: Time Slicing The basic idea of time slicing is to build a generic way to ensure that high-priority updates don't get blocked by a low-priority update. With time slicing the rendered screen is always consistent and we don’t see visual artifacts of slow rendering causing a poor user experience. These are the advantages time slicing comes with: Rendering is non-blocking Coordinate multiple updates at different priorities Prerender content in the background without slowing down visible content Code-splitting and lazy loading with lazy() and Suspense You can now render a dynamic import as a regular component with the React.lazy() function.  Currently, React.lazy only supports default exports. You can create an intermediate module to re-export a module that uses named exports. This ensures that tree-shaking keeps working and that you don’t pull in unused components. By the time a component renders, we must show some fallback content to the user, for example, a loading indicator. This is done using the Suspense component. It is a way for components to suspend rendering while they load async data. It allows you to pause any state update until the data is ready, and you can add async loading to any component deep in the tree without plumbing all the props and state through your app and hoisting the logic. The latest React 16.6 comes with these two features, that is, lazy and Suspense. Hooks was recently released with React 16.7-alpha. In the coming releases, we will see two new APIs called React Cache and Scheduler. You can watch the amazing demos by the React developers, to understand these new concepts in more detail. React introduces Hooks, a JavaScript function to allow using React without classes React 16.6.0 releases with a new way of code splitting, and more! InfernoJS v6.0.0, a React-like library for building high-performance user interfaces, is now out

Yesterday, Google announced that Chrome 70 now supports WebAssembly threads. The WebAssembly Community Group has been working to bring the support for threads to the web and this is a step towards that effort. Google’s open source JavaScript and WebAssembly engine, V8 has implemented all the necessary support for WebAssembly threads. Why the support for WebAssembly threads is needed? Earlier, parallelism in browsers was supported with the help of web workers. The downside of web workers is that they do not share mutable data between them. Instead, they rely on message-passing for communication. On the other hand, WebAssembly threads can share the same Wasm memory. The underlying storage of shared memory is enabled by SharedArrayBuffer, a JavaScript primitive that allows sharing the contents of a single ArrayBuffer concurrently between workers. Each WebAssembly thread runs in a web worker, but their shared Wasm memory allows them to work as fast as they do on native platforms. This means that those applications which use Wasm threads are responsible for managing access to the shared memory as in any traditional threaded application. How you can try this support To test the WebAssembly module you need to turn on the experimental WebAssembly threads support in Chrome 70 onwards: First, navigate to the chrome://flags URL in your browser: Source: Google Developers Next, go to the experimental WebAssembly threads setting: Source: Google Developers Now change the setting from Default to Enabled and then restart your browser: Source: Google Developers The aforementioned steps are for development purposes. In case you are interested in testing your application out in the field, you can do that with origin trial. Original trials allow you to try experimental features with your users by obtaining a testing token that’s tied to your domain. You can read more in detail about the WebAssembly thread support in Chrome 70 on the Google Developers blog. Chrome 70 releases with support for Desktop Progressive Web Apps on Windows and Linux Testing WebAssembly modules with Jest [Tutorial] Introducing Walt: A syntax for WebAssembly text format written 100% in JavaScript and needs no LLVM/binary toolkits