Tech News - Front-End Web Development

Last week, Snyk, an open-source security platform published the State of JavaScript frameworks security report 2019. This report mainly focuses on security vulnerabilities and risks in React and Angular ecosystems. It further talks about security practices in other common JavaScript frontend ecosystem projects including Vue.js, Bootstrap, and JQuery. https://twitter.com/snyksec/status/1189527376197246977 Key takeaways from the State of JavaScript frameworks security report Security vulnerabilities in core Angular and React projects In the report, the ‘react’, ‘react-dom’, and ‘prop-types’ libraries were considered as the core modules of React since they often form the foundation for React web applications. Snyk’s research team was able to find three cross-site scripting (XSS) vulnerabilities in total: two in ‘react’ and one in ‘react-dom’. The two vulnerabilities in the ‘react’ library were present in its pretty older versions, 0.5.x versions and the versions prior to 0.14. However, the vulnerability in react-dom was found in a recent release, version 16.x. Its occurrence depends on other pre-conditions as well, such as using the library within a server-rendering context. All these vulnerabilities’ Common Vulnerability Scoring System (CVSS) score ranged 6.5 and 7.1, which basically means that they were all medium to high severity vulnerabilities. Coming to Angular, Snyk found 19 vulnerabilities across six different release branches of Angular 1.x or AngularJS, which is no longer maintained. Angular 1.5 has the highest number of vulnerabilities, with seven vulnerabilities in total. Out of those seven, three had high severity and four had medium severity. The good thing is that with every new version, the vulnerabilities have decreased both in terms of severity and count. Security risks of indirect dependencies React and Angular projects are often generated with a scaffolding tool that provides a boilerplate. While in React, we use the ‘create-react-app’ npm package, in Angular we use the ‘@angular/cli’ npm package. In a sample React and Angular project created using these scaffolding tools, it was found that both included development dependencies with vulnerabilities. The good thing is that neither of them had any production dependency security issues. “It’s worthy to note that Angular relies on 952 dependencies, which contain a total of two vulnerabilities; React relies on 1257 dependencies, containing three vulnerabilities and one potential license compatibility issue,”  the report states. Here’s the list of security vulnerabilities that were found in these sample projects: Source: Snyk Security vulnerabilities in the Angular module ecosystem For the purposes of this study, the Snyk research team divided the Angular ecosystem into three areas: Angular ecosystem modules, malicious versions of modules, developer tooling. The Angular module ecosystem has the following vulnerable modules: Source: Snyk Talking about the malicious versions of modules, the report lists three malicious versions for the ‘angular-bmap’, ‘ng-ui-library’, ‘ngx-pica’ modules. The ‘angular-bmap’ 0.0.9 version included a malicious code that collected sensitive information related to password and credit cards from forms. It then used to send this information to an attacker-controlled URL. Thankfully, this version is now taken down from the npm registry. The ‘ng-ui-library’ 1.0.987 has the same malicious code as  ‘angular-bmap’ 0.0.9, despite that it is still maintained. The third module, 'ngx-pica' (from versions 1.1.4 to 1.1.6) also has the same malicious code as the above two modules. In developer tooling, the module ‘angular-http-server’ was found vulnerable to directory traversal twice. Security vulnerabilities in the React module ecosystem In React’s case, Snyk found four malicious packages namely ‘react-datepicker-plus’, ‘react-dates-sc’, ‘awesome_react_utility’, and ‘reactserver-native’. These contain malicious code that harvests credit card and other sensitive information and attacks compromised modules on the React ecosystem. Notable vulnerable modules that were found in React’s ecosystem during this study: The ‘react-marked-markdown’ module has a high-severity XSS vulnerability that does not have any fix available as of now. The ‘preact-render-to-string’ library is vulnerable to XSS in all versions prior to 3.7.2. The ‘react-tooltip’ library is vulnerable to XSS attacks for all versions prior to 3.8.1. The ‘react-svg’ library has a high severity XSS vulnerability that was disclosed by security researcher Ron Perris affecting all versions prior to 2.2.18. The 'mui-datatables' library has the CSV Injection vulnerability. “When we track all the vulnerable React modules we found, we count eight security vulnerabilities over the last three years with two in 2017, six in 2018 and two up until August 2019. This calls for responsible usage of open source and making sure you find and fix vulnerabilities as quickly as possible,” the report suggests. Along with listing the security vulnerabilities in React and Angular, the report also shares the overall security posture of the two. This includes secure coding conventions, built-in secure capabilities, responsible disclosure policies, and dedicated security documentation for the project. Vue.js security In total, four vulnerabilities were detected in the Vue.js core project spanning from December 2017 to August 2018: three medium and one low regular expressions denial of service vulnerability. As for Vue’s module ecosystem, the report lists the following vulnerable modules: The ‘bootstrap-vue’ library has a high severity XSS vulnerability that was disclosed in January 2019 and affects all versions prior to <2.0.0-rc.12. The ‘vue-backbone’ library had a malicious version published. Bootstrap security The Snyk research team was able to track a total of seven XSS vulnerabilities in Bootstrap. Out of those seven, three were disclosed in 2019 for recent Bootstrap v3 versions and three security vulnerabilities were disclosed in 2018, one of which affects the newer 4.x Bootstrap release. All these vulnerabilities have security fixes and an upgrade path for users to remediate the risks. Among the vulnerable modules in the Bootstrap ecosystem are: The ‘bootstrap-markdown’ library that includes an unfixed XSS vulnerability affecting all versions. The ‘bootstrap-vuejs’ library has a high severity XSS vulnerability that affects all versions prior to bootstrap-vue 2.0.0-rc.12. The ‘bootstrap-select’ library also includes a high severity XSS vulnerability. This article touched upon some of the key findings of the report. Check out the full report by Snyk to know more in detail. React Native 0.61 introduces Fast Refresh for reliable hot reloading React Conf 2019: Concurrent Mode preview out, CSS-in-JS, React docs in 40 languages, and more Vue maintainers proposed, listened, and revised the RFC for hooks in Vue API

