Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming

Web Browser Programming Blurring the Lines of MVC 303

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:
  • 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.

  • 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 zappepcs ( 820751 ) on Friday November 28, 2008 @01:53PM (#25917223) Journal

    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 the subject and the problem can be seen in tag clouds. Definitive descriptions of web resources will hinder the semantic web until it dies.

  • by eldavojohn ( 898314 ) * <eldavojohn@noSpAM.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 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 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.

  • Er, so what? (Score:1, Insightful)

    by Anonymous Coward on Friday November 28, 2008 @02:16PM (#25917359)
    Model does not mesh with reality, please adjust reality to conform? Having been developing software since long before words like "methodology" and "design pattern" were introduced I'm somewhat skeptical when they're uttered. The Romans were adept at deploying the design pattern for a stone-built semi-circular arch but that doesn't mean that whenever you need to get water across a valley you should rebuild the Pont du Gard.
  • 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.

  • by Lazy Jones ( 8403 ) on Friday November 28, 2008 @02:31PM (#25917475) Homepage Journal

    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 to get even a tiny Flash or JS app (or even HTML/CSS) to behave identically on all major browsers on 3 platforms (just today I encountered this persistent bug [adobe.com], a major PITA). All you get is a rudimentary cross-platform UI that is terrible for serious work (you know, when every mouse click gives you network latency and hitting backspace on the wrong spot ruins your work).

    Give me a cross-platform language with stable UI and native code compilation and without the design issues of C/C++ (allowing me to write all over the stack/code/memory) over "Web 2.0" any day. ;-)

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

  • by peragrin ( 659227 ) on Friday November 28, 2008 @03:24PM (#25917885)

    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.

  • by tolan-b ( 230077 ) on Friday November 28, 2008 @03:28PM (#25917937)

    Yeah I'm pretty tired of people crapping on PHP and by extension those of us who use it (by choice or necessity).

    Yes it has its problems (not the ones mentioned in the article which are either out of date (magic quotes) or PEBKAC (most of the rest), but there's nothing that major.

    Like anything, use it improperly and you'll come out with crap.

    Also to be honest there's no problem with AJAX and MVC, your Javascript should be making requests to your server-side controller(s) in the same way your generated HTML does (the only difference is your requests and responses are async in comparison to your regular HTML initiated GETs and POSTs). Any application logic in Javascript beyond interface manipulation just means you're doing it wrong.

    There's always going to be some processing going on for the view layer (whether it's during HTML generation, or at 'run time' in the browser as JS).

    HTML + JS suck for making applications, but not for the reasons in the article.

    Incidentally if you're after an event driven widget framework for PHP then Prado looks interesting. Seems similar to Tapestry for Java. Far less restrictive than horrors like GWT. I've not used it myself though as I don't think it's really compatible with my homegrown MVC framework, so I can't vouch for it.

  • by diskofish ( 1037768 ) on Friday November 28, 2008 @06:11PM (#25919143)

    Which is fine for the most part but I think peoples lack of care over things like MVC, nicely written code, etc has really ruined the web.

    I disagree. I've been using the web since the Mosaic days, and I must say - it's better than ever! You can find what you're looking for more quickly, the content is richer and there is more of it.

    A particular design pattern is NOT a silver bullet. I've used M$ Ajax/.NET to develop some websites and applications, and I was very pleased. Sure, it could use improvement, but what cant? Using it was way better than try to do some of the things manually. If the application works well and the code is maintainable, you have succeeded. As long as you plan out your application properly before you start writing it, things will go smoothly down the road.

    I've worked on a project with C code that dates back to the 80's. It's not OO and doesn't knowingly follow any strict design patterns, but guess what? It's easy to follow, well documented, and above all, it does it's job!

    I will say it again: If the application works well and the code is maintainable, you have succeeded.

  • by ultranova ( 717540 ) on Friday November 28, 2008 @06:43PM (#25919395)

    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 and has a standard API for making a graphical UI ? Because I couldn't find any mention of anything but outputting text strings in the libc documentation.

    But it's nice to know that I only need a compiler which understands a particular C "flavour", rather than a browser which understands a particular Javascript flavour. They're very different requirements, those.

    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 yet it works. Were it written in C/C++, it would generate a segmentation violation or a buffer overflow for each of these errors. That's another reason to use web programming languages: they help mitigate the damage caused by incompetent programmers.

    Of course you could get the same benefits by using Java or some other memory-managed language rather than C/C++, but I'm not holding my breath there. Too much "Real Men manage their own memory" vainglory there, not to mention the practical problems, such as garbage collection's bad interaction with swap.</rant>

  • by mt1955 ( 698912 ) <[moc.liamg] [ta] [5591tm]> on Saturday November 29, 2008 @12:35AM (#25922051) Homepage Journal
    php being knocked like a GOTO statement *sigh* the problem is not the language but how it's used.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...