3 ms·

"Meanwhile, real sites still have to cope with a majority of visitors who don't have the latest shiny new features." Umm, isn't that what the 6-week-automatic-

by sciurus 15y ago

"Meanwhile, real sites still have to cope with a majority of visitors who don't have the latest shiny new features." Umm, isn't that what the 6-week-automatic-update cycle that you're arguing against is intended to address?

Silhouette 15y ago
No, because many people aren't using browsers that update every six weeks, and even those who are don't get the same updates every six weeks. In this case, as far as I can see, the only new "feature" they've shipped is actually to do with the update process itself, and it's a change that is pretty controversial at that. In fact, quite a few recent updates to Firefox (and Thunderbird for that matter) haven't really had much substance at all. Not exactly a great argument in favour of the need for such rapid updates.
- ok_craig 15y ago
  I wouldn't say there's a need for rapid updates; as a user, I just want them. I don't understand why users should be made to wait 6 months to a year for small features that are available now.
  - Silhouette 15y ago
    As a user, why do you want them? They are of no value to you unless sites or apps that you value are making use of them, and few production sites use most of the bleeding edge tech that supposedly justifies the rapid release cycle. A lot of that tech is of more interest for app-like pages rather than classical web sites, but then you start running into portability issues: not every browser has a fast cycle, and those that do aren't necessarily including the same features at the same pace. That means everyone needs to code a fallback approach anyway unless it's acceptable for their product to support only specific browsers. Once you start down that path, the core functionality is probably there for your users even if you don't then reimplement it a second time or add enhancements using the new technologies.
    - ok_craig 15y ago
      Browser updates are more than just html/css/javascript functionality updates. For examle, if Google updates the UI of Chrome and they can push it to me now, why not? I don't want to wait, and Google is giving me the option of not waiting. Or if they update their extension APIs and I want to make or use an extension that relies on them - why wait? Or if they make javascript run twice as fast for me. As a user, I love being able to get those things as soon as they're ready. > That means everyone needs to code a fallback approach anyway unless it's acceptable for their product to support only specific browsers. This has been and always will be true until 100% of the web uses the same browser. I'm not sure what the point of stating it is, or how a rapid-release schedule makes it worse. It doesn't.

by sciurus 15y ago

Silhouette 15y ago

No, because many people aren't using browsers that update every six weeks, and even those who are don't get the same updates every six weeks. In this case, as far as I can see, the only new "feature" they've shipped is actually to do with the update process itself, and it's a change that is pretty controversial at that. In fact, quite a few recent updates to Firefox (and Thunderbird for that matter) haven't really had much substance at all. Not exactly a great argument in favour of the need for such rapid updates.

ok_craig 15y ago
I wouldn't say there's a need for rapid updates; as a user, I just want them. I don't understand why users should be made to wait 6 months to a year for small features that are available now.
- Silhouette 15y ago
  As a user, why do you want them? They are of no value to you unless sites or apps that you value are making use of them, and few production sites use most of the bleeding edge tech that supposedly justifies the rapid release cycle. A lot of that tech is of more interest for app-like pages rather than classical web sites, but then you start running into portability issues: not every browser has a fast cycle, and those that do aren't necessarily including the same features at the same pace. That means everyone needs to code a fallback approach anyway unless it's acceptable for their product to support only specific browsers. Once you start down that path, the core functionality is probably there for your users even if you don't then reimplement it a second time or add enhancements using the new technologies.
  - ok_craig 15y ago
    Browser updates are more than just html/css/javascript functionality updates. For examle, if Google updates the UI of Chrome and they can push it to me now, why not? I don't want to wait, and Google is giving me the option of not waiting. Or if they update their extension APIs and I want to make or use an extension that relies on them - why wait? Or if they make javascript run twice as fast for me. As a user, I love being able to get those things as soon as they're ready. > That means everyone needs to code a fallback approach anyway unless it's acceptable for their product to support only specific browsers. This has been and always will be true until 100% of the web uses the same browser. I'm not sure what the point of stating it is, or how a rapid-release schedule makes it worse. It doesn't.