Tech News - Full-Stack Web Development

Last month, the team behind Selenium silently slipped in Selenium 4 alpha on the Maven Repository without any official announcement. Alpha release means that developers can start testing out the new updates in the software but are not recommended to use it in production. Selenium 4 is a major release, which was actually planned to ship by Christmas last year, as shared by Simon Stewart, one of the Selenium lead developers and the inventor of WebDriver, at the Selenium Conference India 2018. https://www.youtube.com/watch?v=ypmrrJmgM9U&feature=youtu.be However, going by the status on SeleniumHQ GitHub repository, we can expect more delay in this release. This situation is very similar to that of Selenium 3.0 release. Back in 2013, Stewart shared that Selenium 3.0 will be released by Christmas, which ended up hitting the market after 3 years of the announcement. "I did say Christmas, but I didn't specify what year," he jokingly said in a webinar in 2016. Following are some of the updates in Selenium 4 alpha release: Native support removed for Opera and PhantomJS Starting from this release, the Opera and PhantomJS browsers will not be supported natively as the WebDriver implementations for these browsers are no longer under active development. Since Opera is built on top of the Chromium open source projects, users are recommended to test with the Chrome browsers. PhantomJS users can use Firefox or Chrome in headless mode. Updates for W3C WebDriver Spec Compliance Selenium 4 WebDriver will be completely standardized with W3C. In lieu of this, the following changes are made in this release: Changes to the Actions API This release comes with a revamped Actions API to comply with the WebDriver specifications. The Actions API serves as a low-level interface for providing virtualized device input to the web browser. Currently, Actions is only supported in Firefox natively. Other browser users can use this API by putting the Actions class into “bridge mode”. It will then attempt to translate mouse and keyboard actions to the legacy API. Alternatively, users can continue using the legacy API via the ‘lib/actions’ module. However, it should be noted that the legacy API will be deprecated and will be removed in a minor release once other browsers start supporting the new API. Other changes This release comes with support for all window manipulation commands WebElement.getSize() and WebElement.getLocation() are now replaced with a single method, WebElement.getRect(). A new method, driver.switchTo().parentFrame() method is added To read what else has been updated in this release, check out change doc on Selenium GitHub repository. Selenium and data-driven testing: An interview with Carl Cocchiaro How to work with the Selenium IntelliJ IDEA plugin How to handle exceptions and synchronization methods with Selenium WebDriver API