Last week, the Angular team announced the release of Angular CLI 3.8.0. Along with a redesigned website, this release comes with a new deploy command and improves previously introduced differential loading. https://twitter.com/angular/status/1164653064898277378 Key updates in Angular CLI 8.3.0 Deploy directly from CLI to a cloud platform with the new deploy command Starting from Angular CLI 8.3.0, you have a new deploy command to execute the deploy CLI builder associated with your project. It is essentially a simple alias to ng run MY_PROJECT:deploy. There are many third-party builders that implement deployment capabilities to different platforms that you can add to your project with ng add [package name]. After this package with the deployment capability is added, your project’s angular.json file is automatically updated with a deploy section. You can then simply deploy your project by executing the ng deploy command. Currently, the deploy command supports deployment to Firebase, Azure, Zeit, Netlify, and GitHub. You can also create a builder yourself to use the ng deploy command in case you are deploying to a self-managed server or there’s no builder for the cloud platform you are using. Improved differential loading Angular CLI 8.0 introduced the concept of differential loading to maximize browser compatibility of your web application. Most of the modern browsers today support ES2015, but there might be cases when your app users have a browser that doesn’t. To target a wide range of browsers, you can use polyfill scripts for the browsers. You can ship a single bundle containing all your compiled code and any polyfills that may be needed. However, this increased bundle size shouldn’t affect users who have modern browsers. This is where differential loading comes in where the CLI builds two separate bundles as part of your deployed application. The first bundle will target modern browsers, while the second one will target the legacy browser with all necessary polyfills. Though this increases your application’s browser compatibility, the production build ends up taking twice the time. Angular CLI 8.3.0 fixes this by changing how the command runs. Now, the build targeting ES2015 is built first and then it is directly down leveled to ES5, instead of rebuilding the app from scratch. In case you encounter any issue, you can fall back to the previous behavior with NG_BUILD_DIFFERENTIAL_FULL=true ng build --prod. Many Angular developers are excited about the new updates in Angular CLI 8.3.0. https://twitter.com/vikerman/status/1164655906262409216 https://twitter.com/Santosh19742211/status/1164791877356277761 While some did question the usefulness of the deploy command. A developer on Reddit shared their perspective, “Honestly, I think Angular and the CLI are already big and complex enough. Every feature possibly creates bugs and needs to be maintained. While the CLI is incredibly useful and powerful there have been also many issues in the past. On the other hand, I must admit that I can't judge the usefulness of this feature: I've never used Firebase. Is it really so hard to deploy on it? Can't this be done with a couple of lines of a shell script? As already said: One should use CI/CD anyway.” To know more in detail about the new features in Angular CLI 8.3.0, check out the official docs. Also, check out the @angular-schule/ngx-deploy-starter repository to create a new builder for utilizing the deploy command. Angular 8.0 releases with major updates to framework, Angular Material, and the CLI Ionic Framework 4.0 has just been released, now backed by Web Components, not Angular The Angular 7.2.1 CLI release fixes a webpack-dev-server vulnerability, supports TypeScript 3.2 and Angular 7.2.0-rc.0

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

