Tech News - Web Development

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

Ionic Framework today released Ionic Framework 4.0. The release is a complete rebuild of the popular JavaScript framework for developing mobile and desktop apps. Although Ionic has, up until now, Ionic was built using Angular components, this new version has instead been built using Web Components. This is significant, as it changes the whole ball game for the project. It means Ionic Framework is now an app development framework that can be used alongside any front end frameworks, not just Angular. The shift away from Angular makes a lot of sense for the project. It now has the chance to grow adoption beyond the estimated five million developers around the world already using the framework. While in the past Ionic could only be used by Angular developers, it now opens up new options for development teams - so, rather than exacerbating a talent gap in many organizations, it could instead help ease it. However, although it looks like Ionic is taking a significant step away from Angular, it's important to note that, at the moment, Ionic Framework 4.0 is only out on general availability for Angular - it's still only in Alpha for Vue.js and React. Ionic Framework 4.0 and open web standards Although the move to Web Components is the stand-out change in Ionic Framework 4.0, it's also worth noting that the release has been developed in accordance with open web standards. This has been done, according to the team, to help organizations develop Design Systems (something the Ionic team wrote about just a few days ago) - essentially, using a set of guidelines and components that can be reused across multiple platforms and products to maintain consistency across various user experience touch points. Why did the team make the changes to Ionic Framework 4.0 that they did? According to Max Lynch, Ionic Framework co-founder and CEO, the changes present in Ionic Framework 4.0 should help organizations achieve brand consistency quickly, and to give development teams the option of using Ionic with their JavaScript framework of choice. Lynch explains: "When we look at what’s happening in the world of front-end development, we see two major industry shifts... First, there’s a recognition that the proliferation of proprietary components has slowed down development and created design inconsistencies that hurt users and brands alike. More and more enterprises are recognizing the need to adopt a design system: a single design spec, or library of reusable components, that can be shared across a team or company. Second, with the constantly evolving development ecosystem, we recognized the need to make Ionic compatible with whatever framework developers wanted to use—now and in the future. Rebuilding our Framework on Web Components was a way to address both of these challenges and future-proof our technology in a truly unique way." What does Ionic Framework 4.0 tell us about the future of web and app development? Ionic Framework 4.0 is a really interesting release as it tells us a lot about where web and app development is today. It confirms to us, for example, that Angular's popularity is waning. It also suggests that Web Components are going to be the building blocks of the web for years to come - regardless of how frameworks evolve. As Lynch writes in a blog post introducing Ionic Framework 4.0, "in our minds, it was clear Web Components would be the way UI libraries, like Ionic, would be distributed in the future. So, we took a big bet and started porting all 100 of our components over." Ionic Framework 4.0 also suggests that Progressive Web Apps are here to stay too. Lynch writes in the blog post linked to above that "for Ionic to reach performance standards set by Google, new approaches for asynchronous loading and delivery were needed." To do this, he explains, the team "spent a year building out a web component pipeline using Stencil to generate Ionic’s components, ensuring they were tightly packed, lazy loaded, and delivered in smart collections consisting of components you’re actually using." The time taken to ensure that the framework could meet those standards - essentially, that it could support high performance PWAs - underscores that this will be one of the key use cases for Ionic in the years to come.  

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