As the web has evolved, its security needs have changed too. Today, as web applications become more lightweight, composed of loosely coupled services, with a mesh of different dependencies, the onus is on web developers to build websites and applications that have not only better user experience but also better user security. There are many techniques that can be used to do this. And at this year’s JavaScript fwdays, Twilio frontend developer Stefan Judis demonstrated how we can use HTTP headers to add another layer of security and optimization to our applications and websites. Why do web developers need to think seriously about security? The browser has in recent years become a popular site for attacks. Back in 2017, Equifax, a massive credit rating agency, announced that criminals exploited a vulnerability in their website to get access to personal information of 143 million American consumers. Last year, more than 4,000 websites in the US and UK were found serving the CoinHive crypto miner, a JavaScript script designed to mine cryptocurrency at the expense of users’ CPU power, to its users because of a “cryptojacking” attack. Today, when there are so many open-source packages available on package managers like npm, nobody really codes everything from scratch while developing any application. Last year in November, we saw the case of malicious code in the npm event-stream package. The attacker used social engineering tactics to become the maintainer of the event-stream package and then exploited their position to add a malicious package as a direct dependency. Looking at these cases developers have become more aware of the different means and ways of securing their work like using a web application firewall, using web vulnerability scanners, securing the web server, and more. And, a good place to start is ensuring security through HTTP security headers and that’s what Judis explained in his talk. https://www.youtube.com/watch?v=1jD7dBsg_Nw What are HTTP headers? HTTP, which stands for Hypertext transfer protocol, allows the client and server to communicate over a secure connection. HTTP headers are the key-value pairs that are used to exchange additional information. When a client makes a request for a resource, along with the request a request header is sent to the server, which includes particulars such as the browser version, client’s operating system, and so on. The server answers back with the resource along with a response header containing information like type, date, and size of the file sent. Some different examples of HTTP headers Below are some of the HTTP headers Judis demonstrated: HSTS (HTTP Strict Transport Security) HTTPS, which is a secure version of HTTP, ensures that we are communicating over a secure channel with the help of Transport Layer Security (TLS) protocol or its predecessor Secure Sockets Layer (SSL) for encryption. Not only just security, but it is often a requirement for many new browser features, especially those required for progressive web apps. Though browser vendors do mark non-HTTPS unsafe, we cannot really guarantee safety all the time. “Unfortunately, we’re not browsing safe all the time. When someone wants to open a website they are not entering the protocol into the address bar (and why should they?). This action leads to an unencrypted HTTP request. Securely running sites then redirect to HTTPS. But what if someone intercepts the first unsecured request?,” wrote Judis in a blog post. To address such cases you can use HSTS response headers, that allow declaring that your web server only takes HTTPS requests. You can implement it this way: Strict-Transport-Security: max-age=1000; includeSubDomains; preload Before you implement, do read this helpful advice shared by a web developer on Hacker News: “Be sure that you understand the concept of HSTS! Simply copy/pasting the example from this article will completely break subdomains that are not HTTPS enabled and preloading will break it permanently. I wish the authors made that more clear. Don't use includesubdomains and preload unless you know what you are doing.” CSP (Content Security Policy) The security model for the web is based on the same-origin policy. This means that a web browser will only allow a script in the preceding web page to access data from the following page if both pages have the same origin. This policy is bypassed by attacks like cross-site scripting (XSS), in which malicious scripts are injected into trusted websites. You can use CSP, which will help in significantly minimizing the risk and impact of XSS attacks. You can define CSP using the following meta element in your server HTML or via HTTP headers: Content-Security-Policy: upgrade-insecure-requests This directive (upgrade-insecure-requests) upgrades all the HTTP requests to HTTPS requests. CSP offers a wide variety of policy directives that give you the control of defining the source from where a page is allowed to load a resource. The ‘script-src’ directive can prove to be very helpful in case of XSS attack, which controls a set of script-related privileges for a specific page. Other examples include ‘img-src’, ‘media-src’, ‘object-src’, and more. Before you implement CSP, take into account the following advice from a Hacker News user: “CSP can be really hard to set up. For instance: if you include google analytics, you need to set a script-src and a img-src. The article does a good job of explaining you should use CSP monitoring (I recommend sentry), but it doesn't explain how deceptive it can be. You'll get tons of reports of CSP exceptions caused by browsers plugins that attempt to inject CSS or JS. You must learn to distinguish which errors you can fix, and which are out of your control. Modern popular frontend frameworks will be broken by CSP as they rely heavily on injecting CSS (a concept known as JSS or 'styled components'). As these techniques are often adopted by less experienced devs, you'll see many 'solutions' on StackOverflow and Github that you should set unsafe-inline in your CSP. This is bad advise as it will basically disable CSP! I have attempted to raise awareness in the past but I always got the 'you're holding it wrong' reply (even on HN). The real solution is that your build system should separate the CSS from JS during build time. Not many popular build systems (such as create-react-app) support this.” Despite these advantages, Judis in his talk highlighted that not many websites have put it to work and merely 6% are using it. He wrote in a post, “To see how many sites serve content with CSP I ran a query on HTTP Archive and found out that only 6% of the crawled sites use CSP. I think we can do better to make the web a safer place and to avoid our users mining cryptocurrency without knowing it.” Cache-Control Judis believes that it is a web developers’ responsibility to ensure that their website or web app is not eating up a user’s data to keep the “web affordable for everybody”. One way to do that is by using the Cache-Control header, which allows you to define response caching policies. This header controls for how long a browser can cache an individual response. Here is how you can define it: Cache-Control: max-age=30, public These were some of the headers that Judis highlighted in his post. The article further explains the use of other headers like Accept-Encoding, Feature-Policy, and more. Go ahead and give it a read! All about Browser Fingerprinting, the privacy nightmare that keeps web developers awake at night How to build a real-time data pipeline for web developers – Part 2 [Tutorial] How to build a real-time data pipeline for web developers – Part 1 [Tutorial]  

Last year in December, Mozilla announced its collaboration with Qualcomm to create an ARM64-native build of Firefox targeting Snapdragon-powered Windows 10 ‘Always On, Always Connected’ PCs. Yesterday, it shared that this Firefox build is now available in their Beta release channel. This release builds on top of Firefox Quantum, which is designed to efficiently work on multiple core processors. With this release, Mozilla aims to take this multi-paradigm one step further by making Firefox Quantum efficient for octa-core CPUs available from Qualcomm. To give users “a fast, personal, and convenient experience”, it takes advantage of Rust’s safe concurrency property to divide browsing tasks across the cores Qualcomm processors are being widely used in smartphones. At the Snapdragon Tech Summit 2018, the company shared that they are now moving into the PC space. They introduced the Always on, Always Connected PC category that aims to provide users smartphone-like features on a PC. These features include continuous connectivity and lightning-fast LTE speeds, multi-day battery life, location awareness, among others. Along with this, Qualcomm also announced that they are working with developers to bring a wide range of software applications that will be natively supported in these PCs and one of them was Firefox. Chuck Harmston, Mozilla's senior product manager for the Firefox Arm project, said, "One of the most compelling features of Windows laptops using Qualcomm's Snapdragon chipset is the battery life it enables, measured in days, rather than hours. We've been working hard to take advantage of that, offloading discrete tasks to small chips to use less power ... This was a big project that spanned the Firefox organization, touching almost every part of the browser." Developers are encouraged to try this latest Firefox beta release on their Snapdragon Windows 10 devices and submit bug and crash reports to Mozilla. To know more, check out the official announcement by Mozilla. Mozilla developers have built BugBug which uses machine learning to triage Firefox bugs Mozilla adds protection against fingerprinting and Cryptomining scripts in Firefox Nightly and Beta Mozilla is exploring ways to reduce notification permission prompt spam in Firefox  