Last month, Manuel A. Fernandez Montecelo, a Debian contributor and developer talked about the Debian GNU/Linux riscv64 port at the RISC-V workshop. Debian, a Unix-like operating system consists of free software supported by the Debian community that comprises of individuals who basically care about free and open-source software. The goal of the Debian GNU/Linux riscv64 port project has been to have Debian ready for installation and running on systems that implement a variant of the RISC-V (an open-source hardware instruction set architecture) based systems. The feedback from the people regarding his presentation at the workshop was positive. Earlier this week,  Manuel A. Fernandez Montecelo announced an update on the status of Debian GNU/Linux riscv64 port. The announcement comes weeks before the release of buster which will come with another set of changes to benefit the port. What is RISC-V used for and why is Debian interested in building this port? According to the Debian wiki page, “RISC-V (pronounced "risk-five") is an open source instruction set architecture (ISA) based on established reduced instruction set computing (RISC) principles. In contrast to most ISAs, RISC-V is freely available for all types of use, permitting anyone to design, manufacture and sell RISC-V chips and software. While not the first open ISA, it is significant because it is designed to be useful in modern computerized devices such as warehouse-scale cloud computers, high-end mobile phones and the smallest embedded systems. Such uses demand that the designers consider both performance and power efficiency. The instruction set also has a substantial body of supporting software, which fixes the usual weakness of new instruction sets. In this project the goal is to have Debian ready to install and run on systems implementing a variant of the RISC-V ISA: Software-wise, this port will target the Linux kernel Hardware-wise, the port will target the 64-bit variant, little-endian This ISA variant is the "default flavour" recommended by the designers, and the one that seems to attract more interest for planned implementations that might become available in the next few years (development boards, possible consumer hardware or servers).” Update on Debian GNU/Linux riscv64 port Image source: Debian Let’s have a look at the graph where the percent of arch-dependent packages that are built for riscv64 (grey line) has been around or higher than 80% since mid-2018. The arch-dependent packages are almost half of Debian's [main, unstable] archive. It means that the arch-independent packages can be used by all the ports, provided that the software is present on which they rely on. The update also highlights that around 90% of packages from the whole archive has been made available for this architecture. Image source: Debian The graph above highlights that the percentages are very stable for all architectures. Montecelo writes, “This is in part due to the freeze for buster, but it usually happens at other times as well (except in the initial bring-up or in the face of severe problems).” Even the second-class ports appear to be stable. Montecelo writes, “Together, both graphs are also testament that there are people working on ports at all times, keeping things working behind the scenes, and that's why from a high level view it seems that things just work.” According to him, apart from the work of porters themselves, there are people working on bootstrapping issues that make it easier to bring up ports, better than in the past. They also make coping better when toolchain support or other issues related to ports, blow up. He further added, “And, of course, all other contributors of Debian help by keeping good tools and building rules that work across architectures, patching the upstream software for the needs of several architectures at the same time (endianness, width of basic types), many upstream projects are generic enough that they don't need specific porting, etc.” Future scope and improvements yet to come To get Debian running on RISC-V will not be easy because of various reasons including limited availability of hardware being able to run Debian port and limited options for using bootloaders. According to Montecelo, this is an area of improvement from them. He further added, “Additionally, it would be nice to have images publicly available and ready to use, for both Qemu and hardware available like the HiFive Unleashed (or others that might show up in time), but although there's been some progress on that, it's still not ready and available for end users.” Presently, they are beyond 500 packages from the Rust ecosystem in the archive (which is about 4%) which can’t be built and used until Rust gets support for the architecture. Rust requires LLVM and there’s no Rust compiler based on GCC or other toolchains. Montecelo writes, “Firefox is the main high-level package that depends on Rust, but many packages also depend on librsvg2 to render SVG images, and this library has been converted to Rust. We're still using the C version for that, but it cannot be sustained in the long term." Apart from Rust, other packages use LLVM to some extent, but currently, it is not fully working for riscv64. The support of LLVM for riscv64 is expected to be completed this year. While talking about other programming languages, he writes, “There are other programming language ecosystems that need attention, but they represent a really low percentage (only dozens of packages, of more than 12 thousand; and with no dependencies outside that set). And then, of course, there is a long tail of packages that cannot be built due to a missing dependency, lack of support for the architecture or random failures -- together they make a substantial number of the total, but they need to be looked at and solved almost on a case-by-case basis.” Why are people excited about this? Many users seem to be excited about the news, one of the reasons being that there won’t be a need to bootstrap from scratch as Rust now will be able to cross-compile easily because of the Riscv64 support. A user commented on HackerNews, “Debian Rust maintainer here. We don't need to bootstrap from scratch, Rust (via LLVM) can cross-compile very easily once riscv64 support is added.” Also, this appears to be a good news for Debian, as cross-compiling has really come a long way on Debian. Rest are awaiting for more to get incorporated with riscv. Another user commented, “I am waiting until the Bitmanip extension lands to get excited about RISC-V: https://github.com/riscv/riscv-bitmanip” Few others think that there is a need for LLVM support for riscv64. A user commented, “The lack of LLVM backend surprises me. How much work is it to add a backend with 60 instructions (and few addressing modes)? It's clearly far more than I would have guessed.” Another comment reads, “Basically LLVM is now a dependency of equal importance to GCC for Debian. Hopefully this will help motivate expanding architecture-support for LLVM, and by proxy Rust.” According to users, the architecture of this port misses on two major points, one being the support for LLVM compiler and the other one being the support for Rust based on GCC. If the port gets the LLVM support by this year, users will be able to develop a front end for any programming language as well as a backend for any instruction set architecture. Now, if we consider the case of support for Rust based on GCC, then the port will help developers to get support for many language extensions as GCC provides the same. A user commented on Reddit, “The main blocker to finish the port is having a working Rust toolchain. This is blocked on LLVM support, which only supports RISCV32 right now, and RISCV64 LLVM support is expected to be finished during 2019.” Another comment reads, “It appears that enough people in academia are working on RISCV for LLVM to accept it as a mainstream backend, but I wish more stakeholders in LLVM would make them reconsider their policy.” To know more about this news, check out Debian’s official post. Debian maintainer points out difficulties in Deep Learning Framework Packaging Debian project leader elections goes without nominations. What now? Are Debian and Docker slowly losing popularity?  

