Forgot your password?
typodupeerror
Programming

Web Browser Programming Blurring the Lines of MVC 303

Posted by kdawson
from the extremely-thick-client dept.
lkcl tips his in-depth article up at Advogato on the difficulties for the MVC programming model that are introduced by Javascript and AJAX, and solutions for them. He writes: "This article outlines how the MVC concept is made incredibly awkward by the gradual but necessary introduction of Javascript and AJAX. A solution is found in the form of Javascript Compiler Technology such as GWT or Pyjamas (PyPy's JS backend or Rb2Js could be used, with some additional work). The article outlines how and why the traditional MVC patterns are fragmented by Javascript and AJAX, advocating that if a site is programmed purely in a high-level language that is then compiled to Javascript for the Web Browser sections, the same high-level source code can be executed either client-side on the browser, or server-side, or even both, depending on the requirements. The implications of this approach are discussed in depth."
This discussion has been archived. No new comments can be posted.

Web Browser Programming Blurring the Lines of MVC

Comments Filter:
  • RubyJS (Score:4, Informative)

    by lkcl (517947) <lkcl@lkcl.net> on Friday November 28, 2008 @01:39PM (#25917131) Homepage

    also found, since the submission, rubyjs [rubyforge.org] which is a ruby-to-javascript compiler and yet another port of GWT - this one's called rwt [rubyforge.org]

  • More Importantly (Score:5, Interesting)

    by Alt_Cognito (462081) on Friday November 28, 2008 @01:40PM (#25917139)

    The lines between what is an application are blurring. We have disparate data sources which are being combined in ways which the original sources never necessarily intended. The user application may or may not even be one written by the service provider.

    The semantic web, despite all the nay saying, is here.

    • by MightyMartian (840721) on Friday November 28, 2008 @01:44PM (#25917163) Journal

      The semantic web, despite all the nay saying, is here.

      And it's a fucking mess.

      You know, distributed computing is hardly a new thing, so why is it when the dream of all those researchers a generation ago comes to life, it's in a chaotic, difficult and barely-framework framework like AJAX? It's rather like someone a couple of hundred years ago dreaming of the automobile, but when it's finally developed, it's got two front wheels, two horses legs and the driver faces the wrong way.

      • Re: (Score:3, Insightful)

        by zappepcs (820751)

        I agree. If the semantic web were a parachute, we'd have a lot of dead base jumpers. Some of the idea behind a semantic web are good, but terribly difficult to implement. It's truly a tower of Babylon problem. If (big if) everyone ever agrees to how to handle/interface to web resources, we still all have to learn how to describe things. I call it 'you suck at Gimp' but you call it tutorial, and yet someone else calls it 'fun with Linux apps' and that is just for something easy. It gets worse depending on th

      • I just thought I'd point out that the problems that you are ascribing to JavaScript + HTML could be leveled at the English language. And yet you are comfortable posting with it. Let's face it, as long as things work and have well-defined interfaces, complaining about aesthetics is not productive. Beautiful cathedrals are just that: beautiful. But also cold and uncomfortable.

        We're a messy species of semi-evolved apes.

        HBH
        • by Sloppy (14984)

          I just thought I'd point out that the problems that you are ascribing to JavaScript + HTML could be leveled at the English language.

          We all know spoken languages are evolved, but we still have the illusion that software is designed.

          • An excellent point. I'm not a linguist, but I believe these issues to be related. It is my opinion that the expressiveness of the medium (software, language) determines its success or failure. Design and robustness are key for data management but for user interaction, it is the most flexible solution that wins out. English is an unholy mix of different, completely separate languages and thousands of idioms, and growing every year. It grew from a simple street language to the third most spoken language in th
            • I'm not a linguist

              Indeed, or you'd be able to spell "hamster" or "hamper", whichever it's supposed to be.

        • English's problems are largely a really nasty spelling system. For the most part, adopted words have pretty much been syntactically modified, and because English is all but non-inflected since the rise of Early Modern English, it's not too bad.

          Or, to put it another way, your analogy sucks save on one specific point.

    • Security issues. (Score:5, Informative)

      by TheLink (130905) on Friday November 28, 2008 @01:57PM (#25917251) Journal
      "the same high-level source code can be executed either client-side on the browser, or server-side, or even both, depending on the requirements"

      Careful when you blur the lines.

      The gains might not be as much, because there's a very big difference between running your code on an untrusted client vs running your code on your server.

      It may be rather hard to enforce the integrity and security checks at server side when you start to do more and more stuff on the client.

      If the server has to counter check each step, then you still get that round trip latency effect. If you do most of the stuff client side that could mean the server has to figure out what are valid _end_ states from tons of possible intermediate states. Sometimes that might not be possible.

      It's not a problem for things like google maps, if you modify their client side javascript to behave differently it's not a big issue.
      • by Timothy Brownawell (627747) <tbrownaw@prjek.net> on Friday November 28, 2008 @02:16PM (#25917357) Homepage Journal

        If you do most of the stuff client side that could mean the server has to figure out what are valid _end_ states from tons of possible intermediate states. Sometimes that might not be possible.

        Why? I'd think the server would just need to know "is this client permitted to view/modify that data", which really has nothing to do with any intermediate states. All it has to care about is who the client has authenticated as, and what the (entirely server-side) permission database says.

    • You talk about application from different vendors working together as if it is some kind of new trend in computing that has never been seen before, which could not be further from the truth. Text-mode Unix programs could usually be strung together using scripts and pipes, and it was common and routine to do so. Some even wrote scripts that ran processes on multiple systems.

      The only thing that one needs to get this sort of behavior is a common interface. In the Unix command line, stdin/stdout was a com
    • Bless you for not saying "mashup".
  • The internet, being a series of tubes, naturally adapts itself to the PVC [clearpvcpipe.com], rather than MVC, model.

  • by girlintraining (1395911) on Friday November 28, 2008 @01:52PM (#25917211)

    Call me jaded, old, and behind the times... But what ever happened to a web browser just being a web browser instead of a development platform with three heads breathing fire, half a dozen plugins, six months of combatability testing, and a kitchen sink? Is there ever a point where a web developer will concede that the web is not the Best Platform for Everything in The Universe(tm)? Or is it just that they were never schooled in the old temple and given a proper appreciation of a real language like C++? Help me out here -- this isn't intended as a flame but an honest question -- where does this attitude that everything has to be crowbar'd into a web interface to be considered modern these days? Because a lot of the problems in this article come down to programmers expanding and bloating their platform/language of choice to do something it was never designed for because That's Just What I Know(tm). :( I cry for these languages. I know after 5pm they go home and hit the frozen dairy products hard to feel better about how fat they've become.

    • by eldavojohn (898314) * <eldavojohn&gmail,com> on Friday November 28, 2008 @02:05PM (#25917291) Journal

      ... schooled in the old temple and given a proper appreciation of a real language like C++?

      You're going to have to inform us "young'uns" of what is and isn't a "real language." You see, I can't even begin to help you until you concede that if a tool gets the job done, it's a good tool. It might not be the best tool but it's a good tool. Stop making inflammatory statements.

      What you misunderstand about this change of direction is that microarchitectures and new hybrids of old design patterns are arising to meet the needs of web developers.

      where does this attitude that everything has to be crowbar'd into a web interface to be considered modern these days?

      If you write a C++ program and compile it down to one architecture, how many users do you have? If you write a browser, OS, architecture neutral application and make it available to everyone online, your user base skyrockets dramatically.

      I cry for these languages.

      And these languages cry for you and your closed mindedness towards new ideas. Java was a bad idea at first and yet somehow it has found a niche--more than a niche if you ask me.

      I'll meet you half way, I agree C++ is far faster than anything I've been paid to code in. Now you come the other half of the way and maybe we'll have a discussion here where useful information is exchanged.

      • by mweather (1089505)

        You see, I can't even begin to help you until you concede that if a tool gets the job done, it's a good tool.

        I can hammer a nail in with my fist. But I wouldn't call my fist a good tool for hammering nails. It works, but it's not pleasant.

        • You see, I can't even begin to help you until you concede that if a tool gets the job done, it's a good tool.

          I can hammer a nail in with my fist. But I wouldn't call my fist a good tool for hammering nails. It works, but it's not pleasant.

          Come on, man, that's a bit extreme. It's not like any of us are suggesting we should use Microsoft Visual Basic here ...

          • Come on, man, that's a bit extreme. It's not like any of us are suggesting we should use Microsoft Visual Basic here ...

            And yet Visual Basic "gets the job done"...

            I've worked with lots of languages, and they almost all get the job done. What I find amusing is that virtually everyone has languages they feel defensive about "come on! open your mind!" and others they feel superior to "at least we aren't using X". You really can plug just about any set of languages or technologies into the equation and find someone who will argue the point.

          • >>>You see, I can't even begin to help you until you concede that if a tool gets the job done, it's a good tool.

            >>I can hammer a nail in with my fist. But I wouldn't call my fist a good tool for hammering nails. It works, but it's not pleasant.

            >Come on, man, that's a bit extreme. It's not like any of us are suggesting we should use Microsoft Visual Basic here ...

            MS basic was actually very successful at what it was designed for, doing very quick GUI development on windows.

            The browser on the

          • These days, there's absolutely nothing wrong with modern editions of Visual Basic. It's essentially C# with different syntax.

            • by EvilRyry (1025309)

              That's VB.NET, sharing almost nothing but a syntax similarity with previous versions of VB.

        • by gstoddart (321705)

          I can hammer a nail in with my fist.

          I'd like to see that, because I'm betting you couldn't and still have a hand you could make any further use of.

          Cheers

      • And these languages cry for you and your closed mindedness towards new ideas.

        Distributed computing is not a new idea. It's been around for at least thirty years. AJAX, Web 2.0 or whatever you want to call it, is simply an extremely bad execution of the concept. Trying to defend as "the hip new idea that old-timers just can't accept" is idiotic. It's not a hip new idea, it's just a crappy implementation on a platform that, even before it, was hardly a paramount of efficiency and ease.

        • Re: (Score:3, Insightful)

          by peragrin (659227)

          So design a better version? yes ajax sucks, but it works with what is already existing out there allowing a simple pgrade of features for everyone.

          Silverlight, flash, .NET, even Java all require downloads and installs of some other piece of technology. ajax takes existing tech and does something similar. It isn't pretty but it has been effective.

          Windows should have shown you by now, that ugly but effective still makes millions.

          • First of all, when did web browser stop requiring downloads and installations? Just because it is built into some -- SOME -- operating systems, does not mean that it is ubiquitous or that it is a good idea to develop software for it. Fedora 9 and 10 demonstrate that it is equally easy for an OS vendor to ship Flash and Java support with their OS, and Windows demonstrates that .NET support can also be built in. There is no reason to think that silverlight is any different. All of these are better platfor
          • It's not a matter of designing a better version. The platform is simply not up to the task. AJAX is like trying to shove a giraffe into a closet; yes, with sufficient application of force, you can do it, but the end result is going to be ugly.

            AJAX isn't a solution to a problem, it's an ugly hack to make what is really simply a non-transactional hypertext navigation system pretend like it's a full-blown UI. I can't imagine any serious developer ten years ago looking at HTML/CSS/DHTML with AJAX as a client

      • Re: (Score:3, Insightful)

        by Lazy Jones (8403)

        I'll meet you half way, I agree C++ is far faster than anything I've been paid to code in. Now you come the other half of the way and maybe we'll have a discussion here where useful information is exchanged.

        It won't be long till some of you "young'uns" writes a C++ to bytecode compiler together with a corresponding browser plugin/VM... The problem isn't the language, it's the fact that a browser is a terrible *OS* for anything else than small, short-lived "applications" and I really hope it doesn't go half way to being a decent one.

        As for the "browsers are so architecture neutral", it's not true and you know it. Nowdays it's easier to compile and run good C++ code on a large number of platforms than it is t

      • >>... schooled in the old temple and given a proper
        >>appreciation of a real language like C++?

        >You're going to have to inform us "young'uns" of
        >what is and isn't a "real language." You see, I
        >can't even begin to help you until you concede
        >that if a tool gets the job done, it's a good
        >tool. It might not be the best tool but it's a
        >good tool. Stop making inflammatory statements.

        The original poster was not insulting ruby, or whatever language you use for server side processing. He

      • You don't need to build things within a "neutral" environment like a web browser. Numerous programs that have to be installed have taken off on the web. ICQ, MSN, Email, etc.

        If you make something compelling people will get it and while my line of work is web development I must say so much time is waste making sure you support worthless browsers or so people who don't have whatever plugin can see something.

        There is some sort of mentality that if you bad ass site rocks in IE5 that you're more manly than
      • Re: (Score:2, Interesting)

        You see, I can't even begin to help you until you concede that if a tool gets the job done, it's a good tool.

        So you don't mind if I use a butter knife instead of a screwdriver? That's a relief. I haven't found a man yet who doesn't cringe at the prospect.

        What you misunderstand about this change of direction is that microarchitectures and new hybrids of old design patterns are arising to meet the needs of web developers.

        Perhaps in the same way that poor solutions arise to placate poor decisions. Some people have advocated mass-execution of cows to help halt global warming.

        If you write a C++ program and compile it down to one architecture, how many users do you have?

        About the same as the number of people who find that application useful.

        If you write a browser, OS, architecture neutral application and make it available to everyone online, your user base skyrockets dramatically.

        Okay, you can go play Kings of Chaos, while I go play World of Warcraft, since World of Warcraft has fewer players and I like the "small to

    • by abigor (540274) on Friday November 28, 2008 @02:08PM (#25917305)

      It's a common misconception that people are trying to shoehorn everything into browsers. They're not. But it makes sense for certain apps to be centralised, particularly in a corporate/enterprise environment. It's funny, because the successful web apps that are out there (salesforce.com, Taleo, Gmail, etc. etc.) never get picked on - they are just a fact of life now. But when people experiment with new stuff or try to move other apps into a distributed environment, the critics come out of the woodwork.

      Also, as a longtime C++ programmer, I can say that C++ is no more a "real" language than Python or Ruby - talk about a juvenile understanding of software development. People use what gets the job done quickly and hopefully with fewer bugs, and when the dust settles certain languages and technologies are shown to work, and others not. But you never know unless you try.

      • by vux984 (928602) on Friday November 28, 2008 @02:33PM (#25917491)

        Also, as a longtime C++ programmer, I can say that C++ is no more a "real" language than Python or Ruby

        But Javascript or ECMAScript isn't a 'real' language, or at least not in practice, and that's the issue. Code written in it needs to run on multiple different implementations with no properly accepted standards. Contrast that to C, which yeah, has a number of various flavors, but it only matters that you have a compiler that understands that dialect. The stuff you distribute to users isn't going to explode because of your choice of C.

        When you write in javascript, you are passing it to end users to interpret with interpreters that you have little control over, interpreters that exist in mutiple versions, have poorly documented quirks, and deviate from the standards wildly in places, with competing implementations and standards. And your code is supposed to run reliably on all of them.

        Then add HTML / CSS / XHTML / etc which suffer from the same problems as javascript ... they too have no suitable standards (sure standards exist, but that's more an intellectual point than a useful one). People generate invalid statements left and right, and browsers are supposed to guess how to do things. None of them implement the standards, and all of them have quirks.

        People use what gets the job done quickly and hopefully with fewer bugs

        Nothing has more bugs than stuff written in the 'web languages'. The current slashdot home page has 91 SGML parser errors and 1 warning, 225 HTMLTidy warnings, and 40 errors via the W3C markup validation service.

        and when the dust settles certain languages and technologies are shown to work, and others not. But you never know unless you try.

        For what values of 'shown to work' are we interested in? Quality standards and expectations are unbelievably low.

        • Code written in [ECMAScript over the HTML and CSS DOM] needs to run on multiple different implementations with no properly accepted standards. Contrast that to C, which yeah, has a number of various flavors, but it only matters that you have a compiler that understands that dialect.

          You need 1. the compiler, 2. the libraries, and 3. the loader. Even if you have a compiler for the architecture, that doesn't mean you have the libraries. Windows home editions doesn't come with POSIX and X11 libraries, nor does GNU/Linux come with Win32 libraries unless you install Winelib [winehq.org]. Missing libraries are to C as missing DOM elements are to JavaScript. And even with a compiler and libraries, it may still be impossible to run your program because a lot of platforms' executable loaders throw an except

        • IMO, if the interests of document markup and thin-client application mark-up had been decoupled early on, we wouldn't have this mess.
        • by abigor (540274)

          I was addressing the original poster's assertions about Python, Ruby, and Perl in particular, not Javascript. Sorry for any confusion.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          But Javascript or ECMAScript isn't a 'real' language, or at least not in practice, and that's the issue. Code written in it needs to run on multiple different implementations with no properly accepted standards.

          You're confusing DOM implementations with Javascript. Javascript is a language with a well-defined standard, and no implementation deviates significantly.

          Browser DOM implementations vary wildly and cause the problem that you're talking about.

          I used to think that Javascript was a crap language, for mostly the reasons you outlined. Then I actually looked into the language and found that, despite a few shortcomings, it's a perfectly find functional language. People misuse it due to its similar syntax to Jav

        • Re: (Score:3, Insightful)

          by ultranova (717540)

          But Javascript or ECMAScript isn't a 'real' language, or at least not in practice, and that's the issue. Code written in it needs to run on multiple different implementations with no properly accepted standards. Contrast that to C, which yeah, has a number of various flavors, but it only matters that you have a compiler that understands that dialect. The stuff you distribute to users isn't going to explode because of your choice of C.

          Out of curiosity, what dialect of C is both supported in many platforms a

      • by Lazy Jones (8403)

        It's a common misconception that people are trying to sAlso, as a longtime C++ programmer, I can say that C++ is no more a "real" language than Python or Ruby - talk about a juvenile understanding of software development. People use what gets the job done quickly and hopefully with fewer bugs, and when the dust settles certain languages and technologies are shown to work, and others not. But you never know unless you try.

        If you are a longtime C++ programmer, you should also know that C++ and other statically typed / compiled languages are much easier to debug - not only are there more and better tools (e.g. source-level down to machine code debuggers) available, the compiler warnings and errors are *much* more informative compared to all common interpreted languages. This saves you a lot of time and headaches on the long run and is probably a result of the many more man-years of professional development done in these langua

        • by abigor (540274)

          If you are a longtime C++ programmer, you should also know that C++ and other statically typed / compiled languages are much easier to debug - not only are there more and better tools (e.g. source-level down to machine code debuggers) available, the compiler warnings and errors are *much* more informative compared to all common interpreted languages. This saves you a lot of time and headaches on the long run and is probably a result of the many more man-years of professional development done in these languages (compared to less than 10 years of mostly small/hobbyist work in all the "web languages" - yes, with exceptions) and of course also due to the fact that statically typed and compiled languages are easier to analyze than dynamically typed and interpreted ones.

          Really? I use a debugger on Python code, and it feels a lot like gdb.

          As for the errors being much more informative, I'd have to say that's pretty implementation-dependent.

          Right now, I don't actually work day to day in C++ - instead, I'm working in C and some Java. Neither makes it easier to write bug-free code than Python, in my opinion, although I must say I do appreciate Maven and the way it practically forces you to unit test ;)

          In fact, I see few advantages to static typing. The constant across all langu

    • by lkcl (517947)

      I cover this question in the article. partly it's to do with user expectations; partly it's to do with useability.

      the "traditional" web application, on error-form-checking, has to _regenerate_ the entire page, inserting error messages.

      the response time of such applications conflicts badly with users' expectations.

      if some javascript can do the job - immediately - of checking the password against some basic criteria, for example, why make the user wait several seconds until the server works it out?

      • The JavaScript solution is a way to get around the fact the internet tubes aren't big enough. I'd argue that a server handling the job of server the page again isn't any worse than having to deal with dozens of Ajax requests and depending on the browser the Ajax implementation may ruin performance on the client side. Especially on older machines which is sort of ironic since the whole point of doing things in the browser is supposed to make things more neutral and open to all.
    • by Draek (916851)

      But what ever happened to a web browser just being a web browser instead of a development platform with three heads breathing fire, half a dozen plugins, six months of combatability testing, and a kitchen sink?

      Died after Netscape came along. Then IE and ActiveX not only put the final nail in the coffin, it fucked the corpse before doing so.

      Is there ever a point where a web developer will concede that the web is not the Best Platform for Everything in The Universe(tm)?

      Is there ever a point where a C developer will concede that C is not the Best Language for Everything In The Universe(tm)? no, because he has a monetary interest in perpetuating that perception. People who aren't solely web developers, however, would and do concede that, you just haven't looked hard enough.

      Or is it just that they were never schooled in the old temple and given a proper appreciation of a real language like C++?

      I'm sorry, did you mean C? or did you declare yourself incompetent in the ways of programming by calling the turd commonly known as C++ a real language? :D kidding but only partially, what's a "real" language varies from programmer to programmer and you shouldn't assume your opinion is the only valid one. Plus, languages have little to do with the platform, plenty of non-web apps written in Perl, and plenty of web apps written in Java too.

      where does this attitude that everything has to be crowbar'd into a web interface to be considered modern these days?

      Because it's easier to sell it to PHBs. How many trends in programming during the last twenty years have made logical sense everywhere they've been applied to? it wouldn't surprise me to hear about a company that demands a MVC architecture on servers' shell scripts, just as it doesn't surprise me to hear about people trying to cram an office suite into a web browser.

    • by mangu (126918)

      is it just that they were never schooled in the old temple and given a proper appreciation of a real language like C++?

      I programmed in C and C++ for about twenty years, then I learned Python. I found that my productivity as a programmer drastically increased. Now I program in C only the basic number-crunching routines that I cannot find in any existing library. I use Python for all the rest, and write code at a much higher rate than I can do in C or C++.

      where does this attitude that everything has to be cro

    • by sycodon (149926)

      Just to add to this:

      I'm new to the whole object oriented programming methodologies (.net) and they have a lot of cool things going for them. But I find that most times, they are poorly documented and generally a mess.

      Take a generic web page that returns a row from a database. To do what should be common things like examine and modify values given conditions, highlight or otherwise format a particular row and/or column, perform server side logic that uses data from other tables in the database etc, requires

    • Is there ever a point where a web developer will concede that the web is not the Best Platform for Everything in The Universe(tm)? Or is it just that they were never schooled in the old temple and given a proper appreciation of a real language like C++?

      There are a lot of computers that are capable of running arbitrary HTML, CSS, JavaScript, and sometimes even ActionScript, yet incapable of running arbitrary C++ without the developer spending beaucoup bucks to obtain the platform owner's certification. These include the Internet terminal in the break room at work, the Internet terminal at the public library, an unmodded game console, an unmodded smartphone, etc.

    • by Abcd1234 (188840)

      Or is it just that they were never schooled in the old temple and given a proper appreciation of a real language like C++?

      No offense, buddy, but anyone who looks to C++ as a general model for a "real" programming language needs to be taken out back and shot. C++ is a horrible confluence of hacks designed to address it's very specific design goals (a fast, system-level, strongly-typed, object-oriented programming language that gives the developer supreme control over what features are used), and I don't kn

      • But there are *many* programming languages out there *far* superior in their own domains, and Javascript is absolutely among them.

        I was going to completely agree with you until you said this. Javascript is not a good language. Yes part of the problem is how browsers handle it. But if the language is going to allow people to shit all over it then it's just as much at fault.

        • by Abcd1234 (188840)

          And why, exactly, isn't javascript a good language? I mean, it has it's warts that need mending, specifically namespaces and an import mechanism of some kind. Certainly, some people object to it being prototype-based, or that it's weakly typed, but those are just a matter of taste. But aside from those things, what's wrong with JS?

    • by ccguy (1116865) *

      Is there ever a point where a web developer will concede that the web is not the Best Platform for Everything in The Universe(tm)? Or is it just that they were never schooled in the old temple and given a proper appreciation of a real language like C++?

      Well, you see, web developers are probably developing webs which I'd say the web is the Best Platform for.

      As for the C++ remark and its real language status, I can't wait for your gmail or meebo implementation without using any of a fake language.

    • by gstoddart (321705)

      Call me jaded, old, and behind the times... But what ever happened to a web browser just being a web browser instead of a development platform with three heads breathing fire, half a dozen plugins, six months of combatability testing, and a kitchen sink?

      Because, it became the interface that everyone did everything in, and you could (try to) write code which ran on the client without specifically installing stuff. In theory, it became the utility knife that people kept plugging into. (In practice, I agree

    • by sjames (1099)

      There are several problems as I see it IM(NS)HO.

      A lot of the problems are avoided if we treat the web browser as just a display technology much like X. The client side scripting confines itself to display functions, accepting user input and notifying the server. The problem that remains is that it isn't THE web browswer, it's a Babel of browsers each with it's own nasty quirks, bolt-on abominations and steaming pile of marketing claims. Defeat is regularly snatched from the jaws of victory. Somehow, in all

    • The HTML browser helped inspire thinking towards an open, standards-based thin client application architecture.

      It was a useful tool to research some ideas and prove some concepts, but it should have ended there.

      The past decade and a half should have been focused on an analogous thin-client application mark-up language and associated technologies as opposed to the duct tape and twine that we have today.

    • You're jaded, old and behind the times! (rimshot please)

      Part of this is the result of a cyclically recurring dream of companies like Sun and IBM to move processing off the desktop and onto a server - because they sell servers. This push comes and goes every maybe 10 years. This time around it has hit some fertile ground because some people in web technology had finally figured out you can be doing something useful while the user is looking at the screen. ;)

      Add to that the seeming fact that people have alwa

  • Do the new technologies really do this? Or does it just make it more difficult to see the "obvious" MVC patterns?

    In the Old Days, you could see pretty easily what an MVC Web app might look like: There was a piece of code that generated static HTML pages that displayed data, and this was the View. There was another piece that caught input from the browser and used it to do things, and that was the Controller. And then, perhaps, the Model was represented by the database.

    But did any application really ever hav

    • by mini me (132455)

      It's a pretty common to see apps that use the database like it's a big storage closet, ignore stored procedures completely, and implement all data manipulation functions in Java. Is that a smart idea?

      Yes. Especially now that we are starting to move away from the traditional RDBMS.

      • by tyrione (134248)

        WebObjects used Enterprise Object Frameworks to abstract what stored procedures do some of now [people wanted to squeeze every aspect of speed out inside the RDBMS and argued that value of object design wasn't as important] and it seems stuff is beginning to come full circle.

        Too bad Apple hasn't brought WebObjects back to Cocoa and ObjC where it truly was a leader.

    • There was a piece of code that generated static HTML pages that displayed data, and this was the View. There was another piece that caught input from the browser and used it to do things, and that was the Controller. And then, perhaps, the Model was represented by the database.

      That's still not as clear as one might like.

      In particular: Where do URLs fit into that pattern? Rails Routes are neither models, views, nor controllers, from the framework's point of view. Other frameworks draw the lines differently -- Ramaze puts routes inside the controller.

      I've always thought that MVC was a bit too sloppy. I get what the Model is supposed to be, but the controllers and views are always blurring. For example: If I have a bit of repeated code -- find the username, say, or sanitize this chu

  • by shutdown -p now (807394) on Friday November 28, 2008 @02:22PM (#25917393) Journal

    After quickly skimming the article, it seems that the "problem" isn't so much with MVC itself as it is with people not understanding what it is. Apparently, a lot of web developers have thought that "model/controller = server-side, view = client-side". This is obviously wrong, and, of couse, JS and AJAX become extremely confusing to categorize in such a system. No surprise there. Also, article makes a big deal out of the "problem" that JavaScript can be used to work around the requirement that "server generates the view" - but of course, it was never a requirement of MVC, either, and indeed, the original MVC did not imply any sort of "generation" of the views.

    Of course, the something-to-JS compilers that are so popular these days won't help, either. JS-the-language is good enough, replacing it with Java (or Python, or Ruby) on the client doesn't really help much, so long as the dividing line between the client and the server remains.

  • It can almost never happen that a project could ever adhere 100% to idealistic notions such as MVC, which in a nutshell is the separation or containment of business logic from the user interface. The communication can almost never been isolated into a one-way path of communication for any given type of communications. So the fact that the server doing the business logic might also need to change the javascript code on the client side in order to refine or adjust behavior is simply to be expected.

    These sor

    • by erroneus (253617)

      ...sorry to reply to my own post but re-reading what I wrote made me think of one other point I wanted to make:

      There comes a point for everyone at which the work we do trying to be lazy is greater than the work that would have been done being "not lazy" or otherwise not doing what *should* be done. I would assert that Microsoft has gone beyond this point with the Windows API.

    • by ljw1004 (764174)

      I hate all the talk of "your write code which can run on the server, or the client, it doesn't matter".

      We should be striving to make apps where the server-side code is clearly delineated, tiny, and carefully audited. The client can communicate it through AJAX. The client-side code doesn't have to be audited anywhere near as carefully. The only guarantee you can make is that if you have https, and no google analytics or ads, then your page guarantees not to broadcast sensitive data to places it could be inte

  • any freshman computer science major can recognize this problem. its just that no one amongst us has the power to do anything about it. its the network effect, we are already entrenched in a bad model no one has the power to extricate us from. or, more accurately, we are entrenched in a perfectly good model, circa 1993

    how we move away from messy ajax, which is nothing more than stretching the limits of a world of static html pages to the furthest extreme, is again something any computer science freshman can

  • Aptana Jaxer [aptana.com] goes the opposite way: use Javascript to do everything, both on client side and server side.
  • Cross-compiling Java into Javascript seems undesirable. You'll get bloated Javascript as Java constructs are decomposed into Javascript primitives. Then you get to debug the emitted code, which is not going to be fun. Writing Javascript is a pain, but there are libraries. Look for libraries that aren't too big, can't be changed remotely by some vendor, and don't try to be "frameworks".

    Most browsers can run Java applets, after all. If you really want to use Java on the client, you can use Java on the

  • AJAX programming simply reverts to two-decade-old client-server paradigm: high-level client side language operating on "views" sent by server-side "controller". Okay in the early 90s it was VB on the client and Oracle DB on the server, now it is Javascript on the client and Web Service on the server. It is conceptually the same thing. Why we need to complicate the picture with issue of compiling Javascript from even higher level language - I got no clue. I hate to sound old dude but we, programmers, as a wh
  • Because they arent set up to enforce OOP concepts. There are exceptions like Python, Javafx, etc. They end up with BASIC-like spaghetti then.
    • most scripting languages discourage abstraction because they aren't set up to enforce OOP concepts.

      Wait, what? It's not possible to encourage something without enforcing it?

      Javascript doesn't force anything, and yes, you can create BASIC-like spaghetti. But a bad programmer can create BASIC-like spaghetti in any language. A good programmer will take the time to learn Javascript's prototypal model.

  • I have yet to see a client side solution that worked well. There is just too much to consider to ever do it right. There was even an application I ran one time that did not like the version of the java engine installed on my machine, but another application that wanted a different version so neither application would work without re-installation every time.
  • Something completely ignored by this author is accessibility.

    There is no current solution for AJAX and people with disabilities. Creating this ideal client side view is completely shutting out anyone using a screen reader. Ideally, your view is built in such a way that it is easily rendered in both the server and client.

    Template Toolkit with Jemplate is an example of a solution to this issue. Using server side detection you can see if your client needs a server rendered view and if not, your templates are r

  • I have been watching the web grow for years now. I have seen the pain and delight of several models for transacting things on the web, everything from movies to to down and dirty data entry.

    The problem is that I have yet to see an implementation through a browser that can challenge a native GUI implementation and yes this includes Sales Force, Google Mail, Google Docs and all the rest of them.

    The hugest problem is latency. Even sitting on a T1 they are still clunky and due to browser limitations and incom

    • Re: (Score:3, Informative)

      by lkcl (517947)

      The problem is that I have yet to see an implementation through a browser that can challenge a native GUI implementation and yes this includes Sales Force, Google Mail, Google Docs and all the rest of them.

      that's why i ported pyjamas to the desktop:

      http://pyjs.org/ [pyjs.org]

      pyjamas-desktop basically rips out all of the javascript, and replaces every single javascript-based function with exact same corresponding functionality that manipulates the DOM model of the underlying technology.

      and i chose http://webkit.org/ [webkit.org] as the DOM-manipulating technology.

      i _could_ have chosen XUL / Gecko, but it took so damn long to find Hulahop - http://wiki.laptop.org/go/HulaHop [laptop.org] - that i had to go for webkit.

      i could have cho

    • by lkcl (517947)

      Would it not be simpler to just do this?


      ImgBox = Box.New([styleReference]);

      this is _exactly_ what GWT, Pyjamas and RubyJS/rwt allow you to do.

      actually it would, in pyjamas, be:

      from pyjamas.ui import Image

      i = Image("./icon.png")
      i.setStyleName("name-of-icon-css-style")

    • The hugest problem is latency.

      Surely you jest. I use Gmail every day, and it's lightning fast on pretty much any connection. About as fast as I could ask for with the keyboard shortcuts.

      they all suffer from the most bizarre and twisted coding problems I have ever seen.

      Be specific.

      CSS is STILL fundamentally broken and behaves erratically as evidenced by the box model, which you cannot to behave correctly browser to browser platform to platform.

      Are you going to tell me that a native app has it any easier with cross-platform compatibility?

      If you're going to talk about a library, that's fine -- consider that there are plenty of libraries out there for javascript-as-a-client which make the CSS issue mostly go away.

      DOM still has really niggling and dumb problems after all these years as well.

      Like what? Any which aren't already abstracted away by things like jQuer

  • Not even MVC (Score:4, Interesting)

    by GrouchoMarx (153170) on Friday November 28, 2008 @04:11PM (#25918213) Homepage

    I have long argued [garfieldtech.com] that MVC doesn't even make sense on the web to begin with. MVC is a great architectural model for live interactive systems, but a web site or web app is not a live interactive system. It's an asynchronous challenge/response system.

    I blame Sun for completely abusing the term in their Java stacks (I think they called it "model 2"?), and Ruby on Rails for popularizing the wrong impression. MVC by definition requires a direct observer connection from View to Model. All web-MVC frameworks I've seen start with the initial statement that the Controller, not the View, is responsible for handling user interaction and communicating with the Model. Sorry, that's not MVC. It's not a bad model for the web, but it's not MVC. If anything it's closer to PAC.

    See the link above for a lengthier analysis and links to Wikipedia. :-)

    Really, the whole point of design patterns is to have a common vocabulary. How is that useful if you're going to bastardize your terminology due to stubborn ignorance?

    • Re:Not even MVC (Score:4, Interesting)

      by Shados (741919) on Friday November 28, 2008 @04:53PM (#25918547)

      (I think they called it "model 2"?),

      Lets make things clear first: MVC model 2 has nothing to do with the original MVC, as you already pointed out. The original MVC isn't used much, not even in live interactive system anymore, so they reused the term, and clearly documented it (it made sense at the time: there is a model, a view and a controller, and its a strict design pattern, and the original MVC is rarely seen outside of legacy system and 4G tools that die faster than they pop up).

      Otherwise, you end up with a lot of terms that eventually all mean the same thing but not, and it is even more confusing. The main issue came with people thinking that MVC is ANYTHING with a model, a view, and a controller. That put aside, there's no abuse of language here. There's MVC, and MVC Type 2, and if you're talking about the web, aside in extremely rare scenarios, you're always talking about Type 2, so its redundant.

      Still, that doesn't change much... MVC, because of frameworks like Struts and Rails is seen by the unwashed mass of developers as the "end all be all: if its not MVC, its not a well architecture application", totally ignoring all of the alternatives. Now THAT is a problem. MVC Type 2 is only good for a subset (large, but still just a subset) of web apps.

  • this topic merits a bigger discussion! toolkits like sproutcore and objective-j are changing the game, not just blurring the lines...
  • by One Photon (1419465) on Friday November 28, 2008 @05:59PM (#25919001)
    I don't understand this concept of MVC "blurring".

    For every instance of MVC, the View component itself can be a complete, nested MVC unit or even a collection of MVC units. This is the nature of the MVC design pattern.

    For example, take the humble HTML button. It is its own complete MVC machine. It has a Model (button state, color, size, etc) and controller logic that responds to events (render "down" state, "focus" state, etc.). And of course it has a graphical View.

    This MVC button machine can delegate events and control to a parent MVC machine, such as an HTML table.

    Delegation continues to parent MVCs at ever higher abstraction layers until finally we're at the level of browser-as-complete MVC machine. The next higher layer involves the server back end, and now the browser is the view component of the server/browser abstraction layer.

    If the server implements its GUI interface layer as servlets, for example, then the servlet/browser is a complete MVC machine. But this layer still does not contain the core business logic, since for any well-designed (non-trival) server it should be possible to completely replace the GUI layer (such as Struts, etc) with another GUI framework without affecting the core business logic/data. And so the browser/servlet layer becomes the view component of the highest MVC layer, which has the core business logic as the model and controller.

    The MVC pattern supports a recursive tree of MVC state machines, typically managed as parent-child relationships. Low level business logic, such as preventing alpha characters from being entered into a SSN text input field, can be implemented directly in the input field widget's MVC machine. High level business logic/data, such as validating and submitting a complex shopping order, takes place on the highest level MVC state machine.

    Business logic/data, like any complex computer science problem, can consist of many different levels of abstraction. It is absurd to think that the business logic of a non-trivial business application can be neatly separated into just three components of a single MVC state machine existing at a single level of abstraction. And so I just don't get this idea of blurring, unless it is just one person's understanding of hierarchal abstraction layers that is blurred, which has nothing to do with a limitation of MVC.

    The challenge is in how to create code on the browser that fully leverages the MVC pattern. If code is to be as well organized, refactorable, and maintainable on the browser side as it is on the server side, an MVC machine needs the full OOP paradigm for expression. That's why tools such as GWT have become so attractive. Tools as these make it practical and affordable to distribute all business logic, high and low, to the proper layer of abstraction -- be it at the widget level, tile level, page level, server level, system level, or enterprise level.

Disclaimer: "These opinions are my own, though for a small fee they be yours too." -- Dave Haynie

Working...