Yesterday, at the Node+JS Interactive in Montreal, the OpenJS Foundation announced the acceptance of Electron into the Foundation’s incubation program. The OpenJS Foundation provides vendor-neutral support for sustained growth within the open source JavaScript community. It's supported by 30 corporate and end-user members, including GoDaddy, Google, IBM, Intel, Joyent, and Microsoft. Electron is an open source framework created for building desktop apps using JavaScript, HTML, and CSS, it is based on Node.js and Chromium. Additionally, Electron is widely used on many well-known applications including Discord, Microsoft Teams, OpenFin, Skype, Slack, Trello, Visual Studio Code, etc. “We’re heading into 2020 excited and honored by the trust the Electron project leaders have shown through this significant contribution to the new OpenJS Foundation,” said Robin Ginn, Executive Director of the OpenJS Foundation. He further added, “Electron is a powerful development tool used by some of the most well-known companies and applications. On behalf of the community, I look forward to working with Electron and seeing the amazing contributions they will make.” Electron’s cross-platform capabilities make it possible to build and run apps on Windows, Mac, and Linux computers. Initially developed by GitHub in 2013, today the framework is maintained by a number of developers and organizations. Electron is suited for anyone who wants to ship visually consistent, cross-platform applications, fast and efficiently. “We’re excited about Electron’s move to the OpenJS Foundation and we see this as the next step in our evolution as an open source project,” said Jacob Groundwater, Manager at ElectronJS and Principal Engineering Manager at Microsoft. “With the Foundation, we’ll continue on our mission to play a prominent role in the adoption of web technologies by desktop applications and provide a path for JavaScript to be a sustainable platform for desktop applications. This will enable the adoption and development of JavaScript in an environment that has traditionally been served by proprietary or platform-specific technologies.” What this means for developers Electron joining the OpenJS Foundation does not change how Electron is made, released, or used — and does not directly affect developers building applications with Electron. Even though Electron was originally created at GitHub, it is currently maintained by a number of organizations and individuals. In 2019, Electron codified its governance structure and invested heavily into formalizing how decisions affecting the entire project are made. The Electron team believes that having multiple organizations and developers investing in and collaborating on Electron makes the project stronger. Hence, lifting Electron up from being owned by a single corporate entity and moving it into a neutral foundation focused on supporting the web and JavaScript ecosystem is a natural next step as they mature in the open-source ecosystem. To know more about this news, check out the official announcement from the OpenJS Foundation website. The OpenJS Foundation accepts NVM as its first new incubating project since the Node.js Foundation and JSF merger Node.js and JS Foundations are now merged into the OpenJS Foundation Denys Vuika on building secure and performant Electron apps, and more

Photon Micro is an open-source, lightweight and modular GUI, which comprises of fine-grained and flyweight ‘elements’. It uses a declarative C++ code with a heavy emphasis on reuse, to form deep element hierarchies. Photon has its own HTML5 inspired canvas drawing engine and uses Cairo as a 2D graphics library. Cairo supports the X Window System, Quartz, Win32, image buffers, PostScript, PDF, and SVG file output. Joel de Guzman, the creator of Photon Micro GUI, and the main author of the Boost.Spirit Parser library, the Boost.Fusion library and the Boost.Phoenix library says, “One of the main projects I got involved with when I was working in Japan in the 90s, was a lightweight GUI library named Pica. So I went ahead, dusted off the old code and rewrote it from the ground up using modern C++.” The Photon Micro GUI client can use the following gallery code: Image Source: Cycfi This pops up a warning: Image Source: Cycfi Some highlights of Photon Micro GUI Modularity and reuse are two important design aspects of the Photon Micro GUI. It is supported by the following functionalities: Share Photon Micro GUI can be shared using std::shared_ptr. Hold Hold can be used to share an element somewhere in the view hierarchy. Key_intercept It is a delegate element that intercepts key-presses. Fixed_size Elements are extremely lightweight, fixed_size fixes the size of the GUI contained element. margin, left_margin These are two of the many margins, including right_margin, top_margin, etc. It adds padding around the element like the margin adds 20 pixels all around the contained element. The left_margin adds a padding of 20 pixels to separate the icon and the text box. vtile, htile Vertical and horizontal fluid layout elements allocate sufficient space to contained elements. This enables stretchiness, fixed sizing, and vertical and horizontal alignment, to place elements in a grid. Stretchiness is the ability of elements to stretch within a defined minimum and maximum size limit. Guzman adds, “While it is usable, and based on very solid architecture and design, there is still a lot of work to do. First, the Windows and Linux ports are currently in an unusable state due to recent low-level refactoring.” Some developers have shown interest in the elements of Photon Micro GUI. https://twitter.com/AlisdairMered/status/1148242189354450944 A user on Hacker News comments, “Awesome, that looks like an attempt to replace QML by native C++. Would be great if there was a SwiftUI inspired C++ UI framework (well, of course C++ might not lend itself so well for the job, but I'm just very curious what it would look like if someone makes a real attempt).” Some users feel that more work needs to be done to make this GUI more accessible and less skeuomorphic. [box type="shadow" align="" class="" width=""]Skeuomorphism is a term most often used in graphical user interface design to describe interface objects that mimic their real-world counterparts in how they appear and/or how the user can interact with them (IDF).[/box] A user says, “Too many skeuomorphic elements. He needs to take the controls people know and understand and replace them with cryptic methods that require new learning, and are hidden from view by default. Otherwise, no one will take it seriously as a modern UI.” Another user on Hacker News adds, “don’t use a GUI toolkit like this, that draws its own widgets rather than using platform standard ones when developing a plugin for a digital audio workstation (e.g. VST or Audio Unit), as this author is apparently doing. Unless someone puts in all the extra effort to implement platform-specific accessibility APIs for said toolkit.” For details about the other highlights, head over to Joel de Guzman’s post. Apple showcases privacy innovations at WWDC 2019: Sign in with Apple, AdGuard Pro, new App Store guidelines and more Google and Facebook allegedly pressured and “arm-wrestled” EU expert group to soften European guidelines for fake news: Open Democracy Report Google I/O 2019 D1 highlights: smarter display, search feature with AR capabilities, Android Q, linguistically advanced Google lens and more  