Last year, Apple removed the Extended Validation (EV) certificate indicators from Safari on both iOS 12 and Mojave. Now, Google and Mozilla are following suit by removing the EV visual indicators starting from Chrome 77 and Firefox 70. What are Extended Validation Certificates Introduced in 2007, Extended Validation Certificates are issued to applicants after they are verified as a genuine legal entity by a certificate authority (CA). The baseline requirements for an EV certificate are outlined by the CA/Browser forum. Web browsers show a green address bar when visiting a website that is using EV Certificate. You will see the company name alongside the padlock symbol in the green address bar. These certificates can often be expensive. DigiCert charges $344 USD per year, Symantec prices its EV certificate at $995 USD a year, and Thawte at $299 USD a year. Why Chrome and Firefox are removing EV indicators In a survey conducted by Google, users of the Chrome and Safari browsers were asked how much they trusted a website with and without EV indicators. The results of the survey showed that browser identity indicators do not have much effect on users’ secure choices. About 85 percent of users did not find anything strange about a Google login page with the fake URL “accounts.google.com.amp.tinyurl.com”. Seeing these results and prior academic work, the Google Security US team concluded that positive security indicators are largely ineffective. “As part of a series of data-driven changes to Chrome’s security indicators, the Chrome Security UX team is announcing a change to the Extended Validation (EV) certificate indicator on certain websites starting in Chrome 77,” the team wrote in a Google group. Another reason behind this decision was that the EV indicators takes up valuable screen space. Starting with Chrome 77,  the information related to EV indicators will be shown in Page Info that appears when the lock icon is clicked instead of the EV badge: Source: Google Citing similar reasons, the team behind Firefox shared their intention to remove EV indicators from Firefox 70 for desktop yesterday. They also plan to add this information to the identity panel instead of showing it on the identity block. “The effectiveness of EV has been called into question numerous times over the last few years, there are serious doubts whether users notice the absence of positive security indicators and proof of concepts have been pitting EV against domains for phishing,” the team wrote. Many CAs market EV certificates as something that builds visitor confidence, protects them against phishing, and identity fraud. Looking at these advancements, Troy Hunt, a web security expert and the creator of “Have I Been Pwned?” concluded that EV certificates are now dead. In a blog post, he questioned the CAs, “how long will it take the CAs selling EV to adjust their marketing to align with reality?” Users have mixed feelings about this change. “Good riddance, IMO. They never meant much, to begin with, the validation procedures were basically "can you pay the fee?", and they only added to user confusion,” a user said on Hacker News. Many users believe that EV indicators are valuable for financial transactions. A user commented on Reddit, “As a financial institution it was always much easier to just say "make sure it says <Bank name> in the URL bar and it's green" when having a customer on the phone than "Please click on settings -> advanced settings -> security -> display certificate and check the value subject".” To know more, check out the official announcements by Chrome and Firefox teams. Google Chrome to simplify URLs by hiding special-case subdomains Flutter gets new set of lint rules to build better Chrome OS apps Mozilla releases WebThings Gateway 0.9 experimental builds targeting Turris Omnia and Raspberry Pi 4  

Yesterday, Apple announced that Safari Technology Preview 91 now supports the beta version of the new WebGPU graphics API and its shading language, Web Shading Language (WSL). You can enable the WebGPU beta support by selecting Experimental Features > WebGPU in the Developer menu. The WebGPU JavaScript API WebGPU is a new graphics API for the web that aims to provide "modern 3D graphics and computation capabilities.” It is a successor to WebGL, a JavaScript API that enables 3D and 2D graphics rendering within any compatible browser without the need for a plug-in. It is being developed in the W3C GPU for the Web Community Group with engineers from Apple, Mozilla, Microsoft, Google, and others. Read also: WebGL 2.0: What you need to know Comparing WebGPU and WebGL WebGPU is different from WebGL in the respect that it is not a direct port of any existing native API, but a similarity between the two is that they both are accessed through JavaScript. However, the team does have plans to make it accessible through WebAssembly as well in the future. In WebGL, rendering a single object requires writing a series of state-changing calls. On the other hand, WebGPU combines all the state-changing calls into a single object named pipeline state object. It validates the state after the pipeline is created to prevent expensive state analysis inside the draw call. Also, wrapping an entire pipeline state in a single function call reduces the number of exchanges between Javascript and WebKit’s C++ browser engine. Similarly, resources in WebGL are bound one-by-one, while WebGPU batches them up into bind groups. The team explains, “In both of these examples, multiple objects are gathered up together and baked into a hardware-dependent format, which is when the browser performs validation. Being able to separate object validation from object use means the application author has more control over when expensive operations occur in the lifecycle of their application.” The main focus area of WebGPU is to provide improved performance and ease of use as compared to WebGL. The team compared the performance of the two using the 2D graphics benchmark, MotionMark. The performance test they wrote measured how many triangles each with different properties were rendered while maintaining 60 frames per second. Each triangle was rendered with a different draw call and bind group. WebGPU showed a substantially better performance than WebGL: Source: Apple WHLSL is now renamed to WSL In November last year, Apple proposed a new shading language for WebGPU named Web High-Level Shading Language (WHLSL), which was source-compatible with HLSL. After receiving the community feedback, they updated the language to be compatible with OpenGL Shading Language (GLSL), which is a pretty commonly used language among the web developers. Apple renamed this version of the language to Web Shading Language (WSL) and describes it as “simple, low-level, and fast to compile.” Read also: Introducing Web High Level Shading Language (WHLSL): A graphics shading language for WebGPU “There are many Web developers using GLSL today in WebGL, so a potential browser accepting a different high-level language, like HLSL, wouldn’t suit their needs well. In addition, a high-level language such as HLSL can’t be executed faithfully on every platform and graphics API that WebGPU is designed to execute on,” the team wrote. Check out the official announcement by Apple to know more in detail. Other news in web Firefox 69 allows default blocking of third-party tracking cookies and cryptomining for all users New memory usage optimizations implemented in V8 Lite can also benefit V8 Laravel 6.0 releases with Laravel vapor compatibility, LazyCollection, improved authorization response and more  