Yesterday, Microsoft released the first preview builds of its Chromium-powered Edge browser for Windows 10. This comes after Microsoft announced last year in December that it will be adopting the Chromium open source project in the development of Microsoft Edge for desktop. You can download these preview builds for testing from the Microsoft Edge Insider site. The new builds are available through three different Microsoft Edge Insider Channels: Beta, Canary, and Developer. Canary builds are the ones that will receive updates every night. Developer builds are much more stable than the Canary builds and will be updated weekly. Beta builds are the most stable ones as compared to the three and will receive updates every 6 weeks. Source: Microsoft Right now, Microsoft is only opening the Developer and Canary channels. Though the company was not so clear about the timeline in the announcement, it does promises that the Beta builds and support for Mac and all the other supported versions of Windows will come in the future. However, there is no mention of whether this new overhauled Microsoft Edge will support Linux. In these preview builds, the team has mostly focussed on the fundamentals. So, current users will not see an extensive range of features and language support. These new Chromium-based Microsoft Edge preview builds do look strikingly similar to Google Chrome. Among the similarities include subtle design finishes, a dark mode, and the ability to manage your sign-in profile. In this Chromium-based Edge implementation, Microsoft has removed or replaced about 50 services that are included in Chromium. Some of them are Google Now, Google Cloud Messaging, and Chrome-OS related services. More details regarding the updates will be shared during a BlinkOn 10 keynote today. These preview builds also bring support for an expanded selection of extensions. Users will no longer have to just choose from the limited set of extensions available on Microsoft’s store as extensions from other third-party stores like Chrome Web Store are also supported. Since this is based on Chromium, it also comes with support for Progressive Web Apps and supports the same developer tools as Chromium. Microsoft is working closely with the team at Google and hopes to work with the broader Chromium community going forward. Their latest contributions to the Chromium open source project includes in areas like accessibility, touch, ARM64, and others. In the future, it plans to introduce smooth scrolling, a reading view free of distractions, grammar tools, and Microsoft Translator integration. Users who have tested these preview builds are finding it unsurprisingly very similar to Chrome. One of the users are Reddit remarks, “To the surprise of no one, its basically chrome. Even my google account came in logged in automatically, same recent sites etc. I wonder if the roadmap will include things like dark mode, I never used the annotations feature so can't vouch much for it. I'm yet to try to make a MS Teams call but looking good so far.” The Verge, after testing the preview builds, shared that the Chromium-powered Edge is showing even better performance than Google Chrome. Many users are also saying that instead of joining hands with Google, Microsoft could have instead gone with Firefox to make the web fair and accessible. “I wish they've would have gone with Firefox's Quantum, in order to try and at least balance out web market shares. MSFT no longer has any leverage in the web, so trying to keep it fair and accessible (no browser monopolies) should be a priority for them (especially since they have quite a few web platforms like office 365),” adds a redditor. To read the official announcement, check out the Microsoft blog. Microsoft’s #MeToo reckoning: female employees speak out against workplace harassment and discrimination Microsoft, Adobe, and SAP share new details about the Open Data Initiative Microsoft reportedly ditching EdgeHTML for Chromium in the Windows 10 default browser