At the ongoing 2019 Google I/O, Google made a major overhaul to its Flutter UI framework. Flutter is now expanded from mobile to multi-platform. The company released the first technical preview of Flutter for web. The core framework for mobile devices was also upgraded to Flutter 1.5. For desktop, Flutter is being used as an experimental project. It is not production-ready, but the team has published early instructions for developing  apps to run on Mac, Windows, and Linux. An embedding API for Flutter is also available that allows it to be used in scenarios for home and automotives. Google notes, “The core Flutter project has been making progress to enable desktop-class apps, with input paradigms such as keyboard and mouse, window resizing, and tooling for Chrome OS app development. The exploratory work that we did for embedding Flutter into desktop-class apps running on Windows, Mac and Linux has also graduated into the core Flutter engine.” Flutter for Web Flutter for web allows web-based applications to be built using the Flutter framework. Per Google, with Flutter for web you can create “highly interactive, graphically rich content,” though it plans to continue evolving this version with a “focus on performance and harmonizing the codebase.” It allows developers to compile existing Flutter code written in Dart into a client experience that can be embedded in the browser and deployed to any web server. Google teamed up with the New York Times to build a small puzzle game called Kenken as an early example of what can be built using Flutter for Web. This game uses the same code across Android, iOS, the web and Chrome OS. Source: Google Blog Flutter 1.5 Flutter 1.5 hosts a variety of new features including updates to its iOS and Material widget and engine support for new mobile devices types. The latest release also brings support for Dart 2.3 with extensive UI-as-code functionality. It also has an in-app payment library which will make monetizing Flutter based apps easier. Google also showcased an ML Kit Custom Image Classifier, built using Flutter and Firebase at Google I/O 2019. The kit offers an easy-to-use app-based workflow for creating custom image classification models. You can collect training data using the phone’s camera, invite others to contribute to your datasets, trigger model training, and use trained models, all from the same app. Google has also released a comprehensive new training course for Flutter, built by The App Brewery. Their new course is available for a time-limited discount from $199 to just $10. Netizens had trouble acknowledging Google’s move and were left wondering as to whether Google wants people to invest in learning Dart or Kotlin. For reference, Flutter is entirely built in Dart and Google made two major announcements for Kotlin at the Google I/O. Android development will become increasingly Kotlin-first, and Google announcing the first preview of Jetpack Compose, a new open-source UI toolkit for Kotlin developers. A comment on Hacker News reads, “This is massively confusing. Do we invest in Kotlin ...or do we invest in Dart? Where will Android be in 2 years: Dart or Kotlin?” In response to this, another comment reads, “I don't think anyone has a definite answer, not even Google itself. Google placed several bets on different technologies and community will ultimately decide which of them is the winning one. Personally, I think native Android (Kotlin) and iOS (Swift) development is here to stay. I have tried many cross-platform frameworks and on any non-trivial mobile app, all of them cause more problem than they solve.” Another said, “If you want to do android development, Kotlin. If you want to do multi-platform development, flutter.” “Invest in Kotlin. Kotlin is useful for Android NOW. Whenever Dart starts becoming more mainstream, you'll know and have enough time to react to it”, was another user’s opinion. Read the entire conversation on Hacker News. Google launches Flutter 1.2, its first feature update, at Mobile World Congress 2019 You can now permanently delete your location history and web and app activity data on Google Microsoft Build 2019: Microsoft showcases new updates to MS 365 platform with a focus on AI and developer productivity