Yesterday, the Firefox team announced its latest version, Firefox 71. This version includes a plethora of new developer tools features such as web socket message inspector, console multi-line editor mode, log on events, and network panel full-text search. Many of these features were first made available in the Firefox Developer Edition and later improved based on the feedback. Other highlights in Firefox 71 includes new web platform features such as CSS subgrid, column-span, Promise.allSettled, and the Media Session API. What’s new in Firefox 71? Improvements in speed and reliability In Firefox 71, the team took some help from the JavaScript team by improving the caching of scripts during a startup. This made both Firefox and DevTools start faster. “One Console test got an astonishing 40% improvement while times across every panel were boosted by 8-15%”, the official blog post mentions. Also, the links to scripts, for example, from the event handler tooltip in the Inspector or the stack traces in the Console, reliably gets you to the expected line and debugging sources loaded through eval() now also works as expected. WebSocket Message Inspector In Firefox 71, the Network panel has a new Messages tab. You can observe all messages sent and received through a WebSocket connection: Source: Mozilla Hacks Sent frames have a green up-arrow icon, while received frames have a red down-arrow icon. You can click on an individual frame to view its formatted data. Know more about WebSocket Message Inspector on the official post. Console multi-line editor mode Another developer tools feature in Firefox 71 is the new multi-line console. It combines the benefits of IDEs to authoring code with the workflow of repeatedly executing code in the context of the page. If you open the regular console, you’ll see a new icon at the end of the prompt row. Source: Mozilla Hacks Clicking this will switch the console to multi-line mode: Source: Mozilla Hacks Here you can enter multiple lines of code, pressing enter after each one, and then run the code using Ctrl + Enter. You can also move between statements using the next and previous arrows. The editor includes regular IDE features you’d expect, such as open/close bracket pair highlighting and automatic indentation. Inline variable preview in Debugger The JavaScript Debugger now provides inline variable previewing, which is a useful timesaver when stepping through your code. In previous versions, you had to scroll through the scope panel to find variable values or hover over a variable in the source pane. In the current version, when execution pauses, you can view relevant variable and property values directly in the source. Source: Mozilla Hacks Using the babel-powered source mapping, preview also works for variables that have been renamed or minified by build steps. Make sure to enable this power-feature by checking Map in the Scopes pane. Log on Event Listeners There have been a few updates in the event listener breakpoints in Firefox 71. A few improvements include, log on events lets you explore which event handlers are being fired in which order without the need for pausing and stepping. Hence, if we choose to log keyboard events, for example, the code no longer pauses as each event is fired: Source: Mozilla Hacks Instead, we can then switch to the console, and whenever we press a key we are given a log of where related events were fired. CSS improvements In Firefox 71, the new CSS includes subgrid, multicol, clip-path: path, and aspect ratio mapping. Subgrid A feature that has been enabled in 71 after being supported behind a pref for a while, the subgrid value of grid-template-columns and grid-template-rows allows you to create a nested grid inside a grid item that will use the main grid’s tracks. This means that grid items inside the subgrid will line up with the parent’s grid tracks, making various layout techniques much easier. Multicol — column-span CSS multicol support has moved forward in a big way with the inclusion of the column-span property in Firefox 71. This allows you to make an element span across all the columns in a multicol container (generated using column-width or column-count). Clip-path: path() The path() value of the clip-path property is now enabled by default — this allows you to create a custom mask shape using a path() function, as opposed to a predefined shape like a circle or ellipse. Aspect ratio mapping Finally, the height and width HTML attributes on the <img> element are now mapped to an internal aspect-ratio property. This allows the browser to calculate the image’s aspect ratio early on and correct its display size before it has loaded if CSS has been applied that causes problems with the display size. There are also a few minor JavaScript changes in this release including, Promise.allSettled(), the Media Session API, and WebGL multiview. A lot of users are excited about this release and are looking forward to trying it out. https://twitter.com/IshSookun/status/1201897724943036417 https://twitter.com/awhite/status/1202163413021077504 To know more about this news in detail, read Firefox 71 official announcement. The new WebSocket Inspector will be released in Firefox 71 Firefox 70 released with better security, CSS, and JavaScript improvements Google and Mozilla to remove Extended Validation indicators in Chrome 77 and Firefox 70

Yesterday, the team behind Ghost, an open-source headless Node.js CMS, announced its major version, Ghost 3.0. The new version represents “a total of more than 15,000 commits across almost 300 releases”  Ghost is now used by the likes of Apple, DuckDuckGo, OpenAI, The Stanford Review, Mozilla, Cloudflare, Digital Ocean, and many, others. “To date, Ghost has made $5,000,000 in customer revenue whilst maintaining complete independence and giving away 0% of the business,” the official website highlights. https://twitter.com/Ghost/status/1186613938697338881 What’s new in Ghost 3.0? Ghost on the JAMStack The team has revamped the traditional architecture using JAMStack which makes Ghost a completely decoupled headless CMS. In this way, users can generate a static site and later add dynamic features to make it powerful. The new architecture unlocks content management that is fundamentally built via APIs, webhooks, and frameworks to generate robust modern websites. Continuous theme deployments with GitHub Actions The process of manually making a zip, navigating to Ghost Admin, and uploading an update in the browser can be difficult at times. To deploy Ghost themes to production in a better way, the team decided to combine with Github Actions. This makes it easy to continuously sync custom Ghost themes to live production sites with every new commit. New WordPress migration plugin Earlier versions of Ghost included a very basic WordPress migrator plugin that made it extremely difficult for anyone to move their data between the platforms or have a smooth experience. The new Ghost 3.0 compatible WordPress migration plugin provides a single-button-download of the full WordPress content + image archive in a format that can be dragged and dropped into Ghost's importer. Those who are new and want to explore Ghost 3.0 can create a new site in a few clicks with an unrestricted 14 day free trial as all new sites on Ghost (Pro) are running Ghost 3.0. The team expects users to try out Ghost 3.0 and get back with feedback for the team on the Ghost forum or help out on Github for building the next features with the Ghost team. Ben Thompson’s Stratechery, a subscription-based newsletter featuring in-depth commentary on tech and media news, recently posted an interview with Ghost CEO John O’Nolan. This interview features questions on what Ghost is, where it came from, and much more. Ghost 3.0 has received a positive response from many and also the fact that it is moving towards adopting static site JAMStack approach. A user on Hacker News commented, “In my experience, Ghost has been the no-nonsense blog CMS that has been stable and just worked with very little maintenance. I like that they are now moving towards static site JAMStack approach, driven by APIs rather than the current SSR model. This lets anybody to customise their themes with the language / framework of choice and generating static builds that can be cached for improved loading times.” Another user who is using Ghost for the first time commented, “I've never tried Ghost, although their website always appealed to me (one of the best designed website I know). I've been using WordPress for the past 13 years, for personal and also professional projects, which means the familiarity I've built with building custom themes never drew me towards trying another CMS. But going through this blog post announcement, I saw that Ghost can be used as a headless CMS with frontend frameworks. And since I started using GatsbyJS extensively in the past year, it seems like something that would work _really_ well together. Gonna try it out! And congrats on remaining true to your initial philosophy.” To know more about the other features in detail, read the official blog post. Google partners with WordPress and invests $1.2 million on “an opinionated CMS” called Newspack Verizon sells Tumblr to WordPress parent, Automattic, for allegedly less than $3million, a fraction of its acquisition cost FaunaDB brings its serverless database to Netlify to help developers create apps