Last year in October, the Node.js and JS Foundations announced their intent to create a joint organization. After six months of analyzing community feedback, deliberation, and collaboration, the two foundations finally merged into the OpenJS Foundation on Tuesday. https://twitter.com/nodejs/status/1105500455864598528 Dave Methvin, Technical Advisory Committee Chair, JS Foundation, explaining the motivation behind this merger said in the announcement, “This is an exciting step forward for the entire open source JavaScript community, as it strengthens the impact of our collective efforts under one united Foundation. A new merged Foundation is able to better serve the community and members to grow the JavaScript ecosystem from a technology and standards perspective.” The OpenJS Foundation is backed by 30 corporate and end-user members including Google, Microsoft, IBM, PayPal, and GoDaddy. It currently hosts a wide range of projects including Appium, Dojo, jQuery, Node.js, webpack, and many more. Goals of the OpenJS Foundation Providing resources and accelerating the development The OpenJS Foundation is responsible for expanding the JavaScript community and accelerating the development of JavaScript and other key ecosystem projects. It will provide financial and marketing resources to support projects and working groups. It will act as one stop for all projects within the open JavaScript community for fulfilling their infrastructure, technical, and marketing needs. Combined governance structure The merger will provide a combined governance structure to enable all projects, regardless of their sizes, to benefit from experienced mentors as they progress through the project life cycle. It will encourage collaboration across the JavaScript ecosystem and affiliated standard bodies to create a single home for any project in the JavaScript ecosystem. Improved membership experience The OpenJS Foundation brings together the goals of both the JavaScript and Node.js foundations, so companies or organizations that want to support JavaScript will no longer have to choose between the two. This will also eliminate the operational redundancies between the two organizations and streamline the experience for member companies that provide financial support. Additionally, it will provide a single point of entry to new and prospective members for getting involved in open source JavaScript project and create a simpler and more engaging experience for them. Many Twitter users were excited about this announcement and believe that this a major step towards the overall growth of the JavaScript open source ecosystem. https://twitter.com/gauravseth/status/1105888912608681984 https://twitter.com/agoric/status/1105534569992806400 To know more in detail, check out the official announcement. Node.js and JS Foundation announce intent to merge; developers have mixed feelings Node.js announces security updates for all their active release lines for August 2018 Why use JavaScript for machine learning?  

Yesterday, npm Inc., the provider of the world’s largest software registry, announced npm Enterprise, which will be your company’s very own npm registry. This new service is designed for private registry hosting, workflow integrations, and provides compliance features for large companies. Bryan Bogensberger, CEO of npm Inc, said in a statement, “Approximately 100% of the world’s enterprises acquire over 97% of their JavaScript from the npm Public Registry, making the introduction of npm Enterprise essential for the professionalization of JavaScript development. With npm Enterprise, we are giving JavaScript developers the npm tools they love while providing the enterprise with enhanced visibility, security, and control. The result: happiness throughout organizations everywhere.” The npm Enterprise service comes with the following features and advantages: Companies will have a “companyname.npme.io” website with support for industry-standard SSO authentication to control developer access and other permissions. Allows easy code discovery and sharing within a company. You can securely deploy a package. Access to unlimited Orgs and scopes. Orgs allows a team of contributors to read, write, and publish public or private scoped packages. Users will able to access all the packages that are available in the public registry. It provides audit reports that contain tables of information about security vulnerabilities in your project’s dependencies. With the help of these audit reports, you can fix the vulnerability or troubleshoot further. To avoid any kind of conflict, teams can use the unlimited namespaces npm Enterprise comes with to share and manage code. The npm Enterprise service provides three roles: Billing Manager, Admin user, and End-user. The admin users will have the most far-reaching permissions on the Enterprise instance. They will manage instance settings, Orgs, users, and packages. The billing manager will be responsible for updating the payment method for your Enterprise instance. To learn more about npm Enterprise, visit npm’s official website. npm JavaScript predictions for 2019: React, GraphQL, and TypeScript are three technologies to learn npm v6 is out! npm at Node+JS Interactive 2018: npm 6, the rise and fall of JavaScript frameworks, and more

Last year in November at the Chrome Dev Summit keynote, Google introduced .dev, a domain dedicated to developers and technology. The registration process has already started on Feb 16 and the team is set to launch its Early Access Program. The registration process has already started on Feb 16. According to the timeline shared at the Chrome Dev Summit, the Early Access Program will start on Feb 19th at 8:00 am PST to February 28th at 7:59 am PST. Under this program, users can register available .dev domains by giving an extra fee. This fee will decrease as we get closer to the General Availability phase, which starts February 28 onwards. After registering the domain, users will be required to pay $12/year cost for .dev domains. In addition to a dedicated space for developers, this domain will provide built-in security, as it is included on the HSTS (HTTP Strict Transport Security) preload list. This essentially means that all the connections to .dev websites and pages will be made using HTTPS. Looking at Google’s track record of killing its products over time, some Hacker News users were little skeptical about this service. One user commented, “I wouldn't lease the domain through Google domains. Use a different registrar --- if possible, one that you'll be able to trust. That registrar will work with the registry of the TLD, which would be google in this case, and has a much better chance of actually resolving issues than if you were a direct customer of Google Domains.” Another user said, “They have a well-established track record of enthusiastically backing exciting new projects way outside of their core competency just to dump them like hot garbage several years later...It doesn't seem like a smart move to lease a domain from a politically active mega-monopoly that might decide to randomly become your competitor in 2 years.”  Countering this argument, one of the Google developers from the team launching .dev said,  “You'll be glad to know that TLDs can't simply be discontinued like other products might be. ICANN doesn't allow it. The procedures in place preventing a live TLD from shutting down are called EBERO.” Read more about the .dev domain on its official website. Chromium developers propose an alternative to webRequest API that could result in existing ad blockers’ end Google Chrome developers “clarify” the speculations around Manifest V3 after a study nullifies their performance hit argument Regulate Google, Facebook, and other online platforms to protect journalism, says a UK report

