Forgot your password?
typodupeerror
The Internet Chrome Internet Explorer Mozilla

Rapid Browser Development Challenges Web Developers 221

Posted by Unknown Lamer
from the commitment-is-too-scary dept.
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:
  • HTML 3.2 (Score:4, Funny)

    by Hatta (162192) on Tuesday May 31, 2011 @05:40PM (#36302050) Journal

    HTML 3.2. If you can't do it with HTML 3.2, you don't really need to do it.

    • Re:HTML 3.2 (Score:4, Funny)

      by The MAZZTer (911996) <megazzt@g m a il.com> on Tuesday May 31, 2011 @05:42PM (#36302070) Homepage
      IE7. If you can't do it with IE7, our clients don't want it. :(
      • by ep32g79 (538056)

        IE7. If you can't do it with IE7, our clients don't want it. :(

        Consider yourself lucky, I'm still stuck with supporting IE6. PNG overlays, forgettaboutit.

      • by anyGould (1295481)
        Really, if your software doesn't work on Lynx...
        • Funny, yes, but making sure your site works on Lynx at least to the point that it's comprehensible is a handy proxy for making sure it'll work for a screen reader.

    • Yeah sure, i'll just file that quote alongside "640k ought to be enough for anybody".
    • Re: (Score:3, Insightful)

      by next_ghost (1868792)
      HTML 4.01 Strict. At least until W3C comes back to its senses and drops the "living standard" crap for HTML5.
      • HTML 4.01 Strict.

        Amen to that! I've had many arguments in the past over HTML 4.01 Strict vs. XHTML. My conclusion was that unless you're using inline SVG, MathML, or XSL-based stylesheets for a website (a terrible idea), there was no real benefit to advancing beyond 4.01 Strict. Things will probably eventually change with HTML5, but not if it's a moving target.

      • by AmiMoJo (196126)

        Problem is that users expect more from a web site these days. Limiting yourself to HTML4 results in masses of Javascript to implement features that are native to HTML5, and lots of bandwidth wasting images to make up for deficiencies of CSS and lack of things like font and SVG support.

        A lot of web developers do all that stuff anyway to make up for incomplete or differing HTML5 implementations, because the alternative is trying to maintain two versions of the code to satisfy compatible and incompatible brows

  • by arth1 (260657) on Tuesday May 31, 2011 @05:42PM (#36302074) Homepage Journal

    What do we develop our sites against now?"

    Why, standards, of course. To develop a web site "against" or "for" browsers is having lost the battle before you've even started it.

    • You must have not been paying attention over the past 15 years; the battle was already lost, people have been developing against browsers and not standards for a long time.
      • See comment on "testing" - if we simply targeted standards, we'd never deliver product.

        BTW, this happens in other industries too. Life is harder than college - get used to it.

        • by arth1 (260657) on Tuesday May 31, 2011 @05:59PM (#36302232) Homepage Journal

          See comment on "testing" - if we simply targeted standards, we'd never deliver product.

          You target standards, and test with a validator before it even hits the first browser in test phase 2. That reduces the delivery time.
          Especially when a new browser comes out in the middle of the development process, and you won't have to rewrite a single line of code.
          Oh, and it will be future proof too, and work just as well in Firefox 7 as in IE 12.

          • You target standards, and test with a validator before it even hits the first browser in test phase 2

            Which would be more useful, if browsers met those standards reliably. Even modern browsers have quirks. In IE 9 for example rounded borders suddenly stop working on a fieldset if it has a legend.

            I am fortunate enough to only have to deal with vaguely modern browsers (I mostly work on a non public app where we can set reasonable minimum requirements for supported browsers) but there are still nasties and

            • In IE 9 for example rounded borders suddenly stop working on a fieldset if it has a legend... I mostly work on a non public app...

              Oh dear, please tell me that "no rounded borders on a non-public form" was never an actual deal-breaker.

        • by DrXym (126579)

          See comment on "testing" - if we simply targeted standards, we'd never deliver product.

          BTW, this happens in other industries too. Life is harder than college - get used to it.

          The correct way to develop web content is against the standards and make exceptions where necessary for a browser. It may be that QA sort browsers into various tiers so some browsers need more attention / hacks than others. But always code to the standard first. If it turns out IE has a problem with some CSS rule, or Firefox has a race condition for something else you can surgically deal with that one problem and leave the rest standard. AJAX tools like JQuery help too especially for perrenial headaches lik

      • by Anonymous Coward on Tuesday May 31, 2011 @05:59PM (#36302234)

        You must have not been paying attention over the past 15 years; the battle was already lost, people have been developing against browsers and not standards for a long time.

        Just because it's the way it has always been done doesn't mean that it is correct. Develop for standards. The browser that best supports the standards will be the one that wins. The browser developers should be the ones aiming for compatibility, not the web developers. Once you make the switch, the only viable browsers are the ones that support standards. Bye bye IE. See you never.

        If enough high profile clients complain to microsoft that their browser makes their site look funny, maybe they will actually fix it. I realize this is easier said than done, but it's a case of throw a handful of developers for the browsers at the problem to make it standards compliant, or throw millions of developers at the web programming end to try to keep up with it. On the other hand Woo! Job Security!

        • by achbed (97139)

          The browser that best supports the standards will be the one that wins.

          Wrong. The browser that the corporate IT organizations use wins. Period. If some giant corp requires the use of IE6, you will code to that because they will not allow you to dictate the internal "approved" infrastructure because you want something fancy like proper DIV handling or modern security. The larger the company, the more it becomes "the devil you know".

      • by Lennie (16154)

        That is one of the many reasons why we have HTML5 now, so we don't need to do that.

    • by Anonymous Coward

      ....IE 6!

    • by Daniel Dvorkin (106857) on Tuesday May 31, 2011 @05:54PM (#36302190) Homepage Journal

      Yeah, but what standard? That's the problem. For a number of years, ever since we got past the bad old days of Netscape vs. IE, you could point at HTML $NUMBER and say, "that's it, that's the standard." Kind of the point of TFA is that you can't do that anymore, or won't be able to shortly, and it sucks.

      • by ep32g79 (538056)

        Yeah, but what standard?

        In most of my web development work it's always been the client that sets the standard. There have been some clients that have said "Support IE6 and beyond" (/cringe) and others that have more reasonable standards, e.g. IE7+, Firefox 3.5+, Chrome 9+

        • by grahamd0 (1129971)

          In most of my web development work it's always been the client that sets the standard. There have been some clients that have said "Support IE6 and beyond" (/cringe) and others that have more reasonable standards, e.g. IE7+, Firefox 3.5+, Chrome 9+

          I've never felt that IE7 was substantially better than IE6.

          The addition of transparent PNG support and a few more CSS selectors is great, but it's got almost all of the same rendering bugs that IE6 does.

          • by yuhong (1378501)

            Yea, from what I read IE7's layout engine feels like a hack on top of IE6's. It isn't just CSS, BTW. Guess why the contents of OBJECT elements don't show up in the DOM in IE7? Clue: IE7 fixed the bugs where nested object elements were still initiates even when fallback is not needed.

      • by dudpixel (1429789)

        what?

        pretty sure you can still code for HTML1 and it will still work.

        It seems like people are worried that they wont be using the latest stuff when the product finally ships...but if you dont know what the latest stuff is yet, then this is just silly.

        develop for HTML5. done.

        Its not like any new standard that shows up will mean that HTML5 will suddenly stop working. The web still works even though we have new browsers...and I'm pretty sure no one is going round updating every single website in the world ev

        • develop for HTML5. done.

          Again, the point is that you cannot define what "develop for HTML5" means the way you could define "develop for HTML $X", where $X was any release from 1 to 4 (including point releases.) That is not a good thing.

          • by Jonner (189691)

            That's why we develop for XHTML 1.0 where I work. We don't need any of the fancy new features and we don't have to spend much time thinking about browser compatibility.

        • I have never understood why people love to shoot themselves in the foot by targeting browsers with weird hacks. Just use the common ground that all browsers support. Design additional elements so that the browser can degrade smoothly to something simpler if it does not support them -- This degradability [anybrowser.org] is not well understood or practiced by the average web developer in my eyes.

    • by Phyridean (1122061) on Tuesday May 31, 2011 @05:58PM (#36302224)
      Not that I disagree with your philosophy, but this is rather like saying "Don't develop for real-world conditions. Develop for our theories! I don't care that the real world doesn't conform to our theories, it really should." and then being surprised that whatever you're building doesn't actually work.
      • by arth1 (260657) on Tuesday May 31, 2011 @06:11PM (#36302344) Homepage Journal

        Not that I disagree with your philosophy, but this is rather like saying "Don't develop for real-world conditions. Develop for our theories! I don't care that the real world doesn't conform to our theories, it really should." and then being surprised that whatever you're building doesn't actually work.

        And that is how you should develop. But, you should, of course test against real world conditions, once you have working code, and not a moment before.
        Fix or adjust for the few browser-specific issues that may be left at that point -- they will be far fewer than the issues you create if you code for real world browsers - that's painting yourself into a corner, and pretty much guaranteeing that your product will fail spectacularly when a new browser enters the market.

        Resist the temptation to want to see how the web site looks before it's finished. It doesn't buy you anything, and sidetracks you. If you build a building, you build it according to code, and don't build it to fit particular users, or move the windows and resize the doors while building because of how one individual is built.

        • by pavon (30274)

          Yeah, we should be writing standards compliant code. Nobody disagrees with that. However, all of the browsers only implement a subset of the standard, and if you implement an important feature using part of the standard that isn't well supported yet, then you fucked up. Last minute tweaking won't fix that; you have to completely redo the code using a different approach.

          You need to know what subset of the standard to use before you start coding. This is arguably getting more difficult these days as W3C takes

        • by grahamd0 (1129971)

          More junior developers are usually surprised when they show me a site that works great in Firefox or Safari, but breaks in IE, and the first thing I do is change it enough to break identically in the working browsers.

          But then suddenly the fix is easy, obvious and universal.

          • by arth1 (260657)

            Indeed. And that's a lot less work than trying to make exceptions and special conditions for each and every browser..

            It's like "Doctor, my back hurts when I bend forward to put my hands on the ground, and then twiist 90 degrees." And the same reply as the doctor will give you applies here too.

    • To develop a web site "against" or "for" browsers is having lost the battle before you've even started it.

      One way to avoid this is not to write content in HTML directly. Write in LaTeX or DocBook or a similar language that separates content from presentation [wikipedia.org], in order to insulate your content from changing HTML standards. Then have your script publish to the latest HTML standard. When the HTML standard changes, simply update the conversion tool.

      • That would work great if this were 1995 and we were writing static HTML, but every web site since then has been dynamically generated. There's no LaTeX for "check if the username is already taken before submitting the form."
        • by Ichijo (607641)

          That would work great if this were 1995 and we were writing static HTML, but every web site since then has been dynamically generated.

          Even dynamic web sites still use static HTML. I know this because I occasionally see HTML tags mistakenly displayed as text in articles on news sites.

  • 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?
    • You could always put up a "This site is best viewed in ..." button, for that touch of 90s nostalgia.

      • You could always be a bit more discrete, like this [20thingsilearned.com] when viewed in IE. Personally, if it's up to me, I check in IE9, Chrome Dev channel and Firefox (latest) ... I tend to use Chrome dev channel as a rendering bencmark of how it *should* look... firefox rarely needs tweaking, IE9 a few here and there, and older IE, takes more...

        Some general html5 syntax with additional tags, and css5 do a lot of the heavy lifting now, and js is relatively light/fast when done right. I try to make non-admin interfaces at
        • by BZ (40346)

          For what it's worth, IE9 is a better benchmark of "how it should look" than Chrome in many ways. Of the four major rendering engines, WebKit has the buggiest CSS 2.1 support, for example...

    • by starsky51 (959750)
      Take a look at Spoon [spoon.net]. It's a browser plugin that launches applications in their own virtualised environment. Meaning that different versions of the same browser can run alongside each other, without you having to con Windows into it.
    • 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?

      Regarding Chrome specifically, it is very simple. Virtually nobody has an old version of Chrome as it gets updated automatically (and this really works - look at the statistics two weeks after a new version came out). So just test against stable, beta and dev.

      • Fair enough. I originally wrote "firefox 3" and "firefox 4", but figured that though the spread is growing, not everybody may think that 3.5/6 are hiding in there. You are correct, chrome is a silly example. Running it on linux, I wasn't aware of the autoupdate feature on other platforms.
        It's more the leap from ie7 -9 that's starting to get me, along with firefox. And mobile testing, bah.
        • had a problem earlier today with ie7 specifically.. grr... need to get XP users to Chrome or FF... everyone I've introduced to Chrome loves it.. multi-user scenarios in windows is the only pain with it. I would like an adblock that really works like the FF version (blocked before remote requests)... but that's my only real gripe. The auto update is my biggest reason to push now, tired of out-dated browsers at every turn.
    • by bunratty (545641)
      Hardly anyone runs the old version of Chrome [getclicky.com] just a week or two after a new version is released. Why the hell are you testing against many different versions of Chrome? Do you bill by the hour?
  • by Rob Riggs (6418)
    Use HTML4 and Flash. That's good enough for everyone that matters. :-)
    • by tyrione (134248)

      Use HTML4 and Flash. That's good enough for everyone that matters. :-)

      That's rationale. Not! Skip WebGL, shit can Canvas, WebApps, WebSockets, etc., all for Adobe? Pass. Hell, even Adobe is contributing to Poppler which makes it clear to me that even their own stuff [PDF] rendered sucks compared to an outside project. There was a reason Apple wrote Display PDF--they're better at it.

  • IE6 (Score:4, Insightful)

    by nedlohs (1335013) on Tuesday May 31, 2011 @06:00PM (#36302238)

    with flash if you want to be fancy.

    • It pains me that people still mark comments like that as Insightful. Look up Sencha/ExtJS [sencha.com] or another full-featured framework with UI components. Javascript plus CSS and images can do a ton of extremely useful things that we used to need Flash for. I'm not positive about this, but I think the only thing that ExtJS 4 uses any Flash components for is for some really nice charting tools [sencha.com]. That could change with support for canvas, but one of the advantages of ExtJS 4 is that it works in IE6. Granted, like a

  • This is why I got out of any type of web design work, and if a friend asks me to make them a site, I just say no. This is just going to keep happening and happening. Just wait till IE20 & FF20 are out.
  • Wait until 2014. (Score:2, Insightful)

    by Anonymous Coward

    Then HTML5 will be finalized and XP will have its support dropped so no more IE6,7 and 8 to worry about. Until then design for IE7/Firefox 3.6 and if your business still needs IE6 then install another browser, the world isn't going cater to your old browser forever, no matter how persistent your incompetent managers are.

  • by roca (43122) on Tuesday May 31, 2011 @06:16PM (#36302388) Homepage

    This article is confused in so many ways, it's hard to know where to begin.

    One big thing that it misses is that a lot of "HTML5" is actually writing a detailed spec for existing features that were never properly specified (e.g., HTML parsing). And a lot of the work of implementing HTML5 in a browser is to get those details right so they're the same across browsers. That helps Web authors who aren't even using any of the new features.

    The list of HTML5 features has many errors. "contenteditable" is nothing to do with Web Forms and is not new in HTML5; it's been implemented in all browsers for a long time, and HTML5 just provides a (partial) spec for it. Falling back to SVG when canvas isn't available would be a mistake since every browser that supports SVG also supports canvas.

    I don't know how Microsoft's "native" sloganeering got mixed up in there, because it's completely irrelevant, but let's point out that it's completely bogus. It's not even clear what they mean by "native"; the best guess is that it means "abstraction layers are bad so a browser that only runs on Windows 7 must be the best", which is complete nonsense.

    John Foliot is wrong about the need for frozen spec snapshots. We often find errors in supposedly "stable" parts of the spec; if those parts are frozen in some official snapshot, that just means the snapshot is going to be more wrong than the the up-to-date version.

    Web developers should always look at the latest versions of the specs for the features they use. They should decide what features to use by looking at the browser usage of their user community and making their own cost/benefit calculations.

    • by merreborn (853723)

      They should decide what features to use by looking at the browser usage of their user community and making their own cost/benefit calculations.

      I'm involved with a site that's 44% IE6-8. We've even got a vocal (albeit tiny) set of users running IE6 on Windows 2000 or older, which means they don't even have the full set of IE6 service packs (only XP and newer got anything more recent than IE6 SP1).

      It's delightful.

    • Falling back to SVG when canvas isn't available would be a mistake since every browser that supports SVG also supports canvas.

      It also seems like it's missing the point. If what you want to do can be done in SVG, isn't that a better choice anyway than canvas?

      • by roca (43122)

        That is generally true but sometimes you could do it either way and get better performance with canvas.

  • The obvious answer would be to only implement known-good solutions that work across all major browsers-- something that would be easily implemented by making a list.

    Unfortunately, the "web development industry," which ranges from people who couldn't get hired by McDonalds and who are charging less hourly than McDonalds pays, to people charging upwards of $350/hr, is not exactly known for either discipline or standards.

  • by cdrguru (88047) on Tuesday May 31, 2011 @06:30PM (#36302522) Homepage

    The creators and maintainers of HTML and XHTML have said over and over that the language is a description of content and absolutely not in any manner a design for presentation. Presentation was to be left to the browser and the user.

    Well, that lasted all of about five minutes. The first thing that came along was the use of white-space spacing graphics and tables to push things around so they looked consistent across varying screen widths - so that the 800x600 screen looked like the 1024x768 screen. To make the presentation customized as designed by the web developer (and whoever is paying them) and to have a consistent user experience. Not at all what the design of HTML is for.

    So today we have web sites developed with the specific intent of circumventing the design of HTML and XHTML. Amazingly, these design hacks are not something that anyone really tests for in browser development - they are interested in developing something that meets the criteria of the design of HTML, not the intent of the web developer. In a few cases there are actually things that have been adopted into the browser design to make the web developer's life easier. Since these things are clearly non-standard and unique to a particular browser they make the web developer's life hell.

    So where there were maybe 4 or 5 specific platforms to test against before, now there are far more. 15? 20? More?

    The real solution is to have a web presentation language that does define presentation, which is what just about everyone really wants. Except for the maintainers of the HTML standard. Not only is the problem not going to get any better, by definition we have two groups moving in different directions. It is going to get a lot worse and probably at an expotential rate.

    • +1
    • by AlXtreme (223728)

      1999 called, it wants its rant back. Where have you been this last decade?

      Seriously, with CSS (W3C, not coincidently the same maintainers of HTML) we have that web presentation language and it works pretty well across all major browsers. If you want to give your users a 'consistent user experience', CSS will force it upon them.

      Even with differences between CSS versions and DOM implementations we have it much easier than when frames, white 1px images, ActiveX hacks and tables were the way to do "web design".

      • by yuhong (1378501)

        Those 'designed for IE' labels weren't for show

        I know, that was why Web Standards Project was created. What was interesting was that it took the creation of competition from IE for people to finally care enough about web standards to start this project.

    • by yuhong (1378501)

      From what I read, it began with people taking up Mosaic in 1993 or so making HTML popular, but many of these people also designed webpages based on the display in Mosaic. <Hx> was abused to change font size, <DD>, <DL>, <BLOCKQUOTE>, and several other tags was abused for indentation, etc. It certainly didn't help that these tags looked cryptic to people unfamiliar with HTML. Then came Netscape introducing <CENTER>, <FONT>, etc. Netscape gained a monopoly effectively killi

    • by cbhacking (979169)

      Pretty sure the "web presentation language" you're asking for is called CSS. You may have heard of this language? One of those little features that helped IE4-6 win the browser war of the 90s? The preferred way to format and lay out content, and even do neat tricks like show and hide things dynamically, for over 10 years now? The language that allows you to explicitly define presentation in a way that all browsers on all computers are supposed to show identically, and if they don't, allows you to define a f

  • Should be:

    "Rapid web copy-pasta challenges browser developers."

    And the fact that the "standards" are little more than committee wishlists doesn't help much.

  • ... so that we'll never actually get rich.
  • by VortexCortex (1117377) <VortexCortexNO@S ... t-retrograde.com> on Tuesday May 31, 2011 @06:54PM (#36302740) Homepage

    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.

    • 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,

      The difference between native code of an ActiveX control, and native code produced by JavaScript JIT-compilers, is that the latter comes from a language that is verifiably memory-safe - meaning you can actually sandbox it, with said sandbox being foolproof so long as your verifier is not buggy (but this holds for any implementation technique - even an AST interpreter can have bugs exploitable for arbitrary code execution).

    • by arkenian (1560563)
      So basically you're saying that the current situation on the internet amounts to a job security program for web developers. What I"m having difficulty understanding is where the problem is with this? Actually when I put it that way, it explains a lot....
    • by lennier (44736)

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

      Yes, we did. And I'm very sad that we did, because at the core of HTTP's stateless REST architecture is a very neat half-formed idea struggling to get out, which we've been hell-bent on strangling at birth since 1989.

      Facebook and Twitter should be teaching us something about what we're missing. The SGML document/element divide is mostly hugely unhelpful. What we generally want to publish is not huge consolidated 'documents' but the raw data objects themselves. We should have a distributed publishing infrast

  • by SplashMyBandit (1543257) on Tuesday May 31, 2011 @07:41PM (#36303122)

    Google Web Toolkit (GWT) is pretty darn good at sorting out the browser dependencies for you. There are some pre-browser CSS tweaks you have to do for layout, but basically GWT is to the Web what the Java Virtual machine is to hardware - you just don't have to care about it. Plus, you write GWT in Java, which you already know and are using on your back-end Enterprise cluster. Take a look at GWT, if you are writing a significant part of your AJAX web application at the level of HTML5 and ECMAScript then you are doing the Web-equiavalent of writing assembly code (sometimes necessary, but can be avoided most of the time).

    Here's the link to GWT if you haven't seen it before: http://code.google.com/webtoolkit/overview.html [google.com]

    • I haven't posted in a while, but this is wrong on so many levels. Let's start:

      ...basically GWT is to the Web what the Java Virtual machine is to hardware...

      I guess maybe on some strange high level of abstraction this might be metaphorically applicable, but in reality it's completely wrong. I think you meant "GWT is to the browser," but still nope.

      ...you write GWT in Java, which you already know and are using on your back-end Enterprise cluster.

      Wow. What a strangely strong assumption. I think what you said just before this is key, "...you just don't have to care about it." Guess when you have a hammer everything really does look like a nail. Java isn't the only solution available

      • > People who can't program a complex website without the use of their beloved OOP is because they are unable to adapt to the web development workflow.

        Whateverz. You know nothing about what I develop for, yet your four year 'experience' (which to me means you are still crawling in professional career development terms) you clearly think you know it all - and every web problem can be solved by resorting to Javascript. That's simply bollox!

        The reason I suggest GWT is that Java is the most general purpose

  • Try http://browsershots.org/ [browsershots.org] It's not going to help with testing functionality, but it'll definitely help with layout.
  • by sycodon (149926) on Wednesday June 01, 2011 @12:15AM (#36304842)

    ...at least for corporate online sites.

    Too much time is wasted jerking off to the restrictions of the browser model. Code all over the fucking place...javascript here, server code there. Sessions variables that aren't available because...excuuuuse me, I'm in the wrong code block. Is it full Postback or a partial Postback? Do you really need a fucking library of books that constitute an entire zoo? Perl, Python, Ruby, PHP, Java, .NET, C#, C++, C++++, VB.net, F#, FU! Ajax, SOAP, Object not set to an instance of an object...which fucking object God Dammit!

    AAAAHHHHHH!!!!!!

    This wheel has been reinvented so many times the development world is like a huge used tire depot. More often that not, it's on fire.

  • This story is overwrought. I'm a web developer who maintains about 40 apps on our Intranet, and I have always tried to make them work in IE, Firefox, Safari, Opera, and now Chrome. But really it boils down to making them work in both IE and non-IE browsers. First I try to make it work in Firefox, and I find that it then also works without modification in Opera, Safari, and Chrome. That was the easy part. Then I try to make it work in IE, which involves various patches, and hand-wringing.

    I haven't yet develo

  • With browser versions rolling out like donkey-kong barrels, and a pretty good number of very stylized websites to look after, we spend a pretty good amount of time fielding calls about why x website looks different in y and z browser.. the general client doesnt realize that it looked fine in every available major browser 6 months ago, they **expect** it to be the same in all versions **forever**. This is my headache and it doesnt get better with standards..especially "living" ones..
  • The major issue of faster browser version cycle is for sysadmin.
    And this is a good thing.

    Sysadmins and organisation must understand that a web browser is not a software that you can keep at the same version for 5 years (IE6). This software is the door to the external world and must be updated regularly to adapt to the changes in the external world. Organizations and sysadmins must adapt their software deployment process to the product developement cyle. The fact that the media talk about it will hopefully h

Memory fault -- brain fried

Working...