The release candidate for Typescript 2.9 is here! Typescript is an open-source programming language which adds optional static typing to Javascript. Let’s jump into some highlights of Typescript 2.9 RC. Changes to keyof operator TypeScript 2.9 changes the behavior of keyof to factor in both unique symbols as well as numeric literal types. TypeScript’s keyof operator is a useful way to query the property names of an existing type. Before Typescript 2.9, keyof never recognized symbolic keys. With this functionality, mapped object types like Partial, Required, or Readonly can also recognize symbolic and numeric property keys, and no longer drop properties named by symbols. Introduction of new import( ) type syntax One long-running pain-point in TypeScript has been the inability to reference a type in another module, or the type of the module itself, without including an import at the top of the file. With Typescript 2.9, their is a new import(...) type syntax. import types use the same syntax as ECMAScript’s proposed import(...) expressions, and provide a convenient way to reference the type of a module, or the types which a module contains. Trailing commas not allowed on rest parameters This break was added for conformance with ECMAScript, as trailing commas are not allowed to follow rest parameters in the specification. Changes to strictNullChecks Unconstrained type parameters are no longer assignable to object in strictNullChecks. Since generic type parameters can be substituted with any primitive type, this is a precaution TypeScript has added under strictNullChecks. To fix this, you can add a constraint on object. never can no longer be iterated over Values of type never can no longer be iterated over. Users can avoid this behavior by using a type assertion to cast to the type any. The list of entire changes and code files can be found on the Microsoft blog. You can also view the TypeScript roadmap for everything else that’s coming in 2.9 and beyond. How to install and configure TypeScript How to work with classes in Typescript Tools in TypeScript

In April this year, Mozilla announced that it would be shutting down its IRC network stating that it creates “unnecessary barriers to participation in the Mozilla project.” Last week, Mike Hoye, the Engineering Community Manager at Mozilla, shared the four final candidates for Mozilla’s community-facing synchronous messaging system: Mattermost, Matrix/Riot.im, Rocket.Chat, and Slack. Mattermost is a flexible, self-hostable, open-source messaging platform that enables secure team collaboration. Riot.im is an open-source instant messaging client that is based on the federated Matrix protocol. Rocket.Chat is also a free and open-source team chat collaboration platform. The only proprietary option in the shortlisted messaging platform list is Slack, which is a widely used team collaboration hub. Read also: Slack stocks surges 49% on the first trading day on the NYSE after direct public offering Explaining how Mozilla shortlisted these messaging systems, Hoye wrote, “These candidates were assessed on a variety of axes, most importantly Community Participation Guideline enforcement and accessibility, but also including team requirements from engineering, organizational-values alignment, usability, utility and cost.” He said that though there were a whole lot of options to choose from these were the ones that best-suited Mozilla’s current institutional needs and organizational goals. Mozilla will soon be launching official test instances of each of the candidates for open testing. After the one month trial period, the team will be taking feedback in dedicated channels on each of those servers. You can also share your feedback in #synchronicity on IRC.mozilla.org and a forum on Mozilla’s community Discourse instance that the team will be creating soon. Mozilla's timeline for transitioning to the finalized messaging system September 12th to October 9th: Mozilla will be running the proof of concept trials and accepting community feedback. October 9th to 30th: It will discuss the feedback, draft a proposed post-IRC plan, and get approval from the stakeholders. December 1st:  The new messaging system will be started. March 1st, 2020: There will be a transition time for support tooling and developers starting from the launch to March 1st, 2020. After this Mozilla’s IRC network will be shut down. Hoye shared that the internal Slack instance will still be running regardless of the result to ensure smooth communication. He wrote, “Internal Slack is not going away; that has never been on the table. Whatever the outcome of this process, if you work at Mozilla your manager will still need to be able to find you on Slack, and that is where internal discussions and critical incident management will take place.” In a discussion on Hacker News, many rooted for Matrix. A user commented, “I am hoping they go with Matrix, least then I will be able to have the choice of having a client appropriate to my needs.” Another user added, “Man, I sure hope they go the route of Matrix! Between the French government and Mozilla, both potentially using Matrix would send a great and strong signal to the world, that matrix can work for everyone! Fingers crossed!” Many also appreciated that Mozilla chose three open-source messaging systems. A user commented, “It's great to see 3/4 of the options are open source! Whatever happens, I really hope the community gets behind the open-source options and don't let more things get eaten up by commercial silos cough slack cough.” Some were not happy that Zulip, an open-source group chat application, was not selected. “I'm sad to see Zulip excluded from the list. It solves the #1 issue with large group chats - proper threading. Nothing worse than waking up to a 1000 message backlog you have to sort through to filter out the information relevant to you. Except for Slack, all of their other choices have very poor threading,” a user commented. Check out the Hoye’s official announcement to know more in detail. Other news in web Firefox 69 allows default blocking of third-party tracking cookies and cryptomining for all users Wasmer’s first Postgres extension to run WebAssembly is here! JavaScript will soon support optional chaining operator as its ECMAScript proposal reaches stage 3

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

