Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
The Internet Chrome Internet Explorer Mozilla

Rapid Browser Development Challenges Web Developers 221

Esther Schindler writes "Feeling a little overwhelmed by changing web standards and new browser choices? You aren't the only one. Mozilla is launching development tracks for the next two editions of its Firefox Web browser immediately, with hopes to push both into general release before the end of the year. This while Microsoft previews Internet Explorer 10 on the heels of its IE9 release, and Google projects Chrome 13 just one year after Chrome 7. Meanwhile, HTML5, the next version of the Web's primary language, appears to have entered a permanent gestation phase. Writes Scott Fulton: All the confusion has prompted Web developers to ask this question: What do we develop our sites against now?"
This discussion has been archived. No new comments can be posted.

Rapid Browser Development Challenges Web Developers

Comments Filter:
  • Testing (Score:4, Interesting)

    by ustolemyname ( 1301665 ) on Tuesday May 31, 2011 @05:44PM (#36302094)
    Testing has become a bigger pain then it used to be. Before I could cover everything (except browsers on OS X) in just a handful of virtual machines. Now? The number of parallel installs required and the constant need to add new browser versions is becoming a pain.

    I'm starting to wonder if maybe it's simpler just to test against an older version of the browser (ie chrome 6) and the latest (chrome 12) and run with the assumption that nothing is broken in between. Thoughts?
  • by VortexCortex ( 1117377 ) <VortexCortex AT ... trograde DOT com> on Tuesday May 31, 2011 @06:54PM (#36302740)

    So -- We took SGML document language, then slapped on a shitty scripting language that successfully rode Java's coat-tails, on no other merit than "it's what's available". Then we tried to formalize everything, HTML5 got delayed (is still being delayed) for EIGHT YEARS...

    All for what? What did we do with a stateless distributed document display system and a scripting language? Why we built stateful applications out of them.

    We all booed and hissed at ActiveX and Java -- native code is insecure, no one has the right Java version installed, it's a slow VM! -- But now we take JavaScript and compile it into insecure native machine code, run it in a slow hybrid VM, and no two browsers have the all the same features, and visitors don't have a common version installed.

    Meanwhile someone discovered that if you give the general public access to a software repository, and give coders a stable platform and channel to access customers via -- You can do the exact same bullshit as a web-app with less resources, and make it graphically slick too. (Of course fracturing is starting to happen again -- The old beast of platform diversity rares its head -- Google needs to step up and say: "If you don't give your users the updates after a set period, you can't access the Marketplace with new devices" [with an exemption for older hardware] ).

    I'm no iFan, but this is what I've been saying since I wrote my first web app: "This sucks, it will eat itself alive with complexity as it gets popular".

    Hey the "web" is neat -- But bending your code to support non-standard browser extensions has bit us in the ass -- Abandon ship, It's not worth the hassle to keep bailing at this point -- look over there, a good ol' fashion Repository... and it doesn't leak development time/money like a sieve...

    Believe what you want. Yes, the web is too big to fail, but as long as we haven't learned that basic lesson -- Standards or Bust -- the platform (be it web or app) is doomed to be huge clumsy insecure zombie with an insatiable lust for mindshare, and development time.

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...