On Monday, Google announced that it has partnered with Automattic Inc., the parent company of WordPress.com, to develop an advanced open-source publishing and revenue-generating platform for news organizations named Newspack. Under the Google News Initiative, they have invested $1.2 million towards their efforts in building this platform. The purpose of this platform is to help journalists put their full energy in covering stories instead of worrying about designing websites, configuring CMSes, or building commerce systems. Google mentioned in the post, “It is trying to help small publishers succeed by building best practices into the product while removing distractions that may divert scarce resources. We like to call it "an opinionated CMS:” it knows the right thing to do, even when you don’t.” It will also provide publishers full access to all the plugins created by the WordPress developer community. Automattic, in an announcement, called for small and medium-sized digital news organizations to become charter participants in the development of Newspack. If you want to become one of the partners, you can fill in the form issued by Automattic, which is due by 11:59 p.m. Eastern Time (UTC -5:00) on February 1. The platform’s beta version is estimated to be released near the end of July and will be made available to publishers globally later this year. To get a better idea of the features and capabilities needed by publishers and their business impact, Automattic will be working with Spirited Media and News Revenue Hub. Spirited Media operates local digital news sites in Denver, Philadelphia, and Pittsburgh, and News Revenue Hub provides revenue solutions for digital publishers. In addition to Google, other funding organizations for this platform include The Lenfest Institute for Journalism, ConsenSys, the organization backing Civil Media, and The John S. and James L. Knight Foundation. WordPress 5.0 (Bebo) released with improvements in design, theme and more Introduction to WordPress Plugin Google and Waze share their best practices for canary deployment using Spinnaker

DPAGE is a web page builder which developers can use to get simple web pages up and running on Blockstack's decentralized internet. DPAGE is built on top of Blockstack, an infrastructure in which you can build decentralized blockchain applications. You need a Blockstack account to log into and start using DPAGE. The Blockstack ID used to log in is stored on the blockchain. All user data is stored on a Gaia node which you can choose. This decentralized setup gives users several advantages over a conventional centralized app: Your data is yours: After using DPAGE, if you don't like it then you can create your own app. Alternatively, you can use any other web page builder and all your data will be with you and not owned by any web page/app. Users are not restricted by any vendor lock-ins. A Blockstack ID is virtually impossible to block unlike centralized identities. Google or Facebook IDs can be blocked by companies. All private user data is encrypted end-to-end. Which means that no one else can read it including the DPAGE creators. The data stored is not stored with DPAGE The profile details and user data are stored on a Blockstack’s Gaia storage hub by default. DPAGE itself doesn't store any user data on its servers. You can also run your own storage hub on a server of choice. They store data with Blockstack and they store it on ‘personal data lockers built on Google, AWS, and Azure’. It is safer than some centralized web pages As all private data is encrypted, it's more difficult for hackers to steal user data from the decentralized app. There is no central database that contains all the data, so hackers also have less incentive to hack into DPAGE. However, DDOS attacks are a possibility if the hackers target a specific Gaia hub. There is no user-specific tracking DPAGE only collects non-identifiable analytics of the users for improving the service. The service itself doesn't store or read private pages. There are some positive reactions on Hacker news: “This indeed a seriously cool product, hope more people realize it.” Another comment says: “Nice, I think this is what the web needs, a Unix approach so tools can be built on top and hosts are interchangeable.” To check out DPAGE, visit their website. The decentralized web – Trick or Treat? Origin DApp: A decentralized marketplace on Ethereum mainnet aims to disrupt gig economy platforms like Airbnb and Uber Microsoft announces ‘Decentralized Identity’ in partnership with DIF and W3C Credentials Community Group

