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

82 comments

  1. How to write performance-first code! by Anonymous Coward · · Score: 0

    Step 1: Don't use JavaScript.
    Step 2: Did I fucking stutter?

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

    2. Re:How to write performance-first code! by Anonymous Coward · · Score: 0

      >suggests Lua instead of JavaScript for performance

      That's quite possibly the only language that's even *slower* than JavaScript.

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

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

    4. Re:How to write performance-first code! by Anonymous Coward · · Score: 0

      Well, didn't we have JavaScriptJIT already?

      Which of course ment that all the webmonkeys with the latest nightly builds started to write even shittier code that dramatically slowed down on older browsers. That's going to happen again, since only the newest latest bestest betaest browsers have all the "speedup"-features.

      So this is the "living standard"isation of ECMAScript. "Performance-first code". Syeah right.

    5. 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
    6. Re: How to write performance-first code! by Anonymous Coward · · Score: 0

      Strip 3: donâ(TM)t include Google ad and âoeanalyticsâ tracking scripts.

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

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

    8. Re:How to write performance-first code! by Anonymous Coward · · Score: 0

      Javascript has been something of a sham.

      in 199x, the beginning, 99% of javascript was document.write , that's it. It was a lazy way to add things to a site based on a few client-side variables.

      Then came Perl and PHP as server languages, where you could actually selectively render the page. Many CMS's were designed this way by design, however the piles of shit started getting ever bigger (Wordpress currently requires 256MB to render a 20KB page) and thus pushing the optional shit to the client was the entire purpose of "frameworks", sure it looks faster, but it's really just sucking down your CPU instead of the server.

      Fast forward to "web 2.0" technologies, now every website has so much javascript cruft on it that people actively block some or all of it when they are on bandwidth-constrained devices so they're not penalized with 25MB page loads of rapidly refreshing scripts.

      Web 3.0 will be the pushback, micro-assembly language libraries instead of shitty frameworks. The server will send only the data needed to render the page, the client will load a small 25KB library that represents ONLY the shit actually used by the website, and it will be compiled by the server the first time a client asks for it and then cached for future users of that device until stale. Not the current "webassembly (WASM)" which is a fucking disaster and allowing all kinds of malware and crypto miners in as a backdoor. Clients will send a request for micro-assembly in a specific instruction set, and thus allowing both backend and front end services to be written in anything and then converted to assembly for x86-64, ARM, etc. If the server doesn't know what language the client speaks, it then sends the intermediate code (similar to WASM) for the client to compile itself. At no point does the client ever run any micro-assembly hosted anywhere but on the first party site.

      No third party code unless it's in the global whitelist, which users will be prompted to (example.com is requesting to run a script from example.org: run always, run once, run never (this site will never be permitted to run this script and you will not be prompted again), blacklist (do not run and prevent any site from running scripts from this third party site) for 30 days (refreshed by AV software))

  2. How about by Anonymous Coward · · Score: 0

    security first? Oh no? Yeah, thought so.

    1. Re:How about by Anonymous Coward · · Score: 0

      well of course.. they want to eliminate the gap between local software and javascript garbage locked behind a paywall.

    2. Re:How about by alexo · · Score: 1

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

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

  3. hahahaha by Anonymous Coward · · Score: 0

    Let's cram more datamining into our websites thanks to performance improvements!!!!!

  4. "performance problem" on the web.. by Anonymous Coward · · Score: 0

    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.

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

      I mean to toot my own horn when I say that I am a master journey trainer and my students stand as a shining example of my dedication, perseverance, and ability to teach jquery even to the most inept of fools

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

    7. Re: Not gunna happen... by Anonymous Coward · · Score: 0

      Yup.

    8. Re:Not gunna happen... by Anonymous Coward · · Score: 0

      That space-separated library-specific microsyntax does not sound like something that makes support work easier. You'll have to either know or have checked the documentation, neither of which is optimal.

      The best option would be if the JIT compiler (or some other component) would just optimize the duplicate $('.someEle') requests away.

      Properly indented, chaining is not really bad either.

    9. Re:Not gunna happen... by Billly+Gates · · Score: 0

      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.

    10. Re:Not gunna happen... by Anonymous Coward · · Score: 0

      Any time I see "Software Engineer" on a resume it gets autobinned. "Programmer", "Software Developer", even "Chief Code Monkey" is acceptable.

      But engineer tells me a lot about the applicant without even meeting them. If they lie so blatantly up front then why should I think they aren't the type to mindlessly copypasta everything until it "works", wasting our company's revenue?

      Most reliable filter there is.

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

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

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

    Funds only for Chrome-only improvements?

    --

    AC comments get piped to /dev/null
  7. What is the Tradeoff for "Performance-First"? by Anonymous Coward · · Score: 0

    Presumably Intel embracing the "Performance First" ideology is what had led to the Meltdown vulnerability.

  8. 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: 0

      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.

      Then that would slow down production. If you are going to use 2, 5-line functions, don't use a framework. Yes, I agree. That's not the intended use of frameworks though. Just because you make something, doesn't mean you can prevent others from using it stupidly. I think this is just intended to speed up frameworks that are used properly.

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

    3. 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"
    4. 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!

    5. Re:If you want to speed up the framework by Anonymous Coward · · Score: 0

      Our NPM dir has 42,000 files under it. The transitive dependency bloat for common JS frameworks is ridiculous.

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

      22 megabytes for just some bunch of text and actually no picture? Wow, the web really has become bloated.

      I rewrote my whole website (full responsive) with no JS and under 1M, tops.

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

  9. 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!
  10. How about stability first? by Anonymous Coward · · Score: 0

    Not that any web "developer" would know the first thing about it, with the "living standard" oxymoron being the core of their religion.

  11. 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."
    1. Re:Better idea by Anonymous Coward · · Score: 0

      I suppose you would preface that with "I could be wrong, but I don't think so"?

    2. Re:Better idea by Anonymous Coward · · Score: 0

      Because Google can track you way better with JS enabled and running.

  12. 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 Anonymous Coward · · Score: 0

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

      Bruce Schneier once said, "You can't secure what you can't understand." or words to that effect.

      One of the reasons the web is a security nightmare is we allow things like arbitrary programing languages to run, such as, well javascript and now web assembly, etc, etc.

      I wish there was a way we could turn back, but I fear there is not.

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

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

  13. Re: Brilliant. by Anonymous Coward · · Score: 0

    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

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

  15. jquery's great for demos by Anonymous Coward · · Score: 0

    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.

  16. Whenever google gives money to something by Anonymous Coward · · Score: 0

    It's for google to profit. Not to benefit you or anyone else.

  17. It's still JS, and WebApps will always be shit by Anonymous Coward · · Score: 0

    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.

  18. Convert to C ? by Anonymous Coward · · Score: 0

    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.

  19. "Supporting yourself" by AC again? apk by Anonymous Coward · · Score: 0

    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

  20. 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 Anonymous Coward · · Score: 0

      It's a poor craftsman who blames his tools.

      My languages are C, C++, and various dialects of assembly. I'm using a Katana, you're using a butter knife.

      Fuck your tools.

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

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

    3. Re:As a Javascript developer... by Anonymous Coward · · Score: 0

      Arguably, most Javascript are bad developers, in the sense that they are "bad" as in "bad people", as opposed to the bad Java developers (thanks to the demise of the applet) are just bad developers in the sense that they are bad _at_ Java.

      The difference is that the Javascript developers target a computer not their own for their code to run on. They have externalized all costs, risks, and consequences of writing terrible code on to someone else. It takes a rare Javascript developer to create website that does not require the user to run their code.

      The problem with Javascript developers is that they refuse to acknowledge that they're on the side of the bad guys.

  21. IMPERSONATING ME AGAIN? apk by Anonymous Coward · · Score: 0

    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

  22. dear google by Anonymous Coward · · Score: 0

    There is no performance problem in the web. There is javascript problem in the web.

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

  24. 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
    1. Re:You're spot on. And totally wrong. by Anonymous Coward · · Score: 0

      The browser seems to "win" because you get stuff done on various OSes. But then it fragments, like all unification attempts do.

      C was made to be more portable than assembly. It was, but then you got different C on different hw platforms. 16-bit, 32-bit, IBM, DEC, . . .

      Java was meant to be much more portable than C. But then you got a hodgepodge of different versions, as well as 32-bit or 64-bit.

      The browser has already fragmented, but it doesn't seem that way because earlier incompatible browsers died off. But it will happen again. MS or Apple or Google will bring out a browser that is "better" than the others because it has unique features. The others will compete, and pages will be written for "this browser or that browser or the generic slow version that nobody uses."

  25. 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
  26. The fastest script by Anonymous Coward · · Score: 0

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

  27. The problem is Javascript? by Anonymous Coward · · Score: 0

    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?

  28. 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.
  29. java needs performance above all???? by Anonymous Coward · · Score: 0

    they need a SECURITY FIRST focus. those issues have been a profound problem with java anything for a long long time....and STILL ARE.

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

  31. Missing 2 zeroes by Anonymous Coward · · Score: 0

    $200k? This from one of the biggest companies in the world?

    Joke.

  32. You clearly never developed for the web. by Anonymous Coward · · Score: 0

    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.

  33. billions in profit, pennies for open source by Anonymous Coward · · Score: 0

    google ought to invest some of their billions in the open source packages they use...