Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on from the faster-faster dept.

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

35 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 TFlan91 · · Score: 2

      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.

    2. Re:Not gunna happen... by 93+Escort+Wagon · · Score: 2

      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.

      --
      #DeleteChrome
    3. Re:Not gunna happen... by Hognoxious · · Score: 1

      I have somewhere a Udemy course called "Javascript - the actual fucking language, not any assbaking frameworks or shit".

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    4. Re:Not gunna happen... by Anonymous Coward · · 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, this works too:

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

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

    6. Re: Not gunna happen... by spongman · · Score: 1

      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.

    7. Re:Not gunna happen... by TFlan91 · · Score: 1

      The point wasn't the use of addClass, it was just a chosen method to demonstrate the issue of DOM lookups never being cached.

  2. Lemme guess... by Sebby · · Score: 1

    Funds only for Chrome-only improvements?

    --

    AC comments get piped to /dev/null
  3. Re:How about by alexo · · Score: 1

    [How about] security first? Oh no? Yeah, thought so.

    Well, it worked for Intel. Oh, wait...

  4. If you want to speed up the framework by 93+Escort+Wagon · · Score: 2

    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
    1. 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).
         

    2. 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"
    3. Re:If you want to speed up the framework by Daltorak · · Score: 3, 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!

    4. Re:If you want to speed up the framework by mnemotronic · · Score: 1

      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.

      --
      The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
    5. Re:If you want to speed up the framework by cascadingstylesheet · · Score: 1

      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 virtually all resources.

  5. Re:How to write performance-first code! by execthts · · Score: 1

    Too bad that browsers didn't caught some better scripting language like Lua or something else early on, now we're stuck with javascript for basically forever.

  6. Would not it be better to implement Security-First by williamyf · · Score: 2

    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!
  7. Better idea by Hognoxious · · Score: 1

    How about they just pay them to like totally go away?

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  8. 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 thegarbz · · Score: 1

      This is a great idea. I think we should tell Microsoft. They can do something crazy like integrate Internet Explorer into the underlying OS.

    2. 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?

  9. Re:How to write performance-first code! by execthts · · Score: 1

    May I introduce you to LuaJIT? http://luajit.org/

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

  11. Re:How to write performance-first code! by K.+S.+Kyosuke · · Score: 1

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

    --
    Ezekiel 23:20
  12. As a Javascript developer... by Anonymous Coward · · 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.

    1. Re:As a Javascript developer... by Desler · · Score: 1

      But it's a great craftsman that can recognize when a tool was constructed poorly.

  13. Re:How to write performance-first code! by Billly+Gates · · Score: 1

    No. All the cool kids are learning Techno Psycho Bitch now?

    --
    http://saveie6.com/
  14. Scripting languages are great... by DidgetMaster · · Score: 1

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

    1. Re:Scripting languages are great... by scamper_22 · · Score: 2

      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.

  15. You're spot on. And totally wrong. by Qbertino · · Score: 4, 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.

    --
    We suffer more in our imagination than in reality. - Seneca
  16. money should go to Gmail by citizenr · · Score: 1

    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.
    1. Re:money should go to Gmail by AvitarX · · Score: 1

      Took six seconds to load on my phone.

      The site is actually faster than the app.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
  17. pick two. by sad_ · · Score: 1

    1. fast
    2. secure
    3. easy to use

    --
    On a long enough timeline, the survival rate for everyone drops to zero.
  18. You have to use the BEST framework! by Medievalist · · Score: 1

    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!