Kweb is a library using which you can easily build web applications in the Kotlin programming language. It basically eliminates the separation between browser and server from the programmer’s perspective. This means that events that only manipulate the DOM don't need to do a server-roundtrip. As Kweb is written in Kotlin, users should have some familiarity with the Kotlin and Java ecosystem. Kweb allows you to keep all of the business logic in the server-side and enables the communication with the web browser through efficient websockets. To efficiently handle asynchronicity, it takes advantage of Kotlin’s powerful new coroutines mechanism. It also allows keeping consistent state across client and server by seamlessly conveying events between both. What are the features of Kweb? Makes the barrier between the web server and web browser mostly invisible to the programmer. Minimizes the server-browser chatter and browser rendering overhead. Supports integration with some powerful JavaScript libraries like Semantic, which is a UI framework designed for theming. Allows binding DOM elements in the browser directly to state on the server and automatically update them through the observer and data mapper patterns. Seamlessly integrates with Shoebox, a Kotlin library for persistent data storage that supports views and the observer pattern. Easily add to an existing project. Instantly update your web browser in response to code changes. The Kweb library is distributed via JitPack, a novel package repository for JVM and Android projects. Kweb takes advantage of the fact that in most web apps, logic occurs in the server side and the client can’t be trusted. This library is in its infancy but still works well enough to demonstrate that the approach is practical. You can read more about Kweb on its official website. Kotlin based framework, Ktor 1.0, released with features like sessions, metrics, call logging and more Kotlin 1.3 released with stable coroutines, multiplatform projects and more KotlinConf 2018: Kotlin 1.3 RC out and Kotlin/Native hits beta

Earlier this week it was reported that Microsoft is ditching EdgeHTML for Chromium in the Windows 10 default browser, Edge. Now Microsoft has confirmed this officially yesterday in a blog post. The blog post by Joe Belfiore, VP of Windows stated: “we intend to adopt the Chromium open source project in the development of Microsoft Edge on the desktop to create better web compatibility for our customers and less fragmentation of the web for all web developers.” What does this shift to Chromium mean? Gradually, over the course of 2019, Edge will have under the hood changes. These changes will be developed in open source and the key aspects are: The development of Microsoft Edge will move to a Chromium-compatible web platform for the desktop version. They intend to align Microsoft Edge simultaneously with web standards and also with other Chromium-based browsers. This improves compatibility for everyone and make testing easier for developers. Working on an open-source engine like Chromium allows Microsoft to deliver more frequent updates to Edge. Microsoft Edge is currently available on Windows, this shift can get Edge running on other OSes like Linux and macOS. Microsoft also intends to contribute more to the open-source engine Chromium to make Chromium-based browsers better on Windows devices. A user doesn't have to worry much about this change. If anything this might bring Chrome-like extensions to Edge. If you’re a web developer, you can go to the Microsoft Insider website to try preview builds and contribute. Currently, Chrome holds arguably most of the market share in the browser space. Microsoft had problems working with EdgeHTML and building a browser that would be widely adopted. Perhaps basing Edge on Chromium will actually make people want to use Chrome. Now two tech behemoths will use the same engine to create their browser. This could mean more competition within the Chromium ecosystem. Where does this leave Mozilla Firefox that uses the Gecko engine and Opera that uses Blink? For more details about the engine shift, visit the Microsoft website. Microsoft reportedly ditching EdgeHTML for Chromium in the Windows 10 default browser Firefox Reality 1.0, a browser for mixed reality, is now available on Viveport, Oculus, and Daydream Microsoft becomes the world’s most valuable public company, moves ahead of Apple

According to a story by Windows Central, Microsoft is working on a Chromium based web browser. This will likely be a replacement to their current web browser on Windows 10, Microsoft Edge. Edge never took off the Edge Microsoft Edge was launched in 2015 built from scratch with EdgeHTML. Microsoft tried to get it into adoption by making Windows 10 update free for a limited time. However, the browser was not well received at the early stage itself due to a large number of issues. Since then it has not been very stable driving developers and users away from it. Due to this, Microsoft is reportedly abandoning Edge and the EdgeHTML framework for Chromium. Chromium is a rendering engine used in Google Chrome. The new browser’s name is codenamed Anaheim and will be replacing Edge as the default browser in Windows. It is not known if Edge will be renamed and if the UI will be different. But EdgeHTML will no longer be used in Windows 10’s default browser. Using the Chromium engine instead Using Chromium means that the websites on Windows 10 default browser will load as they do on Google Chrome. Default browser users will no longer have to face the loading and connectivity issues that plagued EdgeHTML based Microsoft Edge. For smartphones, nothing will change much as Edge on smartphones already use platform specific engines. Recently, 9to5Google reported that Microsoft engineers are committing code to the Chromium project. This would suggest that they are working on their own browser by using Chromium instead of EdgeHTML. The browser may likely be out next year. Public reactions A comment on hacker news reads: “You[web developers] don't test your work in Edge and because you tell all your friends and family to use Chrome instead of Edge. So stop complaining about monoculture. Many of you helped create it.” Some sarcasm thrown in another comment: “I test my app in Edge, every time a new version is released. When it inevitably fails, I shake my head in disbelief that Microsoft still hasn't paid a dev to spend a couple months fixing their IndexedDB implementation, which has been incomplete since the IE days. Can't expect a small rag-tag group like Microsoft to compete with a rich corporate behemoth like Mozilla, I guess :)” Another comment says: “How can I test Edge when Microsoft don't release it for Mac and Linux? A browser for a single OS? Talk about monoculture.” https://twitter.com/headinthebox/status/1069796773017710592 Another Tweet suggests that this move towards Chromium is about ElectronJS stronghold over app development and not about Microsoft wanting a Chrome like browser experience on its default browser: https://twitter.com/SwiftOnSecurity/status/1069776335336292352 After years of Internet Explorer being ridiculed and Edge not being the success they hoped for, it would be nice to see the Windows default browser catching up with the likes of Chrome and Firefox. Introducing Howler.js, a Javascript audio library with full cross-browser support Firefox Reality 1.0, a browser for mixed reality, is now available on Viveport, Oculus, and Daydream Microsoft becomes the world’s most valuable public company, moves ahead of Apple