Last month, the ECMAScript proposal for optional chaining operator reached stage 3 of the TC39 process. This essentially means that the feature is almost finalized and is awaiting feedback from users. The optional chaining operator aims to make accessing properties through connected objects easier when there are chances of a reference or function being undefined or null. https://twitter.com/drosenwasser/status/1154456633642119168 Why optional chaining operator is proposed in JavaScript Developers often need to access properties that are deeply nested in a tree-like structure. To do this, they sometimes end up writing long chains of property accesses. This can make them error-prone. If any of the intermediate references in these chains are evaluated to null or undefined, JavaScript will throw the TypeError: Cannot read property 'name' of undefined error. The optional chaining operator aims to provide a more elegant way of recovering from such instances. It allows you to check for the existence of deeply nested properties in objects. How it works is that if the operand before the operator evaluates to undefined or null, the expression will return to undefined. Or else, the property access, method or function call will be evaluated normally. MDN compares this operator with the dot (.) chaining operator. “The ?. operator functions similarly to the . chaining operator, except that instead of causing an error if a reference is null or undefined, the expression short-circuits with a return value of undefined. When used with function calls, it returns undefined if the given function does not exist,” the document reads. The concept of optional chaining is not new. Several other languages also have support for a similar feature including the null-conditional operator in C# 6 and later, optional chaining operator in Swift, and the existential operator in CoffeeScript. The optional chaining operator is represented by ‘?.’. Here’s how its syntax looks like: obj?.prop       // optional static property access obj?.[expr]     // optional dynamic property access func?.(...args) // optional function or method call Some properties of optional chaining Short-circuiting: The rest of the expression is not evaluated if an optional chaining operator encounters undefined or null at its left-hand side. Stacking: Another property of the optional chaining operator is that you can stack them. This means that you can apply more than one optional chaining operator on a sequence of property accesses. Optional deletion: You can also combine the ‘delete’ operator with an optional chain. Though there is time for the optional chaining operator to land in JavaScript, you can give it try with a Babel plugin. To stay updated with its browser compatibility, check out the MDN web docs. Many developers are appreciating this feature. A developer on Reddit wrote, “Considering how prevalent 'Cannot read property foo of undefined' errors are in JS development, this is much appreciated. Yes, you can rant that people should do null guards better and write less brittle code. True, but better language features help protect users from developer laziness.” Yesterday, the team behind V8, Chrome’s JavaScript engine, also expressed their delight on Twitter: https://twitter.com/v8js/status/1166360971914481669 Read the Optional Chaining for JavaScript proposal to know more in detail. ES2019: What’s new in ECMAScript, the JavaScript specification standard Introducing QuickJS, a small and easily embeddable JavaScript engine Introducing Node.js 12 with V8 JavaScript engine, improved worker threads, and much more

After releasing Angular 7 beta in August, the Angular team released the stable version of Angular 7 yesterday. This version comes with a DoBootstrap interface, an update to XMB placeholders, and updated dependencies: TypeScript 3.1 and RxJS 6.3. Let's see what features this version brings in: The DoBootstrap interface Earlier, there was an interface available for each lifecycle hook but ngDoBootstrap was missing the corresponding interface. This release comes with the new lifecycle hook interface DoBootstrap. Here's an example using DoBootstrap: class AppModule implements DoBootstrap {  ngDoBootstrap(appRef: ApplicationRef) {    appRef.bootstrap(AppComponent);  } } An "original" placeholder value on extracted XMB XMB placeholders (<ph>) are now updated to include the original value on top of an example. By definition, placeholders have one example tag (<ex>) and a text node. The text node will be used as the original value from the placeholder, while the example will represent a dummy value. For example: compiler-cli An option is added to extend angularCompilerOptions in tsconfig. Currently, only TypeScript supports merging and extending of compilerOptions. This update will allow extending and inheriting angularCompilerOptions from multiple files. A new parameter for CanLoad interface In addition to Route, an UrlSegment[] is passed to implementations of CanLoad as a second parameter. It will contain the array of path elements the user tried to navigate to before canLoad is evaluated. This will help users to store the initial URL segments and refer to them later, for example, to go back to the original URL after authentication via router.navigate(urlSegments). Existing code still works as before because the second function parameter is not mandatory. Dependency updates The following dependencies are upgraded to their latest: angular/core now depends on TypeScript 3.1 and RxJS 6.3 @angular/platform-server now depends on Domino 2.1 Bug fixes Along with these added features, Angular 7 comes with many bug fixes, some of which are: Mappings are added for ngfactory and ngsummary to their module names in aot summary resolver. fileNameToModuleName lookups are now cached to save expensive reparsing of the file when not run as Bazel worker. It is allowed to privately import compile_strategy. Earlier, when an attempt was made to bootstrap a component that includes a router config using AOT Summaries, the test used to fails. This is fixed in this release. The compiler is updated to flatten nested template fns and to generate new slot allocations. To read the full list of changes, check out Angular’s GitHub repository. Angular 7 beta.0 is here! Why switch to Angular for web development – Interview with Minko Gechev ng-conf 2018 highlights, the popular angular conference

