Slashdot Mirror


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."

7 of 82 comments (clear)

  1. Not gunna happen... by TFlan91 · · Score: 3, 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.

    1. Re:Not gunna happen... by Anonymous Coward · · 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 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.

  2. No, we're not. We have WebAssembly. by Anonymous Coward · · 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 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.

    1. Re:No, we're not. We have WebAssembly. by tepples · · Score: 3, Interesting

      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?

  3. I don't usually buy in to the language bashing... by Anonymous Coward · · 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 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.

  4. Re:If you want to speed up the framework by Anonymous Coward · · 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 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).
       

  5. Re:If you want to speed up the framework by AHuxley · · Score: 5, Interesting

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

    --
    Domestic spying is now "Benign Information Gathering"