Yesterday, Google announced the release of Chrome 70. This version comes with support for Desktop Progressive Web apps on Windows and Linux and for public key credentials. Also, web Bluetooth is now supported for Windows 10 users. Support for Desktop Progressive Web Apps on Windows and Linux You can now install Desktop Progressive Web Apps on Windows and Linux. Once installed, they’re launched from the Start menu, and run like any other installed app, without an address bar or tabs. Credential Management API supports Public Key Credentials Signing in has become very simple with the introduction of the Credential Management API. It enables the communication between your site and the browser’s credential manager or federated account services like Google and Facebook to sign in. One more credential type named, Public Key Credential is introduced. It allows web applications to create and use, strong, cryptographically attested, and application-scoped credentials to authenticate users. Named workers With the help of workers, you can move JavaScript off the main thread and into the background. This will keep your site interactive as it will prevent the main thread from locking up when it is running an expensive or complex JavaScript computation. A new name attribute is added for workers in Chrome 70, which is specified by an optional argument on the constructor: const url = '/scripts/my-worker.js'; const wNYC = new Worker(url, {name: 'NewYork'}); const oSF = {name: 'SanFrancisco'}; const wSF = new Worker(url, oSF); You can now easily distinguish dedicated workers by name when you have multiple workers with the same URL. Miscellaneous updates Web Bluetooth is available for Windows 10 users. It allows your site to securely communicate with nearby user-selected Bluetooth devices. Chrome can now send intervention and deprecation messages to your servers using the Report-To HTTP Response header field or surface them in the ReportingObserver interface. Deprecations in Chrome 70 AppCache from insecure contexts removed AppCache potentially allows persistent online and offline cross-site scripting attacks, when used over insecure contexts. To avoid these attacks, AppCache is now only supported on origins that serve over HTTPS. Developers are advised to use service workers as an alternative. Gamepads.item() deprecated and removed The legacy item() accessor is no longer a part of the Gamepads array. This change improves compatibility with Firefox, the only browser to implement GamepadList. SpeechSynthesis.speak() without user activation deprecated Now an error is thrown by the speechSynthesis.speak() function if a document has not received a user activation. You can expect its removal in Chrome 71 by late November. They have listed all the deprecations in Chrome 70 on their official website. Read the full list of changes on the Google Developers website. Chrome 69 privacy issues: automatic sign-ins and retained cookies; Chrome 70 to correct these Google announces Chrome 67 packed with powerful APIs, password-free logins, PWA support, and more Google Chrome, Mozilla Firefox, and others to disable TLS 1.0 and TLS 1.1 in favor of TLS 1.2 or later by 2020