Two days ago, the team behind FFmpeg released their latest version of FFmpeg 4.2, nicknamed “Ada”. This release comes with many new filters, decoders, and demuxers. FFmpeg is an open-source project composing software suite of libraries and programs to handle multimedia files. It has cross-platform multimedia framework which is used by various games and applications to record, convert and stream audios and videos. The previous version FFmpeg 4.1 was released last year in November. The FFmpeg team has announced on Twitter that the follow-up point release (4.2.1) will be released in a few weeks. FFmpeg 4.2 has a AV1 decoding support through libdav1d. It also supports decoding of HEVC 4:4:4 content in nvdec, cuviddec and vdpau. It has many new filters like tpad, dedot, freezedetect, truehd_core bitstream, anlmdn, maskfun, and more. Read More: Presenting dav1d, a new lightweight AV1 decoder, by VideoLAN and FFmpeg PCM-DVD has been included as an encoder in FFmpeg 4.2. It also introduces numerous demuxers such as dhav, vividas, hcom, KUX, and IFV. This version also removes libndi-newtek. The new version allows the mov muxer to write tracks in any unspecified language. Earlier, a mov mixer could write in only English, by default. The latest version also supports clang to compile CUDA kernels. Users are happy with the FFmpeg 4.2 release and seem to be excited to get hands on with the new features in their applications. https://twitter.com/Poddingue/status/1158840601267322886 A user on Hacker News comments, “Massive "thank you" to FFmpeg for being an amazing tool. My app pivotally depends on FFmpeg extracting screenshots of videos for users to browse through.” Another comment on Hacker News reads, “Nice to see improved HEVC 4:4:4 support in Linux” Additionally users have appreciated the growth of FFmpeg project in general. A Redditor comments, “Man ffmpeg is so awesome. It's still mind blowing that something so powerful is FOSS. Outside of programming languages, operating systems, and essential tools like the GNU suite, I think an argument can be made that ffmpeg is one of the most important pieces of software ever created. We live in a digital world and virtually everything from security cameras to social media sites to news stations use ffmpeg on some level” Check out the FFmpeg page to read about the updates in detail. Firefox 67 enables AV1 video decoder ‘dav1d’, by default on all desktop platforms Fabrice Bellard, the creator of FFmpeg and QEMU, introduces a lossless data compressor which uses neural networks Introducing QuickJS, a small and easily embeddable JavaScript engine

On Tuesday, Atila Neves the Deputy leader for D programming language posted about his vision for D and what he would like to do with D lang in the near future. Make D programming language default for web dev and mobile applications D’s static reflection and code generation capabilities make it an ideal candidate to implement a codebase that needs to be called from several different languages and environments (e.g. Python, Java, R). Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it. With D, none of that is necessary. One can write the production code in D and have libraries automatically making the code callable from other languages. Hence it will be easy to write D code that runs as fast or faster than the alternatives, and it will be a win on all fronts. Memory Safety for D lang Atila believes that D is a systems programming language with value types and pointers, it isn’t memory safe. He says that DIP1000 is in the right direction, but it still needs to be memory safe unless programmers opt-out via @trusted block or function. The DIP1000 proposal includes a scope mechanism that will know when the lifetime of a reference is over by providing a mechanism to guarantee that a reference cannot escape lexical scope. Thus it can safely implement memory management schemes rather than tracing the garbage collection. Safe and easy concurrency in D programming language As per Atila safe and easy concurrency in D is mostly achieved through actor models, but they still need to finalize shards and make everything @safe as well. Centralizing all reflection needs with an API Atila says instead of disparate ways of getting things done with fragmented APIs like (__traits, std.traits, custom code), he would like there to be a library that centralizes all reflection needs with a great API. Easy interoperability for C++ developers C++ has been successful so far in making the transition from C virtually seamless. Atila wants current C++ programmers with legacy codebases to just as easily be able to start writing D code. Faster development times D needs a fast interpreter so that developers can skip machine code generation and linking. This should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. String interpolation in D programming language Code generation is one of D’s greatest strengths, and token strings enable visually pleasing blocks of code that are actually “just strings”. Hence, String interpolation would make it vastly easier to use. To know more about D programming language, check out the official post by Atila Neves. “Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett The V programming language is now open source – is it too good to be true? Rust’s original creator, Graydon Hoare on the current state of system programming and safety

