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

Not gunna happen...

[TFlan91]

Do you know how many times I see jQuery code like this:

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

For god sake, assign that DOM lookup to a fuckin variable and reference it! No need to skim the DOM four effin' times to do some work on an element.

Re:Not gunna happen...

[TFlan91]

Oh and my original point was that the performance issues with JavaScript is mostly bottlenecking around the DOM interface, not developers using for...in vs for...of vs for() vs w/e (but that is still an issue - sometimes)

I've otherwise been content with JavaScripts performance - not the best, but it's perfectly fine.

Re:Not gunna happen...

[93 Escort Wagon]

God knows why this is the case, but after looking at a lot of code I've become convinced that a non-trivial number of web developers "learned jquery" and never bothered to actually learn javascript, so to speak.

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:Not gunna happen...

[Anonymous Coward]

Learning Javascript won't help.

There is a class of developer that can write scripts, but cannot create algorithms. People in this class will never be good at performance optimization. They just don't have the insight they need, nor do they care (for the most part). They achieve success by quickly churning out scripts that "basically" work. That's what they are paid to do.

Once performance problems are hit, someone with actual computer science skills is pulled in to get in there and fix it. And they always balk at what they see.

But it must be this way. People with solid computer science skills cost more than scripters, and most of the time most of what the scripters churn out is good enough to make money. So it is not cost-effecient to have a real computer scientist do it all.

If you want to speed up the framework

[93 Escort Wagon]

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.

Re:If you want to speed up the framework

[Anonymous Coward]

THANK YOU.

There is a popular religion that teaches that the only correct way to do web development is to use someone else's framework. The faithful believe that it is so hard to get code to run the same on all major browsers, and so hard to get it to work in the first place, and so hard to make it perform well and not gobble up all the end-users memory, that the only option is to use a framework.

And, for the most part, they are right. The adherents of this religion are not computer scientists. They don't have the chops.

But some of us do. I do. I am betting you do. And when you DO have the chops, you can produce something that is faster, cheaper, and better, yourself.

But those that can't outnumber those that can, and so the religion flourishes.

(and also, the major browsers comply MUCH better to standards than they did even ten years ago, so the religion is outdated, too).
   

Re:If you want to speed up the framework

[AHuxley]

The ads need the frameworks. The customers with high-quality ads have to be looked after.

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!

Would not it be better to implement Security-First

[williamyf]

Oh wait, if they did that, that would mean al LOT LESS WORK for the Project Zero guys... so no! Performance it is!

No, we're not. We have WebAssembly.

[Anonymous Coward]

In a couple of years, JS will be basically dead. Since WebAssembly allows you to run code from any language in their VM that they falsely call a "browser".
(Somebody add a URL bar and tabs to VirtualBox already! And have a HTML5OS snapshot to copy-on-write clone on hot standby. [Just mention that you didn't come up with it, as I've been suggesting this since the first JSLinux now.])

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. In a VM that only serves as a false sense of security. I'd prefer if we'd get rid of it, and make the HTML viewer application (the top layers of what I called "HTML5OS") independent.

This would allow for a whole class of new possibilities, and free everyone from having to use HTML5 on the web, while allowing every platform to be "web-enabled" simply thanks to the features of the underlying OS.
The OS could also handle application firewalling, certificates, etc, freeing the need for the browser to do it a second limited and incompatible time.

Re:No, we're not. We have WebAssembly.

[tepples]

the web browser has become the prime example of the inner-platform effect (an anti-pattern)

Wikipedia's article about an inner platform states: "An inner platform can be useful for portability and privilege separation reasons -- in other words, so that the same application can run on a wide variety of outer platforms without affecting anything outside a sandbox managed by the inner platform." How would your solution allow a single application to run on Windows, X11/Linux, Android/Linux, Chrome OS, macOS, iOS, and those game consoles that have web browsers?

Re:Scripting languages are great...

[scamper_22]

I used to a lot of embedded programming. As part of the job, we often had to write quick front ends or utilities for our customers. I used a lot of visual basic 6 there.

That actually was a time saver. It was just easy to get something basic out. Way quicker than i could have done it in VC++ or anything like that. Good IDE, debugging... (for a script language of course)

The problem that I have with a lot of this is many scripting languages aren't easy to get into.

Javascript for example is just not easier. Just for starters, an asynchronous event queue system within a webbrowser/server environment is actually a friggin complex programming system on its own.

You start throwing in package management to do anything useful of many script languages and it all gets confusing fast.

I love scripting languages myself. It's just crazy how hard and complex the ones we speak of are.

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.