After the release of Meteor 1.7 in June this year, the Meteor community released Meteor 1.8 yesterday. This version eliminates many of the performance problems in Meteor 1.7. They have addressed the technical debt of compiling an additional client bundle which had led to slow build times in Meteor 1.7. Here’s what all has been added and improved in this latest release. Improved build time In addition to the web.browser and web.cordova bundles, Meteor 1.7 introduced a new client bundle called web.browser.legacy. This addition of an extra bundle resulted in increased client build and rebuild times. Usually, developers spend most of their time testing the bundle in development and the legacy bundle provides a safe fallback in production. Meteor 1.8 takes advantage of this fact and cleverly postpones building the legacy bundle until just after the development server restarts. Development can continue as soon as the modern bundle has finished building. As the legacy build happens during a time when the build process would otherwise be completely idle, the impact of the legacy build on server performance is minimal. Still, the legacy bundle gets rebuilt regularly, so any legacy build errors will be surfaced in a timely fashion. A new mechanism for compiling unused files Meteor’s compiler plugins compile every file they receive, regardless of whether the file will ever actually be imported. To avoid this unnecessary compilation of unused files Meteor 1.8 has finally introduced a simple mechanism. Expensive compilation work will now be delayed by the compiler plugins that call inputFile.addJavaScript or inputFile.addStylesheet. This will be done by passing partial options ({ path, hash }) as the first argument, followed by a callback function as the second argument. This callback function will be called by the build system once it knows the module will be included in the bundle. Though the compiler plugin will process every possible file, any unused files will now be ignored by the build system, and their uncalled callbacks will be discarded after the bundle is built. Create Meteor apps with a simple command You can now easily create new Meteor apps with React instead of Blaze using the following command: meteor create --react new-react-app Overriding problematic version constraints from packages A new syntax is introduced for the .meteor/packages file for overriding problematic version constraints from packages you do not control. If a top-level package version constraint in .meteor/packages ends with a  ‘!’ character, any other (non-!) constraints on that package elsewhere in the application will be weakened. Which means, any version of the package that is not less than the constraint will be accepted, regardless of whether the major/minor versions actually match. For instance, using both CoffeeScript 2 and practicalmeteor:mocha used to be difficult because of the api.versionsFrom("1.3") statement. This statement constrained the coffeescript package to version 1.x. In Meteor 1.8, if you want to update coffeescript to 2.x, you can relax the practicalmeteor:mocha constraint by putting coffeescript@2.2.1_1! in the .meteor/packages file. Dependency upgrades Upgraded to Babel 7 You can get the benefits of non-beta Babel 7 by updating to Meteor 1.8. Install the latest version of @babel/runtime by running the following command: meteor npm install @babel/runtime@latest Upgraded to Mongo 4 Meteor 1.8 comes with MongoDB 4.0.2, a major upgrade from version 3.6.4 in Meteor 1.7. Your local development database will now use version 4.0, though the mongodb@3.1.6 driver will connect to production databases going all the way back to Mongo 2.6. The major advantage of MongoDB 4.0 is its support for multi-document transactions, which are now supported by Meteor’s oplog tailing system. Node.js 8.11.4 for now Although Node 8.12.0 has been released, Meteor 1.8 still supports Node 8.11.4, due to concerns about excessive garbage collection and CPU usage in production. If you want to start using Node.js 8.12.0, you can contribute to the Meteor 1.8.1 pre-release process. In order to update to Meteor 1.8.1, run the following command: meteor update --release 1.8.1-beta.n Read the full change list on Meteor’s GitHub repository and also read the release announcement on Medium. Meteor 1.7 released with modern and legacy browser support Building a real-time dashboard with Meteor and Vue.js The Ember project announces version 3.4 of Ember.js, Ember Data, and Ember CLI

Meteor 1.7 released to support both modern as well as legacy browsers that will keep themselves updated as and when new features arrive. It also provides options for developers to selectively compile their node-modules before publishing it on npm. When Meteor was initially released in 2012, it was considered as a game-changing framework for developers to use JavaScript on the client as well as on the server-side. This gave birth to the “Isomorphic” revolution that allows developers to break from the shackles of rendering pages on the server-side. Over the years Meteor has followed an incremental update plan without drastically changing the framework, a move which developers have really appreciated, and the trend follows for the 1.7 release as well. Notable features in Meteor 1.7 Differential modern/legacy browser support When a new version for a browser is shipped, it comes with all the latest features of ECMAScript packed inside it. This has a very significant impact on web development as developers can start using the latest standards to ease the process and write more fluid and performant code. But it is not always possible, using these new features means leaving behind the users who are still using the old browser, posing a dilemma for developers. Well, Meteor 1.7 brings the best of both worlds by automatically building two sets of client-side assets, one tailored to the capabilities of the modern browser, and the other designed to work equally well on all supported browsers. This will help legacy browsers continue to work exactly the same as they were before. Selective compilation of node modules The npm packages are precompiled before they are published, so users of these packages have to settle for the compilation strategy decided by the author. Meteor 1.7, allows you to control how an npm package is compiled, or compile the package for modern/legacy browsers and Node. This lets application developers take complete control of the npm modules they are using. Most of the new features in Meteor 1.7 can be applied in a backward compatible manner or they can be opted out, it is completely a developer’s choice. For a complete breakdown of the new Meteor features, refer to this Official Meteor blog page.