Two months ago, Mozilla introduced Neqo, code written in Rust to implement QUIC, a new protocol for the web developed on top of UDP instead of TCP. As per the GitHub page, web developers who want to run test on http 0.9 programs using neqo-client and neqo-server, below is the code: cargo build ./target/debug/neqo-server 12345 -k key --db ./test-fixture/db ./target/debug/neqo-client http://127.0.0.1:12345/ -o --db ./test-fixture/db While developers who want to run test on http 3 programs using neqo-client and neqo-http3-server must check the code given below: cargo build ./target/debug/neqo-http3-server [::]:12345 --db ./test-fixture/db ./target/debug/neqo-client http://127.0.0.1:12345/ --db ./test-fixture/db What is QUIC and why is it important for web developers According to Wikipedia, QUIC is the next generation encrypted-by-default transport layer network protocol designed by Jim Roskind at Google. It is designed to secure and accelerate web traffic on the Internet. It was implemented and deployed in 2012, and announced publicly in 2013 as an experimentation broadened and described to the IETF. While still an Internet Draft, QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. As per the QUIC’s official website, “QUIC is an IETF Working Group that is chartered to deliver the next transport protocol for the Internet.” One of the users on Hacker News commented, “QUIC is an entirely new protocol for the web developed on top of UDP instead of TCP. UDP has the advantage that it is not dependent on the order of the received packets, hence non-blocking unlike TCP. If QUIC is used, the TCP/TLS/HTTP2 stack is replaced to UDP/QUIC stack.”  The user further comments, “If QUIC features prove effective, those features could migrate into a later version of TCP and TLS (which have a notably longer deployment cycle). So basically, QUIC wants to combine the speed of the UDP protocol, with the reliability of the TCP protocol.” Additionally, the Rust community on Reddit were asked if QUIC is royalty free. To which one of the Rust developer responded, “Yes, it is being developed and standardized by a working group (under the IETF) and the IETF respectively. So it will become an internet standard just like UDP, TCP, HTTP, etc.” If you are interested to know more about Neqo and QUIC, check out the official GitHub page. Other interesting news in web development Chrome 78 beta brings the CSS Properties and Values API, the native file system API, and more! Apple releases Safari 13 with opt-in dark mode support, FIDO2-compliant USB security keys support, and more! Inkscape 1.0 beta is available for testing  