GitHub has finally finished removing the JQuery dependency from its frontend code. This was a result of gradual decoupling from JQuery which began back in at least 2 years ago. They have chosen not to replace JQuery with yet another framework. Instead, they were able to make this transition with the help of polyfills that allowed them to use standard browser features such as, EventListener, fetch, Array.from, and more. Why GitHub chose JQuery in the beginning? Simple: GitHub started using JQuery 1.2.1 as a dependency in 2007. This enabled its web developers to create more modern and dynamic user experience. JQuery 1.2.1 allowed developers to simplify the process of DOM manipulations, define animations, and make AJAX requests. Its simple interface gave GitHub developers a base to craft extension libraries such as, pjax and facebox, which later became the building blocks for the rest of GitHub frontend. Consistent: Unlike the XMLHttpRequest interface, JQuery was consistent across browsers. GitHub in its early days chose JQuery as it allowed their small development team to quickly prototype and release new features without having to adjust code specifically for each web browser. Why they decided to remove JQuery dependency? After comparing JQuery with the rapid evolution of supported web standards in modern browsers, they observed that: CSS classname switching can be achieved using Element.classList. Visual animations can be created using CSS stylesheets without writing any JavaScript code. The addEventListeners method, which is used to attach an event handler to the document, is now stable enough for cross-platform use. $.ajax requests can be performed using the Fetch Standard. With the evolution of JavaScript, some syntactic sugar that jQuery provides has become redundant. The chaining syntax of JQuery didn’t satisfy how GitHub wanted to write code going forward. According to this announcement, this step of decoupling from jquery will allow them to: Rely on web standards more Have MDN web docs as their default documentation to refer Maintain more resilient code in future Speeding up page load times and JavaScript execution time Which technology is it using now? GitHub has moved from JQuery to vanilla JS (plain JavaScript). It is now using querySelectorAll, fetch for ajax, and delegated-events for event handling; polyfills for standard DOM manipulations, and Custom Elements. The adoption of Custom Elements is on the rise. It is a component library native to the browser, which means that users do not have to download, parse, and compile additional bytes of a framework. With the release of Web Components v1 in 2017, GitHub started to adopt Custom Elements on a wider scale. In future they are also planning to use Shadow DOM. To read more about how GitHub made this transition to using standard browser features, check out their official announcement. Github introduces Project Paper Cuts for developers to fix small workflow problems, iterate on UI/UX, and find other ways to make quick improvements Why Golang is the fastest growing language on GitHub

Yesterday, Brave, the company co-founded by ex-Mozilla CEO, Brendan Eich, launched version 1.0 of its browser for Windows, macOS, Linux, Android and iOS. In a browser market where users have to compromise on their privacy, Brave is positioning itself as a fast option that preserves users’ privacy with strong default settings, as well as a crypto currency-centric private ads and payment platform that allows users to reward content creators. “Surveillance capitalism has plagued the Web for far too long and we’ve reached a critical inflection point where privacy-by-default is no longer a nice-to-have, but a must-have. Users, advertisers, and publishers have finally had enough, and Brave is the answer. Brave 1.0 is the browser reimagined, transforming the Web to put users first with a private, browser-based ads and payment platform. With Brave, the Web can be a rewarding experience for all, without users paying with their privacy.” said Brendan Eich, co-founder and CEO of Brave Software. “Either we all accept the $330 billion ad-tech industry treating us as their products, exploiting our data, piling on more data breaches and privacy scandals, and starving publishers of revenue; or we reject the surveillance economy and replace it with something better that works for everyone. That’s the inspiration behind Brave,” he added. The company also announced last month that Brave has about 8 million monthly active users. Brave offers a privacy-first approach to its users that natively blocks trackers, invasive ads, and device fingerprinting. This leads to substantial improvements in speed, privacy, security, performance, and battery life. It has default settings to block phishing, malware, and malvertising. Embedded plugins, which have proven to be an ongoing security risk, are disabled by default in Brave. Browsing data always stays private and on the user’s device, which means Brave will never see or store the data on its servers or sell user data to third-parties. Brave 1.0 key features Additionally Brave 1.0 offers some unique features to its users: Brave Rewards program to fund open web – By activating Brave Reward, users can support their favorite publishers and content creators and integrate Brave wallet on both desktop and mobile. This feature allows users to send Basic Attention Tokens (BAT) as tips for great content, either directly as they browse or by defaulting to recurring monthly payments to continuously support websites you visit frequently. There are over 300,000 verified websites on-boarded on Brave for this program including The Washington Post, The Guardian, Wikipedia, YouTube, Twitch, Twitter, GitHub and more. Brave Ads compensate users for their attention – Brave has a new blockchain-based advertising model that enables privacy and gives 70% of its revenue share in the form of Basic Attention Tokens (BAT) to users who view the Brave ads. These ads are a part of private ad network and Brave Rewards program. It allows users to opt-in to view relevant privacy-preserving ads in exchange for earning BAT. When users opt into Brave Rewards, Brave ads are enabled by default. As per the content viewed by a user, ad matching happens directly on the user’s device, so their data is never sent to anyone, and they see rewarding ads without mass surveillance. Users can also transfer their earned BAT from the wallet and convert into digital assets and fiat currencies, but they need to complete the verification process with Uphold, a digital money platform. Brave Shields for automatic ad and tracker blocking – Brave Shields, this feature is enabled by default and is customizable from the address bar. It blocks invasive third-party ads, trackers, and autoplay videos immediately – without needing to install any additional programs. On Hacker News, users have appreciated the way Brave browser operates and rewards its content consumers as well as the creators. One of them has explained its functioning in detail, “I've been using Brave rewards, both as a user and a content maker. It's really great, and I feel this may be a reasonable alternative to the invasive trackers+ads we have today. For the uninitiated, Brave lets users opt-in to Brave rewards: - You set your browser to reward content creators with Basic Attention Token (BAT). You set a budget (e.g. 10 BAT/month), and Brave distributes it the sites you use most, e.g. if you watch a particular YouTube channel 30% of your browsing time, it will send 30% of 10 BAT each month to that content creator. - As a user, you can get paid in BAT. You tell Brave if you're willing to see ads, and how often. If so, you get paid in BAT, which you can then distribute to content creators. Brave ads are different: rather than intrusive in-page ads, Brave ads show up as a notification in your operating system outside of the page. This prevents slow downs of the page, keeping your browsing focused, while still allowing support of content creators. And of course, Brave ads are optional and opt-in.” You can download Brave for free, by visiting official Brave page, Google Playstore or the App Store. Google is circumventing GDPR, reveals Brave’s investigation for the Authorized Buyers ad business case Brave ad-blocker gives 69x better performance with its new engine written in Rust Edge, Chrome, Brave share updates on upcoming releases, recent milestones, and more at State of Browsers event Brave launches its Brave Ads platform sharing 70% of the ad revenue with its users Brave Privacy Browser has a ‘backdoor’ to remotely inject headers in HTTP requests: HackerNews

