Slashdot Log In
Web Browser Programming Blurring the Lines of MVC
Posted by
kdawson
on Fri Nov 28, 2008 01:32 PM
from the extremely-thick-client dept.
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."
Related Stories
[+]
Technology: Model-View-Controller — Misunderstood and Misused 221 comments
paradox1x writes "Malcolm Tredinnick shares a terrific rant against the misunderstanding and misuse of the Model-View-Controller design pattern. In particular he takes issue with the notion that Django should be considered an MVC framework. He says that 'It's as valid as saying it's a "circus support mechanism," since the statement is both true, in some contexts, and false in others (you can definitely use Django-based code to help run your circus; stop looking so skeptical).' I'm not sure I agree with the entire piece, but it is a very good read." We recently discussed another look at the bending and stretching of MVC patterns in the world of Web development.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
RubyJS (Score:4, Informative)
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]
Re: (Score:3)
You have not understood what a compiler is, do you?
It's a translator/transformer from one language into another.
Machine language as just a language like any other. And the javascript VM is just a machine like any other. (It's virtual. But every processor you can buy got simulated before it got produced.)
Even a real processor is written in a language (eg. Verilog) nowadays.
The only difference between a compiler and a "normal" program is, that the data that compilers process is code too. Oh, and how about a c
More Importantly (Score:5, Interesting)
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.
Re:More Importantly (Score:5, Insightful)
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.
Parent
Re: (Score:3, Insightful)
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
Re: (Score:3)
Babel = Babylon
The form Babylon is the Greek variant of Akkadian Babilu (bÄb-ilÃ, meaning "Gateway of the god(s)", translating Sumerian Ka.dingir.ra). In the Bible, the name appears as ×'×'×oe (Babel), interpreted by Book of Genesis 11:9 to mean "confusion" (of languages), from the verb balbal, "to confuse". [wikipedia.org]
Re: (Score:3, Insightful)
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 maint
Security issues. (Score:5, Informative)
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.
Parent
Re:Security issues. (Score:4, Insightful)
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.
Parent
History of the Internet (condensed) (Score:5, Insightful)
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.
History of the Internet (not even close) (Score:5, Insightful)
... 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.
Parent
Re: (Score:3, Insightful)
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
Re: (Score:3, Funny)
is that I can sit down at basically any computer anywhere in the world, open up a browser, and have basically the same experience with any application I open.
That is not even true with basic HTML/CSS nowdays. Let alone "applications". Not even identical keyboard shortcuts are possible across browsers.
Re: (Score:3, Insightful)
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.
Re:History of the Internet (condensed) (Score:5, Insightful)
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.
Parent
Re:History of the Internet (condensed) (Score:5, Insightful)
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.
Parent
Re: (Score:3)
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
Re:History of the Internet (condensed) (Score:4)
A "real" language has been classically defined to mean "a language which can compile itself."
Complete and total bullshit. If you deny that Python and Perl "compile" themselves, than neither do Lisp or Smalltalk, two of the fundamental pillars of modern programming language pedigree. And I don't think anyone familiar with those languages would claim they aren't "real".
If you then concede that dynamically byte-compiled languages like Lisp, Smalltalk, Java, and C#, among others, qualify as "real" programming languages based on some reinterpretation of your "definition", then any dynamic Javascript compiler (like, say, V8 [wikipedia.org]) automatically promotes Javascript to a "real" language. Sounds like a pretty dubious definition to me.
Honestly, you have no idea what the hell you're talking about, do you?
Parent
Not really an MVC problem (Score:5, Insightful)
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.
Not even MVC (Score:4, Interesting)
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)
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.
Parent
Blurred understanding: MVC is recursive, not flat (Score:5, Informative)
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.
Re: (Score:3, Funny)
And if it doesn't float it's a witch?
Re: (Score:3, Insightful)
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
Re: (Score:3, Informative)
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