Earlier this month, Google Chrome 76 got native support for lazy loading. Web developers can now use the new ‘loading’ attribute to lazy-load resources without having to rely on a third-party library or writing a custom lazy-loading code. Why native lazy loading is introduced Lazy loading aims to provide better web performance in terms of both speed and consumption of data. Generally, images are the most requested resources on any website. Some web pages end up using a lot of data to load images that are out of the viewport. Though this might not have much effect on a WiFi user, this could surely end up consuming a lot of cellular data. Not only images, but out-of-viewport embedded iframes can also consume a lot of data and contribute to slow page speed. Lazy loading addresses this problem by deferring the non-critical, below-the-fold images and iframe loads until the user scrolls closer to them. This results in faster web page loading, minimized bandwidth for users, and reduced memory usage. Previously, there were a few ways to defer the loading of images and iframes that were out of the viewport. You could use the Intersection Observer API or the ‘data-src’ attribute on the 'img' tag. Many developers also built third-party libraries to provide abstractions that are even easier to use. Bringing native support, however, eliminates the need for an external library. It also ensures that the deferred loading of images and iframes still work even if JavaScript is disabled on the client. How you can use lazy loading Without this feature, Chrome already loads images at different priorities depending on their location with respect to the device viewport. This new ‘loading’ attribute, however, allows developers to completely defer the loading of images and iframes until the user scrolls near them. The distance-from-viewport threshold is not fixed and depends on the type of resources being fetched, whether Lite mode is enabled, and the effective connection type. There are default values assigned for effective connection type in the Chromium source code that might change in a future release. Also, since the images are lazy-loaded, there are chances of content reflow. To prevent this, developers are advised to set width and height for the images. You can assign any one of the following three values to the ‘loading’ attribute: ‘auto’: This represents the default behavior of the browser and is equivalent to not including the attribute. ‘lazy’: This will defer the loading of the images and iframes until it reaches a calculated distance from the viewport. ‘eager’: This will load the resource immediately. Support for native lazy loading in Chrome 76 got mixed reactions from users. A user commented on Hacker News, “I'm happy to see this. So many websites with lazy loading never implemented a fallback for noscript. And most of the popular libraries didn't account for this accessibility.” Another user expressed that it does hinder user experience. They commented, “I may be the odd one out here, but I hate lazy loading. I get why it's a big thing on cellular connections, but I do most of my browsing on WIFI. With lazy loading, I'll frequently be reading an article, reach an image that hasn't loaded in yet, and have to wait for it, even though I've been reading for several minutes. Sometimes I also have to refind my place as the whole darn page reflows. I wish there was a middle ground... detect I'm on WIFI and go ahead and load in the lazy stuff after the above the fold stuff.” Right now, Chrome is the only browser to support native lazy loading. However, other browsers may follow the suit considering Firefox has an open bug for implementing lazy loading and Edge is based on Chromium. Why should your e-commerce site opt for Headless Magento 2? Edge, Chrome, Brave share updates on upcoming releases, recent milestones, and more at State of Browsers event Angular 8.0 releases with major updates to framework, Angular Material, and the CLI

Yesterday, Django released its latest major update - Django 3.0. Django is a Python-based web framework designed to help developers build apps faster with less code. Django 3.0 now comes with built-in async functionality, Python 3.6, 3.7 and 3.8 support and third-party library support for the older version of Django. New features in Django 3.0 MariaDB support Django now officially supports MariaDB 10.1 and higher. To use MariaDB you should use the MySQL backend, which is shared between the two. ASGI support for async programming Django 3.0 provides support for running as an ASGI application, making Django fully async-capable (Django already has existing WSGI support). However, async features will only be available to applications that run under ASGI. As a side-effect of this change, Django is now aware of asynchronous event loops and will block you calling code marked as “async unsafe” - such as ORM operations - from an asynchronous context. This was one of the most eagerly awaited features. https://twitter.com/jmcampbell72/status/1201502666431619072 https://twitter.com/arocks/status/1201711143103807490 https://twitter.com/gtcarvalh0/status/1201475826564382720 Exclusion constraints on PostgreSQL Django 3.0 adds a new ExclusionConstraint class which adds exclusion constraints on PostgreSQL. Constraints are added to models using the Meta.constraints option. Filter expressions Expressions that output BooleanField may now be used directly in QuerySet filters, without having to first annotate and then filter against the annotation. Enumerations for model field choices Custom enumeration types TextChoices, IntegerChoices, and Choices are now available as a way to define Field.choices. TextChoices and IntegerChoices types are provided for text and integer fields. Django 3.0 has also dropped support for PostgreSQL 9.4 which ends in December 2019. It also removes private Python 2 compatibility APIs. The upstream support for Oracle 12.1 also ends in July 2021. Django 2.2 will be supported until April 2022. Django 3.0 officially supports Oracle 12.2 and 18c. The complete list of updates is available in the release notes. Django 3.0 is going async! Which Python framework is best for building RESTful APIs? Django or Flask? Django 2.2 is now out with classes for custom database constraints

