Google Chrome



  • Don't know how many of you have heard of this.  Looks like it's pretty recent news: http://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html



  • thx4thelink ... haven't heard about it ...

    looks like reinventing the wheel, but who knows, they might pull it off ... 



  • Assuming it's not a complete flop, I am looking forward to this.  The web is in dire need of someone to step up to the plate and fix things (not just write white-papers filled with gibberish about "fixing" things and then bitch when the half-assed solutions aren't implemented to spec).

     



  • @NullAndVoid said:

    Assuming it's not a complete flop, I am looking forward to this.  The web is in dire need of someone to step up to the plate and fix things (not just write white-papers filled with gibberish about "fixing" things and then bitch when the half-assed solutions aren't implemented to spec).

    My thoughts exactly.  And thanks Tster for the heads-up, I've not heard of this until now (been a bit Ostrich on current developments recently), looking forward to trying it out.



  •  Its pretty obvious where they are heading. They want the browser to be just as rock-stable and reliable as the operating system that runs it. Because as far as Google is concerned, the browser is the operating system. 



  • @NullAndVoid said:

    Assuming it's not a complete flop, I am looking forward to this.  The web is in dire need of someone to step up to the plate and fix things (not just write white-papers filled with gibberish about "fixing" things and then bitch when the half-assed solutions aren't implemented to spec).
     

    IMO, the browser is only half the battle.  The web is sorely in need of a complete rethinking of the underlying technologies.  HTML/JavaScript/CSS were not designed to deliver "rich" applications - it seems that building anything remotely complicated with them is an exercise of how many hacks can you come up with.  If delivering full-featured applications via the web is what we want, we need to develop technologies designed to do so; not just mash crap together.

    It's just shamefull that HTML doesn't even specify a numeric only input field.  You know how much time we all could save if we had something like <input type="numeric" min="0" max="10" float="no" />.

    In any case, I hope Google's browser provides some innovation and forces the other browser makers to either copy/one-up them.



  • @lpope187 said:

    In any case, I hope Google's browser provides some innovation and forces the other browser makers to either copy/one-up them.
     

    This seems to be the idea, as far as I can tell from the comic.



  • @lpope187 said:

    IMO, the browser is only half the battle.  The web is sorely in need of a complete rethinking of the underlying technologies.  HTML/JavaScript/CSS were not designed to deliver "rich" applications - it seems that building anything remotely complicated with them is an exercise of how many hacks can you come up with.  If delivering full-featured applications via the web is what we want, we need to develop technologies designed to do so; not just mash crap together.
     

    I think XForms is/was an attempt to build a new foundation for web applications, but as it seems, progress is incredibly slow, so I wonder if it will be fully supported by major browsers. Currently, I'd guess that AJAX frameworks have already delivered everything that XForms promises and a lot more.



  • @ammoQ said:

    Currently, I'd guess that AJAX frameworks have already delivered everything that XForms promises and a lot more.

    Flex as well ...



  • @lpope187 said:

    It's just shamefull that HTML doesn't even specify a numeric only input field.  You know how much time we all could save if we had something like <input type="numeric" min="0" max="10" float="no" />.

    What a horrible mess.  You will still have to validate the data on the server-side and instead of using a rich programming language to construct arbitrary business logic you are stuck cramming attributes into your tags.  This sounds like a big WTF.



  • @morbiuswilters said:

    @lpope187 said:

    It's just shamefull that HTML doesn't even specify a numeric only input field.  You know how much time we all could save if we had something like <input type="numeric" min="0" max="10" float="no" />.

    What a horrible mess.  You will still have to validate the data on the server-side and instead of using a rich programming language to construct arbitrary business logic you are stuck cramming attributes into your tags.  This sounds like a big WTF.

     

    But it could allow the user to customize how the browser enforces (or even if it does enforce) the tags.  I think there are a lot of possible additions to HTML that could be added.  And it's not like it's a security thing or anything.  It would just allow for a better user experience.  The "numeric" is kind of like a hint to the browser.  .NET controls have text boxes where you enter in the format of the data that is expected and it makes well written .NET applications very user friendly.  I wouldn't mind web pages being more like that.



  • @morbiuswilters said:

    What a horrible mess.  You will still have to validate the data on the server-side and instead of using a rich programming language to construct arbitrary business logic you are stuck cramming attributes into your tags.  This sounds like a big WTF.
     

    Any specification for how to ask the user for input could be considered "business logic".  A drop-down list of values, for example, is often generated server-side via business logic.  None of these input specifications replace server-side validation, they are just instructions for the web browser on how to prompt the user for the input. 



  • @Jeff S said:

    @morbiuswilters said:

    What a horrible mess.  You will still have to validate the data on the server-side and instead of using a rich programming language to construct arbitrary business logic you are stuck cramming attributes into your tags.  This sounds like a big WTF.
     

    Any specification for how to ask the user for input could be considered "business logic".  A drop-down list of values, for example, is often generated server-side via business logic.  None of these input specifications replace server-side validation, they are just instructions for the web browser on how to prompt the user for the input. 

    And a drop-down is a fairly simple idiom that can be handled quite well in HTML.  Whatever options are acceptable are just there.  Comparing this to the arbitrary logic allowed by a real programming langauge is absurd.  Imagine for a moment if your numeric field was only numeric (or only required) under certain circumstances.  This would have to be represented in the HTML add-ons.  HTML could just ignore these cases, but a lot of developers will opt for Javascript over the new HTML form elements simply because they won't want to scrap the whole thing when the requirements change and HTML is no longer capable of working for them.  So either you end up with a very simple addition to HTML that only works in a few cases, requires a change from existing practices to utilize and a switch back to existing practices if the requirements change enough to justify it and ends up being about as verbose as the JS required to do the same validation OR you end up with a ridiculously complex spec that essentially emulates a programming language in XML just to give developers the functionality they need.  Sounds like a massive WTF to me.  Finally, by using JS to do your own validation you also gain the ability to have errors handled within your GUI instead of having goofy "standard" errors built into the browser such as "Field xyz is required to be a number that is between the values of 1 and 10 and does not have a decimal."  The browser obviously has no way of knowing why the restriction is placed on the field and thus cannot provide useful assistance to the end-user.



  •  I've found hints that <input type="int"> already exists, though firefox, opera and konqueror seem to ignore it...(IE not tested)



  • @morbiuswilters said:

    And a drop-down is a fairly simple idiom that can be handled quite well in HTML.  Whatever options are acceptable are just there.  Comparing this to the arbitrary logic allowed by a real programming langauge is absurd. 

    Luckily, no one here is suggesting adding "arbitrary logic allowed by a real programming langauge" to HTML.



  • @Jeff S said:

    Any specification for how to ask the user for input could be considered "business logic".  A drop-down list of values, for example, is often generated server-side via business logic.  None of these input specifications replace server-side validation, they are just instructions for the web browser on how to prompt the user for the input. 

    Um... nope. That would be the "presentation" layer, which handles how the interface is presented to the user. Business logic means stuff that actually runs the business, like "bill order 666 to customer 101", "create order 493 with items 4,2,1 and 9"; which in a proper MVC environment will run server-side, and will do it properly no matter what its fed from the presentation layer.

    Client-side validation is OK, but it isn't something you can rely on; anyone could just build up a copycat POST form and send unvalidated data like Feb 66, 9999 and such.



  • @danixdefcon5 said:

    Um... nope. That would be the "presentation" layer, which handles how the interface is presented to the user. Business logic
    means stuff that actually runs the business, like "bill order 666 to
    customer 101", "create order 493 with items 4,2,1 and 9"; which in a
    proper MVC environment will run server-side, and will do it properly no
    matter what its fed from the presentation layer.
     

    You quoted and interpreted what I wrote completely out of context. 

    I completely 100% agree with what you wrote. 

     



  • @Jeff S said:

    Luckily, no one here is suggesting adding "arbitrary logic allowed by a real programming langauge" to HTML.

    I wouldn't suggest that because it would probably end up looking like the WTF known as XSL. I can understand why we ought to separate display elements, presentation of the elements, client-side behavior, server-side behavior, server-side data, etc. However, I do not understand why these things must be split amongst five or more different languages. I can see how it got that way (they were all developed independently of each other), but I don't think it should stay that way. Is there a super-language that can handle it all? I have asked this elsewhere and the best answer I got was Lisp, but sadly, I don't think that's gonna fly.



  • @morbiuswilters said:

    @lpope187 said:

    It's just shamefull that HTML doesn't even specify a numeric only input field.  You know how much time we all could save if we had something like <input type="numeric" min="0" max="10" float="no" />.

    What a horrible mess.  You will still have to validate the data on the server-side and instead of using a rich programming language to construct arbitrary business logic you are stuck cramming attributes into your tags.  This sounds like a big WTF.

     

    I was thinking more along the lines of providing a better way to provide limited client-side restrictions along the lines of "don't even allow anything but numeric characters to be entered".  Honestly, I try to put just basic validation on the client side (make sure it is a date, number, etc), and put the same basic rules as well as the complex business rules on the back-end.  Just like any other system, validation still needs to be done at the back-end and/or middle tiers. 



  • @NullAndVoid said:

    Is there a super-language that can handle it all? I have asked this elsewhere and the best answer I got was Lisp, but sadly, I don't think that's gonna fly.
    There is already one language that handles it all, and has done it since at least 1999.

    Java.

    Check out the J2EE 1.4 specs, for example: you put all the business logic on an application server on the server-side; then you build, say, a Swing client that connects (and authenticates) to the AppServer. You get a nice client-side GUI doing the presentation stuff, and all the BL on the server-side using EJB's.

    Too bad the AJAX craze came along; now everything seems to be centered around Web 2.0, ripping off the Aqua look-and-feel, and making the browser do things it was not designed for. So now J2EE (and the next EE's) are mostly being used in web-only apps, using things like Hibernate and Spring so the client/server implementation I mentioned earlier becomes impossible to implement if the app was made using these tools.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.