React announced its monthly release yesterday, React 16.5.0. In this release they have improved warning messages, added support for React DevTools Profiler in React DOM, and done some bug fixes. Updates in React A Dev warning is shown if React.forwardRef render function doesn't take exactly two arguments. A more improved message is shown if someone passes an element to createElement by mistake. The onRender function will be called after mutations and commitTime reflects pre-mutation time. Updates in React DOM New additions Support for React DevTools Profiler is added. The react-dom/profiling entry point is added for profiling in production. The onAuxClick event is added for browsers that support it. The movementX and movementY fields are added to mouse events. The tangentialPressure and twist fields are added to pointer events. Support for passing booleans to the focusable SVG attribute. Improvements Improved component stack for the folder/index.js naming convention. Improved warning when using getDerivedStateFromProps without initialized state. Improved invalid textarea usage warning. Electrons <webview> tag are now allowed without warnings. Bug fixes Fixed incorrect data in compositionend event when typing Korean on IE11. Avoid setting empty values on submit and reset buttons. The onSelect event not being triggered after drag and drop. The onClick event not working inside a portal on iOS. A performance issue when thousands of roots are re-rendered. gridArea will be treated as a unitless CSS property. The checked attribute is not getting initially set on the input. A crash when using dynamic children in the option tag. Updates in React DOM Server A crash is fixed that happens during server render in react 16.4.1 Fixes a crash when setTimeout is missing This release fixes a crash with nullish children when using dangerouslySetInnerHtml in a selected option. Updates in React Test Renderer and Test Utils A Jest-specific ReactTestUtils.mockComponent() helper is now deprecated. A warning is shown when a React DOM portal is passed to ReactTestRenderer. Improvements in TestUtils error messages for bad first argument. Updates in React ART Support for DevTools is added New package for scheduling (experimental) The ReactDOMFrameScheduling module will be pulled out in a separate package for cooperatively scheduling work in a browser environment. It's used by React internally, but its public API is not finalized yet. To see the complete list of updates in React 16.5.0, head over to their GitHub repository. React Next React Native 0.57 coming soon with new iOS WebViews Implementing React Component Lifecycle methods [Tutorial] Understanding functional reactive programming in Scala [Tutorial]

Today, Minko Gechev, an engineer in the Angular team at Google announced the release of Angular CLI 7.2.1. This release fixes a webpack-dev-server vulnerability and also comes with support for multiselect list prompt, TypeScript 3.2, and Angular 7.2.0-rc.0. https://twitter.com/mgechev/status/1083133079579897856 Understanding the webpack-dev-server vulnerability The npm install command was showing the Missing Origin Validation vulnerability because webpack-dev-server versions before 3.1.10 are missing origin validation on the websocket server. A remote attacker can take advantage of this vulnerability to steal a developer’s code as the origin of requests to the websocket server, which is used for Hot Module Replacement (HMR) are not validated. Other updates in Angular 7.2.1 CLI Several updates and bug fixes were listed in the release notes of Angular CLI’s GitHub repository. Some of them are: Support is added for multiselect list prompt Support is added for TypeScript 3.2 and Angular 7.2.0-rc.0 Optimization options are updated Warnings are added for overriding flags in arguments lintFix is added to several other schematics `resourcesOutputPath` is added to the schema to define where style resources will be placed, relative to outputPath. The architect command project parsing is improved Prompt support is added using Inquirer Jobs API is added Directly loading component templates is supported Angular 7 is now stable Unit testing Angular components and classes [Tutorial] Setting up Jasmine for Unit Testing in Angular [Tutorial]