Slashdot Mirror

← Back to Stories (view on slashdot.org)

Chrome 35 Launches With New APIs and JavaScript Features

Posted by Soulskill on from the can-now-run-for-president dept.

An anonymous reader writes "Google today released Chrome version 35 for Windows, Mac, Linux, and Android. The new version is mainly for developers, especially those building Web content and apps for mobile devices – this release doesn't appear to have any new features targeted at the end user. "

42 of 73 comments (clear)

  1. Shitty summary by loufoque · · Score: 1

    Seriously, I don't think I could have made a worse one even if I tried.
    How about giving some useful information, or maybe something that would actually be newsworthy?

    "New Chrome version with new features"
    OMG! Who knew this version thingies meant they added features!?

    1. Re:Shitty summary by ArcadeMan · · Score: 1, Insightful

      I thought the version was a penis length competition.

      At least that's what it looks like since Chrome and Firefox started changing major versions every fucking week or so.

      --
      Get free satoshi (Bitcoin) and Dogecoins
    2. Re:Shitty summary by johnsie · · Score: 1

      It's a load of horse shit. The new firefox UI shows that the have run out of ideas.

    3. Re:Shitty summary by almitydave · · Score: 1

      I thought the version was a penis length competition.

      At least that's what it looks like since Chrome and Firefox started changing major versions every fucking week or so.

      It's not just the version number, everyone knows you have to take the version number times download size divided by the square root of length between releases (in days).

      --
      my, your, his/her/its, our, your, their
      I'm, you're, he's/she's/it's, we're, you're, they're
    4. Re:Shitty summary by SeaFox · · Score: 1

      "New Chrome version with new features"
      OMG! Who knew this version thingies meant they added features!?

      Yeah, nobody changes the version number for bugfix-only releases.

    5. Re:Shitty summary by dugancent · · Score: 1

      Firefox v4 - released 22 March 2011
      Firefox v29 - released 29 April 2014

      Two years and 27 versions. Hmmm..

      --
      SJWs are the new boogeyman. -Me
    6. Re:Shitty summary by dugancent · · Score: 1

      Er, three years.

      --
      SJWs are the new boogeyman. -Me
    7. Re:Shitty summary by Bacon+Bits · · Score: 1

      I've said this many times before, but all they've done is just merged major and minor version numbers into a single version. We're really at around Firefox 7 or 8 if they'd kept the old versioning scheme. Somewhere out there there's a branch map that shows they've only done a major branch a handful of times.

      Think about normal versioning and updates. You get:
      1. Major updates - These are supposed to have major features and UI changes. Major version increment.
      2. Minor updates - These are supposed to have minor features and bug fixes. Minor version increment.
      3. Security and fast track updates - These just have security fixes or emergency bug fixes. Point version increment.

      The question to ask is: what's the difference between 1 and 2? If you're spending a lot of time delaying features or arguing about what needs to be delayed for six months to a year to wait for an official release, then you're spending a lot of time spinning your wheels. You develop a major feature, and can't implement it for a year. Then, a year later after you've forgotten everything, you finally get feedback and bug reports. Now everything you built on top of your new feature also has to be reconsidered, and God forbid you have to do a rollback. So, let's scratch that. When major features get finished, they get released. You get immediate feedback, don't have to learn to ride the horse again to fix them, and feel a lot more free to get stuff done.

      However, since there's no longer a distinction between 1 and 2, you can't use different version elements. You can't predict when a release will have a major feature, you don't want to argue about what a major feature is, and you don't want to backslide into the old versioning nomenclature and delaying features needlessly. So, you throw out the major and minor. Now you just have point releases (emergency bugs and security) and version number (everything else). However, also notice that because you can't predict when you'll release a major feature, you can't predict your release schedule. At all. So, instead of constantly hemming and hawing about when to release, you just do it periodically. After X weeks or months, you do a freeze and then a bit later you push dev to test and test to prod.

      The drawback is you irritate your users. Consumer users won't really care that much, although many won't understand why your version numbers move so fast. Businesses will get annoyed because they like to standardize on single versions and stick with them for far too long, so maybe you create an "extended support" version which has old style version numbers. In that system, your major version number is whatever arbitrary release you pick, and then some unfortunate soul gets to backport security and emergency fixes. They don't get any of your new features, but they're businesses. They won't want features. They just want functionality and conformity.

      --
      The road to tyranny has always been paved with claims of necessity.
  2. Re:don't be stupid by NotInHere · · Score: 3, Insightful

    You are not stupid when you develop "web apps" -- you get al your customer's data. You are only stupid when you use them for more serious things than 2048.

  3. Random sized fonts fixed in Android by Threni · · Score: 1

    You know, like when you read Slashdot and you might want each story to have the same sized font. Is rendering a font in the correct size difficult; is there a technical reason for this?

    1. Re:Random sized fonts fixed in Android by gmagill · · Score: 1

      No. It's not.

  4. Re:Version 35 of the now venerable spying portal by nctritech · · Score: 2

    Links2 is working just fine, thanks.

  5. Re:Version 35 of the now venerable spying portal by walterbyrd · · Score: 1

    What makes you think that Microsoft spies on you any less than Google?

    If you do think that, can you provide hard evidence?

  6. Re:don't be stupid by rudy_wayne · · Score: 5, Insightful

    this release doesn't appear to have any new features targeted at the end user. "

    Good. Browsers should have stopped adding "features" 5 years ago. Display web pages and shut the fuck up.

  7. Re:CHROME 1 to 34 APIS OBSOLETE !! by walterbyrd · · Score: 1

    What makes you think that?

  8. Does it have an API for NoScript yet? 5 years? by dicobalt · · Score: 4, Interesting

    Been waiting for that 5 years now... http://forums.informaction.com...

    1. Re:Does it have an API for NoScript yet? 5 years? by drobety · · Score: 2

      > Been waiting for that 5 years now

      The myth, It still go on... There:
      Blocking javascript execution reliably in Chromium based browsers

    2. Re:Does it have an API for NoScript yet? 5 years? by x_t0ken_407 · · Score: 1

      Very interesting and informative...damn my lack of mod points.

  9. Re:Version 35 of the now venerable spying portal by jader3rd · · Score: 1, Interesting

    Competence, Organization, and privacy policy. Even if Microsoft wanted to break their privacy policy and spy on an end user as much as Google does, they couldn't pull it off because it would require too much coordination among too many different organizations for them to be able to pull it off.

  10. Re:Version 35 of the now venerable spying portal by kesuki · · Score: 1

    what makes you think anyone still uses internet explorer. inflated botnet numbers from microsoft? oh wait windows 8 by default has about 20 automatically refreshing tabs with internet explorer. between win8 and botnets the traffic is skewed.

    android is proof that open source and 'free software' are a far cry from each other, and it tracks a lot of data while i have yet to hear of free software containing adware.

    --
    https://www.gnu.org/philosophy/free-sw.html
  11. Which environment instead? by tepples · · Score: 4, Insightful

    What cross-platform application environment would you recommend other than the HTML stack? Oracle Java and Adobe Flash/AIR don't have a spotless security record either. Or would you prefer to have to write 14 different native applications for 14 different platforms? You could have a web app written, tested, and deployed before you even finish applying to become an authorized developer on half of those platforms.

    1. Re:Which environment instead? by aztracker1 · · Score: 3, Insightful

      For the most part the cross browser stuff is pretty straight forward these days, and if you're building a web application (not site) you can limit yourself to modern browsers without too much trouble... depending on your browser feature needs of course. IE11 is decent, 10 isn't bad, and 9 is doable. If you use react, angular or ember as a base, it's as good as most component ui systems. It's still easier than a cross platform codebase for native apps.

      --
      Michael J. Ryan - tracker1.info
    2. Re:Which environment instead? by nine-times · · Score: 1

      Personally, I'm of the opinion that we should have two different apps: One for development of relatively passive "web pages", perhaps with limited capabilities, but very secure, and then another built to be a portable application framework for "web apps". I think it's kind of great the way Chrome now allows you to have apps that seem like separate native applications, but does all of that functionality need to be tied directly to my normal web browser?

      Ultimately, it boils down to this: Most of the time, I want very basic web browser functionality. Whenever that's the case, any extra capabilities you offer to access local file storage, cache persistent data, or run complex code just ends up being a security risk. Then when I want a more serious "web app", I would usually prefer that it appears separately, as its own window. So even if my web pages and my web applications are relying on the same technologies (e.g. HTTP, HTML, CSS, Javascript), I'm using them differently and I would prefer that they behave differently. So why must it be that the same web-browser application does both? Why not create a highly efficient cross-platform application framework based on those technologies, and keep the browser simple?

  12. Re:meh by tepples · · Score: 2

    how about bloody 64bit on mac.?

    Chrome was one of the first popular web browsers to use a separate process per tab. This architecture makes 64-bit less necessary because each tab is expected to use less than 2 GB of RAM.

    you pretty much need to use java7 today

    Which major web sites still use Java applets as opposed to SWF or HTML5?

  13. Re:Version 35 of the now venerable spying portal by tepples · · Score: 1

    what makes you think anyone still uses internet explorer.

    I don't think most Windows users obtain Firefox or Chrome through FTP or by downloading it to a USB flash drive on a separate computer. Even Google agrees that it should be called "Microsoft Firefox Downloader": look at what it bolds in the search results.

  14. Font inflation in mobile browsers by tepples · · Score: 1

    I think the reason is that most "desktop" web pages are made for 900px to 1000px wide displays. This fits on a 1024-pixel-wide netbook display or on a 960-pixel-wide half of a 1080p display. But it doesn't fit so well on a 7" tablet that's only about 540px* wide. So the web browser has to zoom the page out and zoom the text back in. And to avoid disrupting the layout, it needs to use heuristics to determine which textual elements to enlarge. See an article about font inflation in Firefox for Android.

    * In CSS, 1px doesn't represent a device pixel. It means 1/2688 of the distance from the eye, which happens to equal one device pixel for a 96 dpi screen 28 inches away from the user but can cover more pixels on a higher-density output device. Because a phone or tablet is held closer to the eye than a desktop PC monitor, Android assumes 160px per inch. This usually translates to a scale factor of 1, 1.5, or 2 between CSS px and device pixels. Early 7" Android tablets had a 480x800 pixel display and left px == pixel. The first-generation Nexus 7 had a 800 pixel wide 216 dpi display and scales px by 1.5. The second-generation Nexus 7 has a 1200 pixel wide 323 dpi display and scales px by 2.

    1. Re:Font inflation in mobile browsers by Threni · · Score: 1

      Intersting link, thanks. And interesting that it mentions how tedious it is to have to scroll left and right when the screen isn't wide enough to display the text, and that Firefox's reflow code handles this. Chrome doesn't have reflow, so you're forced to scroll left and right for every single line of text you want to read on most (ie non-mobile) web pages.

  15. Reading TFA by BillX · · Score: 1

    I'm not remotely interested in Chrome, but I want to see what's in store for Firefox about 2 releases from now.

    --
    Caveat Emptor is not a business model.
    1. Re:Reading TFA by lemur3 · · Score: 1

      I'm not remotely interested in Chrome, but I want to see what's in store for Firefox about 2 releases from now.

      this is clearly a joke....but if you actually want to see whats in store for firefox 'about 2 releases from now' just start using the firefox Nightly branch:

      https://nightly.mozilla.org/

      they recently implemented a new http cache http://www.janbambas.cz/new-fi...

      they moved the preferences into the webpage area instead of in a popup window http://msujaws.wordpress.com/2...

      in windows theyve implemented OMTC https://wiki.mozilla.org/Platf...

      and they have been continuing work on their one thread/process per tab project.. https://wiki.mozilla.org/Elect...

    2. Re:Reading TFA by spiralx · · Score: 1

      Thanks, that has explained that the "frecency error blah blah" messages I'm seeing in my console aren't just someone's epic fail at committing a spelling mistake :)

  16. Side Tabs by labnet · · Score: 2

    Been waiting for that 5 years now...
    http://forums.informaction.com...

    And the three years since some dude called 'glen' took out side tabs; which is why I went back to firefox (treestyle tabs ftw)

    --
    46137
  17. Re:meh by dottrap · · Score: 1

    how about bloody 64bit on mac.?

    Chrome was one of the first popular web browsers to use a separate process per tab. This architecture makes 64-bit less necessary because each tab is expected to use less than 2 GB of RAM.

    It's not about addressable memory space.

    64-bit usually yields better performance due to more registers and the fact that i386 was a register starved architecture.

    But more importantly, everything on modern Mac is now 64-bit. Anything that is 32-bit must load in a 32-bit version of every shared system library that the application touches. At a minimum, Firefox would have to load in the entire 32-bit version of the Cocoa frameworks (because Firefox needs to at least create a native window). If Firefox is the only 32-bit app resident on your system (which is highly likely today), then it's wasting gobs of your system RAM and probably making you swap to disk more.

  18. Re:meh by tepples · · Score: 1

    I wasn't aware that major features of Chrome relied on the Java virtual machine. Can you provide a citation so I can confirm this and learn why Google chose to do it that way?

  19. Re:don't be stupid by freezin+fat+guy · · Score: 1

    How are "developer" features not features for the end user? Don't users interact with web pages?

    By that logic you could argue that HTML 2.0 form support is only a developer feature. The fact that it enables the end user to input data doesn't make it a feature for that end user?

  20. Re:Version 35 of the now venerable spying portal by dave420 · · Score: 1

    That didn't actually happen as you seem to think it does, which reflects more poorly on you than it does MS.

  21. Re:don't be stupid by dywolf · · Score: 1

    i was rather hoping that as Firefox and Opera have both decided to become little more than Chrome clones, replete with crappy interface and lack of customization (especially when Opera 12 was the KING of layout customization, a truly exceptional peice of software), that Chrome might opt to add more customization.

    To be clear:
    Firefox needs to stop chainging its UI every few releases. So when Firefox 29 finally became Just Another Chrome Clone (JACC), it amused me that it took only 24 hours for an extention called "Classic Firefox Restorer" or whatever to hit the web and become one of the most popular firefox extensions (but of course the devs will ignore that)
    Opera 12 was the best browser I have ever used. The only reason I no longer use it exclusively, is because they've stopped updating it, and its page renderer chugs on many common pages these days. and now Opera 20 is JACC, that axed basically everything that appealed about Opera.

    If I wanted to use Chrome, I would bloody use Chrome.
    Stop messing with your browsers and alienating your users in the quest to chase Google with your JACC's.

    --
    The guy who said the election was rigged won the presidency with the second-most votes.
  22. What different behavior? by tepples · · Score: 2

    So even if my web pages and my web applications are relying on the same technologies (e.g. HTTP, HTML, CSS, Javascript), I'm using them differently and I would prefer that they behave differently. So why must it be that the same web-browser application does both? Why not create a highly efficient cross-platform application framework based on those technologies, and keep the browser simple?

    Because by the time you make an HTML5 web application browser usably efficient, it's already also reasonably efficient at displaying web pages. What different behavior would you prefer in a subset browser suitable only for "web pages"? And where should one draw the line between a "web page" and a "web application"? Which is a forum? Which is a wiki? Which is a blog with a comment section? Which is a microblog host like Pump or Twitter? Which is a microblog host that allows adding GPS coordinates to posts?

    1. Re:What different behavior? by nine-times · · Score: 1

      What different behavior would you prefer in a subset browser suitable only for "web pages"? And where should one draw the line between a "web page" and a "web application"?

      Figure out what subset of scripting and data caching you can build into the browser without allowing privacy/security vulnerabilities, and set that as the limit for the "web browser" so that we'll all know our web browsing is safe. If that hamstrings your web application too much, then sorry, build an application.

    2. Re:What different behavior? by tepples · · Score: 1

      Figure out what subset of scripting and data caching you can build into the browser without allowing privacy/security vulnerabilities

      Forgive me for appearing like ELIZA, but in order to figure that out, we first need to define what constitutes "privacy/security vulnerabilities".

  23. Java with browser by tepples · · Score: 1

    Why would Java require a web browser in the first place?

  24. Registers vs. pointer size by tepples · · Score: 1

    It's not about addressable memory space.

    64-bit usually yields better performance due to more registers and the fact that i386 was a register starved architecture.

    I thought there was a tradeoff between register starvation and data cache starvation. There are fewer registers on x86, but the pointers are half the size (without the so-called "x32" ABI that didn't catch on).

    1. Re:Registers vs. pointer size by dottrap · · Score: 1

      The op complaint was no 64-bit Firefox for Mac. Apple doesn't do x32, so it's not even an option.

      Data starvation can be mitigated/manually controlled in 64-bit by understanding your data. High performance code utilizes contiguous blocks of memory and is very aware of data layout, and isn't going to be pointer chasing. So allocating arrays of types that use int32_t instead of int64_t is a trivial example. So in a 64-bit architecture, you still generally win performance-wise.

      x32 failed for a lot of reasons.
      From the article you cited, here's a quote:
      "they just really don't see the [x32] ABI as being worthwhile ... to make maintaining an extra ABI worthwhile."

      As the quote highlights, the real crux of the problem is how much of a pain it is to maintain yet another ABI.
      The performance differences for x32 didn't justify it over true 64-bit. That means the data starvation due to larger pointer sizes wasn't the dominating factor. So going from i386 to x32 vs. i386 to x64, the latter wins because it gets the speed of more registers, negligible performance impact for pointer size differences, and the plus of large addressable memory if you need it.

      To show the pain of another ABI, here is a simplified example: You are using a video editor in GNOME under x32. You suddenly need more than 4GB of addressable memory. That means you needs a x64 version. But then you need a GNOME that is also built as x64, so you have to load up an entirely separate instance of GNOME, all its dependencies, and the video editor. Either you need to shutdown your current environment and reboot another, or you need to load both simultaneously. (This is what happens now when you load 32-bit i386 on modern Mac, hence a large RAM hit, not to mention that every binary also takes double the disk space.)