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."
"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."
Step 1: Don't use JavaScript.
Step 2: Did I fucking stutter?
security first? Oh no? Yeah, thought so.
Let's cram more datamining into our websites thanks to performance improvements!!!!!
is the twenty-three tracking and 'analytic' scripts and seventeen ad-generating scripts on every fucking page view.
of course google wants that shit to go faster, so people don't turn to ad blockers and script blockers and other tactics to avoid the crud (third party dns, hosts files, filtering proxy servers, etc.) that makes them (google) money and feeds their databases.
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.
Funds only for Chrome-only improvements?
AC comments get piped to
Presumably Intel embracing the "Performance First" ideology is what had led to the Meltdown vulnerability.
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.
#DeleteChrome
Oh wait, if they did that, that would mean al LOT LESS WORK for the Project Zero guys... so no! Performance it is!
*** Suerte a todos y Feliz dia!
Not that any web "developer" would know the first thing about it, with the "living standard" oxymoron being the core of their religion.
How about they just pay them to like totally go away?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
Please do continue to insult and push around the handicapped. When the dems are in office it will only get worse. My favorite dems are Chavez and Lenin
... 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 all work well enough.
JavaScript is basically herpes though. Irritating, impractical, unsightly and it sticks with you forever. I'd never volunteer for herpes. At least my PHP chlamydia can be effectively treated.
Just to mitigate some of the hate I'll be getting I'd like to add that the vast majority of my work is for microcontrollers and the higher layer software for user interfacing is usually for smaller companies, the bigger implementations are usually handled by in-house people and I focus on the hardware... so be gentle.
Then once the UI/UX/ScrumDork/buzzworders/clients are done figuring out what they actually wanted factor all the jquery out. React is because someone wanted wordpress in the browser and now enough cool kids know the tricks that, like wordpress, it has a sunk costs advantage. Angular is for Java developers who are bitter because they're forced to work on web apps and want to torture a team to share the pain.
Vanilla js is actually okay and does run in browsers. Everything else is wordpress level mistakes. Node is a good stepping stone to Amazon forcing us all to use lamda and get tracking implant bracelets that administer electric shocks if you cancel prime.
It's for google to profit. Not to benefit you or anyone else.
No matter what google want to push to try to make things easier for webapps on your mobes, they're always going to be utter shit
This is yet another attempt by them to make webapps 'speedier' and 'more sexy' by improving the performance the underlying code.
Avoid webapps like the plague they will be.
Sacrilege I know, but Java/Javascript are prototyping languages and despite all the hype will never catch up.
As the technology matures that's the obvious way to get performance.
Everyone KNOWS you IMPERSONATE ME: gweihir KNEW it https://it.slashdot.org/commen... (as you tried to "stir me up" vs. him before & we discussed it - he did NOT do it!)
THAT or STALKING me UNIDENTIFIABLE ac & 'supporting yourself' that way too as you are now!
* You're SICK IN THE HEAD & "obsessed" w/ STALKING me by UNIDENTIFIABLE anonymous OR by IMPERSONATING me spouting stupid shit!
APK
P.S.=> You were useful to me though - thanks https://science.slashdot.org/c... getting ME to look into that & "lo & behold" HOSTS DO STOP Intel CPU speculative execution weakness (by preventing what uses it to attack you from getting to you (or you to it rather)) - & I KNOW that fact THAT IS KILLING YOU INSIDE stupid (you stopped trying it in your impersonations of me)... apk
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.
gweihir PROVED you IMPERSONATE me https://it.slashdot.org/commen... chump & so did c6gunner https://linux.slashdot.org/com... forgetting to SUBMIT BY AC & f'd up using his registered 'lusrname' instead (just because he tried to mock me after I FAIRLY challenged him to show he's done better work - he had ZERO).
YOU EVEN HELPED ME https://science.slashdot.org/c... (& you quit trying to make hosts look 'ineffectual' on Intel speculative execution attacks & HOSTS HELP PREVENT THEM lol!)
APK
P.S.=> LMAO - I totally KNOW that 3rd/last link above?
It's KILLING YOU inside YOU ACTUALLY HELPED ME getting me to see if hosts stop more than just portsmash (they also stop Meltdown & Spectre too) - you got ME to look & "lo & behold" - hosts WORK by stopping you being INFESTED by what uses them against you (& YOU STOPPED TRYING THAT in your impersonations of me, lol).... apk
There is no performance problem in the web. There is javascript problem in the web.
...for certain tasks. If you need to rapidly prototype something; if you are dealing with a small amount of data; or if you need to run something just once a week or month then scripting is a quick way to accomplish this. But if you are doing anything many times each hour, dealing with huge data sets, or if otherwise performance is really important you don't use scripting! There is a reason why things like file system drivers, network controllers, or enterprise databases are not written in a scripting language.
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.
We suffer more in our imagination than in reality. - Seneca
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.
Who logs in to gdm? Not I, said the duck.
> "The fastest script is the script that is not loaded at all."
If the layered API proposal is implemented, we'll be able to import platform primitives (which could be browser-optimized)
something like
import { VirtualScroller } from 'std:virtual-scroller|https://unpkg.com/valdrinkoshi/virtual-scroller?module'
Sure, developers should learn CSS. I'm with you 100%, but let's not stick our heads in the sand and say 'noscript for all'
First I just want to say, I've told many students, and colleagues alike, that you can write shit code in any language.
If performance if the aim of the game, then I'd suggest we need a radical re-think. Javascript is querky and has odd behaviour that can't be versioned out if you want backwards compatibility. So onwards! With asm.js and now web assembly, we're seeing javascript evolving into Java with a heritage of script you can run alongside it. As impressive as that is, no one's questioning the fundamentals: Is HTML the right solution? Is CSS the right solution? Is Javascript the best best language to leverage the power of the browser?
When you look at DirectX driven games, and think about the organisational structures that manage all the graphical animations, and state changes inherent in a realtime system, - and then look at a web page, I think there's some pretty big and fundamental questions that need to be asked - and although performance-wise web assembly may lead us in the direction of faster code execution, - are we reaching the end of a long and winding road, or is there a flat motorway that we should be making that will lead to a faster, better, and possibly easier to manage and maintain - code base?
1. fast
2. secure
3. easy to use
On a long enough timeline, the survival rate for everyone drops to zero.
they need a SECURITY FIRST focus. those issues have been a profound problem with java anything for a long long time....and STILL ARE.
Vanilla.js is the most secure, most enabling javascript ever!
You can't beat Vanilla.js; it outperforms every other framework in usability.
Yet Vanilla.js is the smallest, most efficient, fastest loading framework available!
Vanilla.js 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 for your project, today!
$200k? This from one of the biggest companies in the world?
Joke.
No offense, as I appreciate you comment.
But I've developed web applications since 1996, and there never was a time where "the web" was just one reliable standard platform.
In the early days of HTML 3.x, it was a complete mess. No browser was compatible with any other one. Ever the minor versions differed enough to warrant a server side check.
Then the W3C put their foot down, and with HTML 4.x things got better, and with XHTML and proper CSS, DOM 1/2 and ECMAScript, things were actually properly standardized. But that didn't matter one bit, since IE6 still dominated the n00bspace, and it was utterly incompatible, even with itself. And buggy as hell. (I literally had nightmares about it for years.)
When IE finally started to die, hope was big... but the browser makers went full retard, founded the What(TheFuck)WG (as I call it), and not only reversed the whole cleanup that resulted in XHTML, but doubled down on it, in a way that nowadays would be called Trump-style. See, usually, you define a standard, to have a reliable basis, and then write implementations that guarantee this basis. Even if it will not include the newest fad, it will be *stable*. Which is the whole point of a standard. But they instead... took their horrible mess of a browser spaghetti code, and simply cast that into a "standard". And since their code monstrosities constantly mutated like a Lovecraftian horror, the standard as constantly adapted too. Which they named with the oxymoron "the living standard". Completely missing the stability point. I talked to them in person, back then, and know for a fact, that they had no clue what a standard even was. It was like talking to fanatics. (Comparable to SJWs.) Ignoring all reason, and seeing everything as an offense.
Then came the shameless extensions. Mainly from Google's Chrome. Feature after feature, API after API, until you saw "Best viewed in $incompatibleBrowser" lines in sites again. And *stupid* APIs too! (Like WebSockets. Which *could* have been a in-browser API to use sockets. But actually is an API to use a completely different WebSocket protocol that cannot talk to real sockets, and deliberately so. Because thou shalt not have any other Gods beside me. The "Framework" mantra.) In complete disregard of the needs of the developers out there, to need to know what the platform actually does at the end user side, regardless of the implementation or version.
TL;DR: The "web" is the most unstable and fluctuating platform there is. To say you "needn't think twice about what brand, version and Iteration of operating systems the target audience is running", is utterly absurd.
I quit the industry because of that Lovecraftian insanity.
google ought to invest some of their billions in the open source packages they use...