latest
Google's in-development Fuchsia operating system has been slowly taking shape over the past three years. It appears to be designed for both mobile and desktop devices, with a real-time kernel and a unique interface. We already know languages like Google Dart and Apple's Swift will be supported by Fuchsia, but now it seems JavaScript might be joining the party.
Google has added countless features to Chrome, especially the Android version, that are designed to improve functionality on slow connections. It can automatically download articles for later reading, and the data saver feature continues to get better. Now it appears Google is taking more drastic steps - like disabling JavaScript entirely on slow connections.
Google Dart has evolved a great deal over the past few years. It was originally designed as a JavaScript replacement, with Google planning to add native support for it in Chrome. The company later dropped those plans, instead focusing on Dart's ability to compile to JavaScript (thus allowing Dart code to work in every web browser). Dart is heavily used in the cross-platform Flutter SDK, and it's a supported language in Fuchsia.
The Chrome team seems to always be working on many ways to quicken page loading times and speed up our access to information. The latest proposed test, which hasn't been implemented yet, is a built-in Lazy Loading mechanism for images and iframes. According to the Google Chromium group, work is underway to test and implement this new feature in Chrome for Android.
Web browsers have several major components, including the rendering engine (the part that displays web pages) and JavaScript engine (the part that runs scripts in pages). V8 was created alongside Chrome, and is used in many other browsers and runtimes based on the Chrome codebase.
Chrome on Android already heavily throttles (or outright kills) background tabs, but Chrome on the desktop has mostly allowed inactive tabs to do whatever they want. Unfortunately, having several tabs open using performance-intensive JavaScript code, like timers, can cause Chrome performance and battery life (if you're on a laptop or other portable device) to suffer.
Malicious emails often attach various forms of executable programs and trick users into running them. These include standard Windows executables (.exe), batch files (.bat), and even JavaScript files (.js). Starting February 13, 2017, Google will not allow JS files to be sent as an attachment, including JS files detected within archives.
This month's update to Chrome is a little more developer-centric than usual. We're accustomed to seeing small visual tweaks and a couple of other new capabilities here and there –and there is a fix of that nature– but this time, it's all about the APIs. Chrome Beta v44 adds a few new features for notifications and install banners, adds a new way to define names for object literals in Javascript, and makes a few breaking changes to the Push API.
The Nexus 4 below was created without using any external images. Okay, the one below is actually just a screenshot of a Nexus 4 designed entirely using CSS and JavaScript, but the real deal is hosted over at CodePen. The smartphone is somewhat interactive - you don't have access to the home screen or the Play Store, but you can play around with the dialer. The tabs can be switched, even though they don't lead to anything for the time being. All of the code is visible for anyone who wants to see how the sauce is made.
Man, WebKit cannot catch a break today, can it? After Samsung announced that it would be teaming up with Mozilla to build their own mobile browser engine called Servo, Google says its planning to fork WebKit to create a new project called Blink. Unlike Servo, this one will still be based on WebKit, but this new fork actually seems to be aimed not at competing with whatever Samsung is putting out, but rather at gaining freedom from another browser: Safari.
A key aspect of the power of smartphones is the variety of functions they provide to the user. Data, GPS, Voice, Video, are all found in almost every Android phone on the market. With today's release of on{X} ("on-ex"), Microsoft hopes to exploit this convergence of functionality in a way that is less reliant on the user for input and more aware of its surroundings. By gathering information from the host of sensors available to the operating system, it's quite possible for your phone to determine its location and context and respond accordingly, without intervention by the user. Armed with their trademark lower-case, sans-serif, Holo-breaking Metro style convention, on{X} is Tasker for the everyman.
You're already a web developer, master of HTML, CSS, and JavaScript. You have a great idea for an Android App, but your particular skill set doesn't help you create that app. Or does it? O'Reilly media just released a 176-page 2nd edition of "Building Android Apps with HTML, CSS, and JavaScript" by Jonathan Stark and Brian Jepson that explains how to do just that.
It's a well-known fact that Android enthusiasts love benchmarks. When new devices hit our hands, what is one of the first things we do? Run benchmarks. It's how we compare devices to one another, and what we use to develop the standards on which future devices will be set. At this point, we use a set of benchmarking tools that have become clutch throughout the community: Quadrant, Linpack, SmartBench, etc.
Last year, we reported on a serious vulnerability in all versions of Android, found by a security researcher Thomas Cannon. It allowed a remote attacker to download files off a user's SD card upon visiting a webpage with malicious JavaScript code embedded in it. Google's response was swift, and the fix was rolled out in the public release of Gingerbread at the end of 2010.
A new vulnerability that affects every Android device currently on the market was discovered and published today by Thomas Cannon, an information and security researcher. The hole in the way the Android browser treats Javascript allows a remote attacker to lure an unsuspecting victim to a malicious web page, which then downloads and executes rogue Javascript with access to the local SD card's file system. While the locations of files on the SD card needs to be known by the attacker in advance, it still represents a clear problem due to many popular applications storing data in the same location. Additionally, photo files tend to use similar naming schemes, and the attacker would be easily able to harvest some of your private pictures.
It’s rather surprising this comparison took such a long time to take place, but nonetheless, ArsTechnica published the image below comparing the performance of Android 2.2’s web browser against iOS4’s mobile Safari in two respected JavaScript benchmarks.