Yesterday the team behind the Ionic Framework announced the general availability of Ionic React, which is a native React version of Ionic Framework, pivoting from its traditional Angular-focused app framework. “Ionic React makes it easy to build apps for iOS, Android, Desktop, and the web as a Progressive Web App”, states the team in a blog post. It uses Typescript and combines core Ionic experience with the tooling and APIs that are tailored to developers. It is a fully-supported, enterprise-ready offering with services, advisory, tooling, and supported native functionality. @ionic/react projects will work like standard React projects, leveraging react-dom and with setup normally found in a Create React App (CRA) app. For routing and navigation, React Router is used under the hood. One difference is the usage of TypeScript, which provides a more productive experience. To use plain JavaScript, you can rename files to use a .js extension then remove any of the type annotations with each file. Explaining the reason behind choosing React, the team says, “With Ionic, we envisioned being able to build rich JavaScript-powered controls and distribute them as simple HTML tags any web developer could assemble into an awesome app. We realized that building a version of the Ionic Framework for React made perfect sense. Combined with the fact that we had several React fans join the Ionic team over the years, there was a strong desire internally to see Ionic Framework support React as well.” How is Ionic React different from React Native The team realized that there was a gap in the React ecosystem that Ionic could fill as an easier mobile and Progressive Web App development solution. Developers were also interested in incorporating it in their existing React Native apps, by building more screens in their app out of a native WebView frame. There were two major reasons why the Ionic team built @ionic/react. First, it is DOM-native and uses the standard react-dom library. In contrast, React Native builds an abstraction on top of iOS and Android native UI controls. The team states, “When we looked at installs for react-dom compared to react-native, it was clear to us that vastly more React development was happening in the browser and on top of the DOM than on top of the native iOS or Android UI systems” Secondly, Ionic is one of the most popular frameworks for building PWA, most notably the Stencil project. React Native, on the other hand, does not officially support Progressive web apps. PWAs are, at best, an afterthought in the React Native ecosystem. @ionic/react has been well appreciated by developers on Twitter. https://twitter.com/dipakcreation/status/1183974237125693441 https://twitter.com/MichaelW_PWC/status/1183836080170323968 https://twitter.com/planetoftheweb/status/1183809368934043653 You can go through Ionic’s blog for additional information and for getting started. Ionic React RC is now out! Ionic 4.1 named Hydrogen is out! React Native Vs Ionic: Which one is the better mobile app development framework?

On Tuesday, Fabrice Bellard, the creator of FFmpeg and QEMU and Charlie Gordon, a C expert, announced the first public release of QuickJS. Released under MIT license, it is a “small but complete JavaScript engine” that comes with support for the latest ES2019 language specification. Features in QuickJS JavaScript engine Small and easily embeddable: The engine is formed by a few C files and does not have any external dependency. Fast interpreter: The interpreter shows impressive speed by running 56,000 tests from the ECMAScript Test Suite1 in just 100 seconds, and that too on a single-core CPU. A runtime instance completes its life cycle in less than 300 microseconds. ES2019 support: The support for ES2019 specification is almost complete including modules, asynchronous generators, and full Annex B support (legacy web compatibility). Currently, it does not has support for realms and tail calls. No external dependency: It can compile JavaScript source to executables without the need for any external dependency. Command-line interpreter: The command-line interpreter comes with contextual colorization and completion implemented in Javascript. Garbage collection: It uses reference counting with cycle removal to free objects automatically and deterministically. This reduces memory usage and ensures deterministic behavior of the JavaScript engine. Mathematical extensions: You can find all the mathematical extensions in the ‘qjsbn’ version, which are fully-backward compatible with standard Javascript. It supports big integers (BigInt), big floating-point numbers (BigFloat), operator overloading, and also comes with ‘bigint’ and ‘math’ mode. This news struck a discussion on Hacker News, where developers were all praises for Bellard’s and Gordon’s outstanding work on this project. A developer commented, “Wow. The core is a single 1.5MB file that's very readable, it supports nearly all of the latest standard, and Bellard even added his own extensions on top of that. It has compile-time options for either a NaN-boxing or traditional tagged union object representation, so he didn't just go for a single minimal implementation (unlike e.g. OTCC) but even had the time and energy to explore a bit. I like the fact that it's not C99 but appears to be basic C89, meaning very high portability. Despite my general distaste for JS largely due to websites tending to abuse it more than anything, this project is still immensely impressive and very inspiring, and one wonders whether there is still "space at the bottom" for even smaller but functionality competitive implementations.” Another wrote, “I can't wait to mess around with this, it looks super cool. I love the minimalist approach. If it's truly spec compliant, I'll be using this to compile down a bunch of CLI scripts I've written that currently use node. I tend to stick with the ECMAScript core whenever I can and avoid using packages from NPM, especially ones with binary components. A lot of the time that slows me down a bit because I'm rewriting parts of libraries, but here everything should just work with a little bit of translation for the OS interaction layer which is very exciting.” To know more about QuickJS, check out Fabrice Bellard's official website. Firefox 67 will come with faster and reliable JavaScript debugging tools Introducing Node.js 12 with V8 JavaScript engine, improved worker threads, and much more React Native 0.59 is now out with React Hooks, updated JavaScriptCore, and more!