Google To Pay JavaScript Frameworks To Implement Performance-First Code (zdnet.com) 82
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."
"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."
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
>suggests Lua instead of JavaScript for performance
That's quite possibly the only language that's even *slower* than JavaScript.
Funny that you single out the one language that actually has an implementation matching or exceeding the performance of the best JS implementations, and completely ignore the languages for which your claim actually holds, such as Python, Ruby, Perl, PHP, Tcl etc.
No, we're not. We have WebAssembly. (Score:2, Interesting)
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 mor
Re: (Score:2)
This is a great idea. I think we should tell Microsoft. They can do something crazy like integrate Internet Explorer into the underlying OS.
Re:No, we're not. We have WebAssembly. (Score:4, Interesting)
the web browser has become the prime example of the inner-platform effect (an anti-pattern)
Wikipedia's article about an inner platform [wikipedia.org] 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?
You're spot on. And totally wrong. (Score:5, Insightful)
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.
Re: (Score:2)
No. All the cool kids are learning Techno Psycho Bitch now? [youtube.com]
Re: (Score:2)
[How about] security first? Oh no? Yeah, thought so.
Well, it worked for Intel. Oh, wait...
Not gunna happen... (Score:4, Interesting)
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: (Score:3)
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: (Score:3)
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: (Score:2)
I have somewhere a Udemy course called "Javascript - the actual fucking language, not any assbaking frameworks or shit".
Re: (Score:3, Interesting)
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 alwa
Re:Not gunna happen... (Score:5, Insightful)
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 [jquery.com], this works too:
$('.someEle').addClass('class-1 class-2 class-3 class-4');
Re: (Score:2)
The point wasn't the use of addClass, it was just a chosen method to demonstrate the issue of DOM lookups never being cached.
Re: (Score:1)
IE 8 is dead now. Let JQuery rest in peace. Most corporate users who still use insecure ancient IE also have Chrome as HTML 5 is a requirement to use the internet.
Re: Not gunna happen... (Score:2)
Well, to be fair, jquery does now use the native browser api to execute that select, and the browser does cache those nodelists, so that codes isnâ(TM)t as inefficient as you might think.
Lemme guess... (Score:2)
If you want to speed up the framework (Score:3)
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: (Score:2, Interesting)
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
Re: (Score:2)
THANK YOU.
snipsnip
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.
I'm not sure I do. It would be fun to give it a whirl, yea. Unfortunately paychecks depend on product out the door. We don't have the bandwidth or time to develop a multi-OS, multi-browser, multi-browser-version library.
(and also, the major browsers comply MUCH better to standards than they did even ten years ago, so the religion is outdated, too).
I'm guessing you're on the mark here, but you would not believe how much legacy code we've got that depends on jQuery. Again, no time or butts to convert it to anything else. If it ain't broke big-time, don't fix it.
Re:If you want to speed up the framework (Score:5, Interesting)
Re:If you want to speed up the framework (Score:4, Insightful)
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!
Re: (Score:2)
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.
The web took off because it was inefficient and text based and supported a vast array of possible clients.
(There's a capitalism vs. communism parallel to be made there, but I'll leave that be.)
Makes it a heck of a lot easier to parse for ads and trackers too ....
You sound kind of like you are pining for AOL ;)
And BTW, doesn't your browser cache anything? Mine just asks - occasionally - if the graphical asset has changed, and the vast majority of the time shows a local cached copy. And it does that with
You have to use the BEST framework! (Score:1)
Vanilla.js [vanilla-js.com] is the most secure, most enabling javascript ever!
You can't beat Vanilla.js [vanilla-js.com]; it outperforms every other framework in usability.
Yet Vanilla.js [vanilla-js.com] is the smallest, most efficient, fastest loading framework available!
Vanilla.js [vanilla-js.com] lets you use less code to do more work, in more standardized ways, and future proofs your code by reducing legacy burden.
Get Vanilla.js [vanilla-js.com] for your project, today!
Would not it be better to implement Security-First (Score:3)
Oh wait, if they did that, that would mean al LOT LESS WORK for the Project Zero guys... so no! Performance it is!
Better idea (Score:2)
How about they just pay them to like totally go away?
I don't usually buy in to the language bashing... (Score:1, Interesting)
... but JavaScript is atrocious. I think that pretty much any language can be used to produce something that's functional and reliable. Maybe not as elegant as it could be but still functional. I'm a guy that uses PHP regularly, I develop mission critical database solutions sometimes using MS Access and I've written entire projects in Visual Basic. They weren't the only options either, I could have chosen other paths, but circumstance and costings led to those decisions. None are great, but at least they al
As a Javascript developer... (Score:1)
Majority of the comments seem to be by people who feel the need to feel better about themselves by bashing a language and people they know very little about. Yes, there are bad Javascript developers, but so what? There are bad Java developers as well. Just because you're not able to grok it, isn't a reason to bash it. It's a poor craftsman who blames his tools.
Re: (Score:1)
But it's a great craftsman that can recognize when a tool was constructed poorly.
Scripting languages are great... (Score:2)
Re: (Score:3)
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. Jus
money should go to Gmail (Score:2)
30 seconds for the inbox to load is a joke.
Also _whole_ $200K Google? wow, thats a lot of money, could almost pay for a month of free candy at Googleplex, almost.
Re: (Score:2)
Took six seconds to load on my phone.
The site is actually faster than the app.
pick two. (Score:2)
1. fast
2. secure
3. easy to use