Slashdot Mirror
Web Browser Programming Blurring the Lines of MVC
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."
I did and it's worth it!
The implication is that it ends in a total clusterfuck, just like Ajax?
also found, since the submission, rubyjs which is a ruby-to-javascript compiler and yet another port of GWT - this one's called rwt
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.
The internet, being a series of tubes, naturally adapts itself to the PVC, rather than MVC, model.
If you post it, they will read.
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.
#fuckbeta #iamslashdot #dicemustdie
GWT produces a bunch of bloated, slow, redundant code. Compiling Java to Javascript is a hair brain idea. You don't understand how to code for the Web? Stay away from it.
"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.
I write applications in XUL (around 20.000 LoC). I use "MVC"ish style for the server. But the "client" is smart(reads: fat).
My main problem with JS, is that is float calculations suck. If you want to do something serious with calculations you may have problems.
-Woof woof woof!
[citation needed]
I thought the author's point was weakened when he decided to start tearing down JavaScript and php without giving one sentence to the shortcomings of his language of choice: Python.
... 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.
My work here is dung.
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 have it that easy?
The thing that makes MVC a more advanced skill than what you might learn in undergrad computer programming classes is that it requires more than a good understanding of a programming languages and related tools. It requires you to think things through, plan ahead, and make choices.
YES, it is probably possible to implement "even some of the Model," as the article, says, in JavaScript in the browser. Is that a smart idea?
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?
On the other hand, is MVC the right model for every application?
I think a lot of textbook programming paradigms, including MVC, are ultimately pie-in-the-sky, and somewhere along the line a real-world application is always going to end up making some kind of unfortunate compromise. That doesn't mean you shouldn't be aiming for the sky anyway. If you're actually trying to write well-disciplined, maintainable code, that's always a Good Thing.
The real problem with the Web development environment is that it makes it very easy for developers to choose not to do that and just knock out solutions to problems quickly, instead, without really thinking things through. That's not MVC's fault, nor should one blame one's tools.
God help me, I think the real answer might be ... effective management. Christ, did I really just say that?
Breakfast served all day!
This is very true -- it's so easy to get into the mindset of "well I write webapps, so everything I make has to be a webapp".
Actually, this just happened to me. I was trying to find a way to write a utility that reads and writes in a big directory structure which users can access, but which the app server is not able to see. So I figured I would have to force users to zip up the whole directory and upload it, until my team lead said, "Why don't you just make this a client-side app instead?" Before that it had never even crossed my mind, but it made so much more sense to do it that way.
It's much better to think about requirements with an open mind about the platform than it is to lock yourself in, either consciously or subconsciously.
And don't forget about haXe as well, which has been designed to be able to output JS, but also PHP, SWF, Neko, and more recently C++
that's why i mention RubyJS and GWT as well. all three - RubyJS, Pyjamas and GWT - are javascript compilers.
there are plenty more: see part-way-down the responses to http://advogato.org/article/985.html for a list which one of the advogatians posted.
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.
-1, Predictable Lameass "Joke" Meme
Really jlowery, you're just like a karma whore except that the +1 Funny you're going after does not even boost your karma. So basically you're just an attention whore.
Its a mess because it was never planned. The browser has evolved as a application as more content producers want to use it in ways not originally planned. The browser (and by extension, the web) is the best case study of feature creep and bloat anyone can ask for. It was never made to do what it does, hell, I dont think anyone was ever sure what the hell the purpose of the web and the browser ever was, besides a end-all be-all type of application, and probably the only such application that ever succeeded (yes, even EMACS is not good (or bad) enough to compete in this regard).
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 sorts of compromises are necessary unless we change the minds of users everywhere to appreciate and be willing to work within the limitations of the MVC model. So yeah, we already know that users, especially executive users, management users and especially consumer users, are not prepared to sacrifice their preconceived notions about the way things are expected to look, feel and behave... the systems need to deliver to expectations and that quite often requires numerous compromises to programming idealism.
I have "soap boxed" on this topic especially where Microsoft's backward compatibility "bloat" is concerned. With each new release of Windows, Microsoft misses an opportunity to shed itself of backward compatibility bloat through a variety of means many of which would be completely invisible to the end user... especially solutions that have to do with virtualization and emulation. But instead, they keep supporting old bugs and behaviors and the bloat simply builds leading to the results we see in XP and Vista. While I can state that I completely understand why Microsoft does it, I cannot agree with their perpetuation of this model since thing are coming to a head and the public disapproval of Vista [and Mojave?] is testament to the fact that people are no longer just going to swallow whatever Microsoft serves up and that the power of common, off-the-shelf PCs are not generally sufficient to conceal the bloat and poor performance of Vista.
Okay, I somehow made this about Microsoft. Apologies to those offended. They are simply a very convenient example of a compromise of programming idealism to enable a project to fulfil user expectations... the user expectation of backward compatibility is a large part of why Windows is so bloated and unreliable and I will be the first to admit that Microsoft has done a pretty amazing job of managing the situation as much as they have... think about the enormity and scale Microsoft's maintaining of backward compatibility and you will have to agree.
You keep using that word. I do not think it means, what you think it means.
Teach your kids: "C++ made baby Jesus cry."
For awhile people were saying, "Any cheap computer these days is powerful enough to do web surfing, email, and word processing." But given how AJAXified everything is now and how big web apps are getting, this isn't as true anymore. For example, my Pentium 4 at home will sometimes show a popup when leaving Gmail.com that says something like, "Process still running, leave the page anyway?" Then again, the new browsers like FF 3.1 are supposed to have blazing fast Javascript processing, so who knows?
-- http://ninthagenda.com/
... like that's news?
Slashdot: News that mattered.
JavaScriptMVC is the perfect solution for MVC on the client. The server still can be MVC. It provides services using an MVC like architecture. Here's a good post about the double MVC architecture. http://javascriptmvc.com/blog/?p=68
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.
You still didn't mention the shortcomings of python - no language is perfect and to so thouroughly trounce two you obviously don't have a deep enough understanding of doesn't make for a very balanced or credible article. Javascript is a pure object orientated (prototype based) language. When tackled with disclipline you can create very elegant and well structured code - just like with every other programming language.
Similarly to claim that it's impossible to produce a workable MVC framework with PHP is laughable, it is possible (and many have done it very well indeed). Decent php programmers know not to mix logic and presentation (i.e. embed code in html files - except when that file is simply a very basic template and the only php used is simple variable echo'ing), just like decent c programmers know to use buffer overflow safe string functions. Despite what your short sighted vitriole may assume, there are a large number of professional PHP programmers who can put together a very well architected piece of software.
Don't get me wrong, PHP has it's shortcomings, but you have basically picked on the PEBKAC one - that because it's easy to produce bad code the language must be bad - it's possible to write bad, insecure code in almost ANY language. As far as your gripe about character sets, ruby has problems with unicode until the next version comes out and far too many programmers are ignorant to producing decent internationalised software.
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 describe. but the only better models that matter are those that are backed by a large influential force in the marketplace
i give you google chrome
google chrome will serve as the bridge from the old static html world to the mvc model talked about here. and its probably been discussed at google hq for the last 3 years
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Aptana Jaxer goes the opposite way: use Javascript to do everything, both on client side and server side.
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. 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 exception if the executable isn't correctly signed by the platform owner.
Who says that MVC has to be the only way to build a web app?
It fits sometimes - sometimes it does not.
You obviously have never used Python. I used to do scripts in Perl in the past, but one day I did an interesting experiment: I wrote a 200 lines program in Perl and Python, and compared them side by side. The Python code was slightly larger than the Perl code, but I actually needed about the same number of keystrokes for each, since Perl uses so many characters that need the shift key.
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
"Smart is sexy." -- D. Scully ("War of the Coprophages")
MVC is a broken paradigm, its time to get over it. So please, can we let the broken frameworks designed to enforce it while crippling good engineering practices, like Struts, just die.
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 client. It will execute faster than Java compiled into Javascript. You can even hide that stupid Sun ad that appears as the JVM loads.
Parent has a good point. I work for a software company that Develops GIS (geopgraphical Information Software). and all of our clients want theor programs to be web based. this means VB or C# with AJAX/JAVA. For complexity of these programs, and the time that goes into them, the logical thing to do would make it a windows based application. the clients dont like the fact that they then have to install software, and put more problems on their IT staff. (User policies, hardware/software conflicts). so we bould everything to work based on IE6 (alot of people still use Windows 2000). Its a fricken nightmare. There are no standards that are standard, and the whole web based framework is a mess. .. wtf?
I know i cant be that old school, but why cant people use C++ and and GUI APIs? there are already protocols for talking to your SQL server and app engine via network, and using a windows Application framwork has many benifits. Ive argued this time and time again with my boss, but thats how they want it.
BTW: when i first Read MVC i thought they ment Microsoft Visual C, not Model View controller
Go go Gadget Nailgun!
by following this approach of web services, now all a given php needs to do is: If this is a page to process data:
If the page is to reterieve data:
As you can see since there is less for php to process, the execution for those pages has increased greatly. What makes this process even better is that now all this data can then be cached on some kind of CDN which means fewer calls to your servers and thus lower latency.
If I were to break down each lanuage into the MVC it would be along these lines:
Model: very little JS (I just make sure there is data to submit back to the server. This saves on making calls that will definitely fail) PHP validates all the time.
View: JS and AJAX
Controller: PHP
Hope this helps some clear up some of the confusion
Burn her!
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
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 whole have very short memory.
Because they arent set up to enforce OOP concepts. There are exceptions like Python, Javafx, etc. They end up with BASIC-like spaghetti then.
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.
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.
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 common interface, and as long as a program was reading its input from stdin and writing its output to stdout, it worked together with other programs. On the web, the interface is a bit more complex, involving various languages and protocols, but it is still a common interface that everyone is programming to, which allows the applications to be strung together.
It is not the "semantic web." The software has no insights into the semantics of what I want to do, and routinely I need to go 5 or 6 pages deep to find anything relevant in any of my searches, on Google, on Yahoo!, on my university's library search system, and so forth.
Palm trees and 8
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 rendered on the client side.
--- tracer.ca
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 incompatibilities they all suffer from the most bizarre and twisted coding problems I have ever seen.
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.
DOM still has really niggling and dumb problems after all these years as well.
In the final analysis what we all want is a set of tools that will allow us to design a screen with a particular look and feel that will be presented exactly the same no matter where it is displayed.
Back in the day we had dumb terminals that did little more then accept X,Y print it here commands and handled it pretty well. The advent of the GUI show the promise of what could be accomplished and much of it was realized by using the native components that were designed, text boxes, pull down lists, buttons, radio boxes, check boxes etc.
Today you have to combine three very different styles of design and coding, they are HTML, CSS and Java Script to come up with anything that is remotely useful for doing anything more then displaying text.
We need to glue all those together in a coherent manner that brings it to a true object model.
Take for example the Box Model, these are normally represented by the DIV tag. Now the DIV tag has many modifiable properties, the border, the margins, the background, lots of stuff. But the problem is that many are those properties cannot be modified on the fly without having to make a modification in one or more of the three separate parts. To change the background I have to use Java Script to interrogate DOM to get to the right CSS selector and change that and my god what a pain that is! Would it not be simpler to just do this?
ImgBox = Box.New([styleReference]);
Further all since java scipt is loaded when the page is loaded it should be trivial to have static events pre-built for each component eg:
function ValidateText(){
if(value == NULL){
Alert("This is a required field!");
This.SetFocus();
}
}
LastName = TextInput.New([StyleReference]);
LastName.OnExit = ValidateText ;
Then as the user goes along doing whatever it is they are doing, some even triggers a background change, which for this example is an image, then would it not follow that that the following call would be far more appropriate then what we do now?
ImgBox.Background("/webroot/images/mygreatcorpimage.png");
I understand that designers want things to be limitlessly fluid, but at some point you have to go back to the point of making proper objects and remove the utter randomness from it. ALL of this should be built into DOM instead of scattered across three desperate coding styles.
Everything ends up in DOM but the problem is most of it is far to loosely coupled and cannot access the display engines of the platform as it should. I know this notion goes against what we have all grown used to but I feel that it must be accomplished if we really want the browser to function as it should or can.
Hey KID! Yeah you, get the fuck off my lawn!
Why is the parent post considered offtopic? Some moderator didn't read the article because it's obvious the author is a Python fanatic.
I have long argued 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?
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
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.
Don't thank God, thank a doctor!
this topic merits a bigger discussion! toolkits like sproutcore and objective-j are changing the game, not just blurring the lines...
Keep the faith, share the code
program right down on the bare metal.
GENERATION 25: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
It is an opens source project and could be ported to any language around : http://arv-wf.org/
I stopped reading when I realized the author believed the MVC pattern was the one and only true way and that PHP was the only "web programming" language.
The authors is confusing architecture issues with language issues. Javascript has serious shortcoming, xmlhttp blows due to left and right incompatibilities, and PHP's API design by committee makes it a chores to work with but seriously I can't see the difference between a full blown "AJAX" interface doing JSON call to a web-service and a fat client doing RPC call with CORBA or some proprietary tcp/ip interface*.
Aside from the fact that all this is nothing more than a rape of the HyperText Transfer Protocol and the HyperText Markup Language which were never designed for it in the first place there is absolutely nothing new. If anything xml rpc at least helps bringing the architecture almost back in sync with what we already had 30 years ago with fat clients...
If I still had them around I'd get my CS book from 15 years ago and show you that all the patterns you need are already in there.
(* CORBA is dead thanks god! )
i think.... i think if you turned every assumption about what you _believe_ i believe into its opposite, you'd come close to what i think.
can i suggest, respectfully, that you re-read it without making any assumptions, and then, perhaps, give us the benefit of your experience by mentioning what alternatives there are to MVC?
i would be delighted to analyse the alternatives.
l.
Okay, I admit that your post is much funnier than my original. Feel better now?
Please, moderators: let's give this man the attention he deserves!
If you post it, they will read.
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.
I agree that JS is an incredible language. It is incredible that it has survived all the twists and turns of its development and dubious implementations. JS is frankly ass. Its DOM is an abomination and its semantics are cluttered and redundant. The scripts are crappy by necessity.
It continues thanks to inertia in browser development and the determination of fresh-minted programmers to remind themselves how smart they are by making their work hard. The toolkits exist because the work is soul-killing without them. They don't represent interest in JS so much as interest in making it go away.
I don't quite understand the role of lambda calculus for an ostensibly object-oriented language like JS, either. If it is a functional programming paradigm you are after, XSLT is an order of magnitude more coherent a language, in spite of its verbosity.
illegitimii non ingravare
...turn on Javascript to read TFA?
Have gnu, will travel.
I know most people would not agree, but MS goal was to create one language/apiset for the dekstop app / server code / client side browser interfaces. dotNet and Silverlight2 which uses .net in under 8meg does all this.
If only sun made a fully featured, but small foot print, less than 4meg download JVM, it could have done it and be standard in all browsers, but no, now people had only viable choices because JS was the only choice.
Just having ONE language across all three wide layers is a great ideal.
Liberty freedom are no1, not dicks in suits.
If the entire view is designed in a proper language like Python, doesn't that mean that interface architects and graphic designers (who like creating interfaces) will also need to know Python? I thought one of the most important aspects of the MVC approach was that programmers could focus on the data and logic, and interface people could focus on the view. I say no to this approach.
If you're going to have a third party make write code for you and you have no idea what kind of crap code you're going to get in return, setting requirements like following the MVC model is important. Otherwise, endless frustration and delay in schedule can ensue.
like they are going to stop there
why do you think google wants to build anothr browser? what's the point?
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
It's a common misconception that people are trying to shoehorn everything into browsers. They're not.
The heck they're not. And for good reason.
The browser has all of the display goodness most programs need, and the network makes a nice channel to throw it all through. If your user-centric program (not a driver, kernel or os-specific utility) isn't testing the limits of 3d hardware there's no excuse to not have the backend be a web server and the application itself being a link to the specific port on localhost.
Operating systems are cute and all, but local apps are not cross platform and they're hard to port. Apps that dish a web interface are tons more portable.
Help stamp out iliturcy.
php being knocked like a GOTO statement *sigh* the problem is not the language but how it's used.
JSP versus Servlets
Static binding versus Dynamic binding
XML Attributes versus XML Elements
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga
MVC was just a hyped way to do simple things to sophisticated that the end result would have to be something very simple. Just like EJB. It's the cognitive fallacy of believing your code has more value when it has more functionality (more than your mind can hold) Keep it simple, stupid! I never bothered to develop in both ugly environments.
This meta-article and the whole style of discussion proves it once again in so many ways: To many n00bs claim to much of a say in Web-developenent. Especially among the ones programming a lot but actually knowing squat about web-developement and it's specialties. That something like this goes as an expertise story shows the downside of the field. It's like the entire imature discussion, indifferent raving and bashing about Ajax or RoR or some other recent fad in the field.
To clear a few things up
1) MVC is a construct to describe the most basic setup when using a seperate persistance layer in an end-user application. The concept has been around for at least 15 years and is most certainly *not* limited to web-developement. On contrary, it's basically a relatively simple model for 90ies style GUI DB Apps. For modern web-developement fanatically sticking to MVC is a severe restriction, as in a web-app with seperate persistance, the controller - due to stateless connection to the UI (Browser) - needs to be seperated into at least 2 tiers to make any sense at all, thus turning a pure 3-tier MVC approach into more of a hinderance than a support in webapps.
2) Moving the view layer into client-side logic (if it's in MVC or something else is of no concern) is nothing new. The concept has been around since the dawn of computer networking and is - of course - also a natural progression for web-apps and a growing availability of umbiquious zero-fuss rich-client funtionality (read: non-trivial standardised JavaScript client-server stuff (aka 'Ajax') nowadays works in most Browsers). In many ways the pure server side stuff in web-logic of the last 10 years was an exception and intermediate solution paid for with huge server overhead in order to offer statefull sorta-kinda-GUI-apps in software purpose built for something completely different: Reading documents (aka 'Browsers'). Java was an attempt to get the real thing but it didn't catch on for various reasons. The main being crappy plattform deployment to end-users. That's why - strangely enough for Java enthusiasts - Java still is competing with Flash in that respect.
3) Client-side logic doesn't break MVC. As explained above, MVC has nothing to do wether the app resides on the client, the server or is spread out between. In fact, the most sophisticated frameworks that rely on rich-client functionality do that seperation as the most natural result. Openlaszlo (that which Adope ripped off in Flex) and Tibco GI come to mind as prime examples for that. And both have been around for quite some time now.
As a senior web-developer with solid experience I love the fact that the entire field is very good at regularly offering solid ripostes of result oriented work to any academic arrogance the field of computer science and programming. Thus the ongoing success of PHP-based web-apps. However, it appears that this is taken as an excuse - by professionals just as much as novices - to babble out and present anything they ran accross and haven't fully looked into yet as the newest insight in the field. I sometimes wish people would stop, do some research and then think before they post an opinion that isn't even thought through to the end. Customers and novices interested in the field for whatever reason are confused enough as it is.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
One thing i specifically left out of the article was Pyjamas-Desktop - http://pyjd.org/
it's a port of the pyjamas API to "straight" python, and so the EXACT same app, from the exact same source code, runs natively under the standard python interpreter.
there's no reason why GWT's libraries should not, likewise, be ported to the desktop.
there's no reason why pyjamas should not be ported to c++.
there's no reason why rubyjs / rwt should not be ported to the desktop.
the nice thing that pyjamas-desktop shows is that, thanks to the abstraction layer using webkit underneath, and webkit being available for qt, gkt, wx-widgets and also (as shown in google chrome) google's "silk" drawing API, the pyjamas API is toolkit-independent.
and, again, it can also sit on top of gecko, thanks to Hulahop.
in this way, you get a user-interface applications development widget set and framework that is os-independent, language-independent, browser-independent, platform-independent and widget-set-independent.
i don't know of *any* UI framework that comes *remotely* close to being able to claim that, yet pyjamas + GWT + rwt is *well* on the way.
also, regarding the "incompatibilities" issue: pyjamas, GWT and rwt all support a mechanism to "overload" classes and class functions with browser-specific code, on a per-class and on a per-function basis. so, it *can* be done.
We were so close to being reasonably cross-platform-capable at very high performance with gcc, POSIX, OpenGL and UI toolkits like Qt. Then AJAX happened, *sigh* ... Now everyone is betting on clunky interpreted languages (= more bugs visible only at runtime and 10-50x slowdown) in- or outside browsers and whatever stripped-down UI libraries are available for them.
The tragicomical highlight is the fact that FF itself works rather fine and is reasonably fast on all platforms (plugin bugs like Adobe's notwithstanding) and still people apparently don't see it as a good example for cross-platform coding.
I don't know anymore what drives this industry. Can it really be the fact that with whatever-on-rails you can code the 1000th blog or social networking site in 15 minutes? Instant gratification and zero accomplishment being the new trend in programming?
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Solves a LOT of the issues you mentioned above...
Rails(or php/asp..etc) + RubyAMF + Flex - deploy to browser... or Desktop via Air. Yes - I know.. great isn't it.
"three heads breathing fire, half a dozen plugins", sounds like something Daniel saw in a dream/vision. It just precedes the end of the known world. I guess I am joking, but I was a fan of the KISS principle and it seems flexibility leads to infectibility these days. HTML had a certain elegance, and Dynamic HTML started a slippery slope that has brought us to a web made of gobbletigoop.
AJAX and javascript suck. Only no-programming hacks use them. Convert to the Server Side!
Damn those Google copycats: Native Client: A Technology for Running Native Code on the Web.
"I love my job, but I hate talking to people like you" (Freddie Mercury)