Google To Pay JavaScript Frameworks To Implement Performance-First Code (zdnet.com)

An anonymous reader quotes ZDNet: Google will be launching a fund of $200,000 to sponsor the development and implementation of performance-related features in third-party JavaScript frameworks... Frameworks with original ideas to improve performance and those which ship "on by default" performance-boosting features will be favored in the funds allocation process. Nicole Sullivan, Chrome Product Manager, and Malte Ubl, Google Engineering Lead, have told ZDNet that the popularity, size, or the adoption of any participant framework will not count as a defining factor for being selected to receive funding. "The objective of this initiative is to help developers hit performance goals and hence serve their users with high-quality user experiences by default and ensure that this happens at scale," the two told ZDNet in an email...

"One key factor is also whether the respective feature can be turned on by default and thus have maximum impact rather than being only made available optionally," Sullivan and Ubl said.... "We want developers to be creative in approaching and solving the performance problem on the web but at a high-level we'll be looking at features that directly impact loading performance (e.g. use of feature policies, smart bundling, code-splitting, differential serving) and runtime performance (e.g. breaking tasks into smaller, schedulable chunks & keeping fps high)...."

But in addition to putting up funds to help frameworks improve their codebase, Google has also invited the development teams some of these frameworks to provide feedback in a more prominent role as part of the Google Chrome development process... "Frameworks sometimes make web apps slower. They are also our best hope to make it faster," a slide in Sullivan and Ubl's Chrome Dev Summit presentation read.
"It's still JavaScript," complains long-time Slashdot reader tepples. "The fastest script is the script that is not loaded at all."

Comments

Re:Not gunna happen...

[Anonymous Coward]

You don't even need to store it in a variable: jQuery is chainable so the following will work:

$('.someEle').addClass('class-1').addClass('class-2').addClass('class-3').addClass('class-4');

And, of course, if the developer knew CSS in the slightest, or bothered reading the addClass() documentation, this works too:

$('.someEle').addClass('class-1 class-2 class-3 class-4');

Re:If you want to speed up the framework

[Daltorak]

Get rid of the bloody framework. Why include 200K of compressed javascript when you're only going to use two five-line functions.

Not to mention all the potential security vulnerabilities you just needlessly included in your code.

Always blows me away when developers draw the line at "Javascript frameworks".

Never mind the dependency on several different web browsers, each of which are loaded with thousands of capabilities, but behave a little different from eachother. Never mind the hard dependency on a mediocre programming language that changes frequently, cannot be compiled ahead of time, must be served in an inefficient text format, and whose corresponding graphical assets must be sent across the Internet every time the user wants to see them. Never mind the fact that we have to use transpilers like babel or Typescript, minifiers, packaging & loader engines like webpack or SystemJS, polyfills to cover older browsers..... Never mind the fact that there was NO STANDARD LIBRARY for most of JavaScript's existence...... never mind the fact that we have to slow everything down on the server -and- client side because we have to use HTTPS to protect our application at runtime. No, let's not blame all that, let's blame Lodash, Sizzle, Wolkenkit, Redux and SignalR for having the temerity to exist and be useful to developers.

Makes no sense, dude. Makes no sense at all.

Take this Slashdot page I'm looking at right now. According to Firefox's own dev tools, this Slashdot browser tab I'm typing in is taking 150 MB RAM, but just 22 MB of that is actually for the page's content and scripts. The addition or removal of some JavaScript isn't going to make a big difference here!

You're spot on. And totally wrong.

[Qbertino]

At this point, the web browser has become the prime example of the inner-platform effect (an anti-pattern), in being nothing more than a more shitty implementation of the OS below it.

Exactly. But you've totally forgotten the reason the browser is winning. It's precisely *because* you can use it as a platform and needn't think twice about what brand, version and Iteration of operating systems the target audience is running. F*ck MS, Oracle, Apple, some obscure Linux with a bazillion desktop and lib variants, BSDs and whatnot. Take your proprietary heap of lock-in garbage and go die in a fire. And all hail the mighty Webbrowser! Ten times over!

So yes, it's an OS behind the curve, but no, it's absolutely not an Anti-pattern, is the exact opposite. And I thank God for once again the laughed at toys winning and taking over the planet. Just like that silly open architecture toy computer x86 back then.

Toys win and the web will own everything and the world will be a better place because of it.