Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Web Browser Programming Blurring the Lines of MVC

kdawson posted more than 5 years ago | from the extremely-thick-client dept.

Programming 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."

cancel ×

303 comments

Please read the article (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#25917103)

I did and it's worth it!

Re:Please read the article (-1)

Anonymous Coward | more than 5 years ago | (#25917173)

MVC is your Mama's Vaginal Cunt. It's really quite tasty.

Re:Please read the article (-1)

Anonymous Coward | more than 5 years ago | (#25917747)

you just ate my creampie.

Implication (0)

Anonymous Coward | more than 5 years ago | (#25917119)

The implication is that it ends in a total clusterfuck, just like Ajax?

Re:Implication (0)

Anonymous Coward | more than 5 years ago | (#25917765)

Am I missing something or did MVC die like... 15 years ago?

Long live sane multi-tier schemes with rational separation of concerns.

RubyJS (3, Informative)

lkcl (517947) | more than 5 years ago | (#25917131)

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:RubyJS (0)

Anonymous Coward | more than 5 years ago | (#25917293)

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]

Wouldn't that be a translator and not a compiler, since it never generates binary machine language?

Re:RubyJS (1)

therpham (953844) | more than 5 years ago | (#25917481)

You could really call it either. I suppose calling it a translator makes sense given the language analogy, but really all a compiler does is read in some file(s) (usually source code) and emit file(s) based on the input, usually but not always in the form of something executable. So, a source-to-source compiler is still a compiler.

More Importantly (5, Interesting)

Alt_Cognito (462081) | more than 5 years ago | (#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.

Re:More Importantly (5, Insightful)

MightyMartian (840721) | more than 5 years ago | (#25917163)

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:More Importantly (2, Insightful)

zappepcs (820751) | more than 5 years ago | (#25917223)

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.

Re:More Importantly (1, Offtopic)

daem0n1x (748565) | more than 5 years ago | (#25917419)

Tower of Babel.

Its a mess because.... (0)

Anonymous Coward | more than 5 years ago | (#25917385)

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

Re:Its a mess because.... (1)

thetoadwarrior (1268702) | more than 5 years ago | (#25917741)

This is true and as I recall the creator of HTML had said, in the past, there wasn't really any intention of people having to delve into the code and presumably he envisioned web page creation like using Word.

Secondly the web has been built up by a lot of people that learned to program through other means. 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 think the early browser wars didn't help this. After all why should someone code with standards when the big guys don't even do thing to one standard?

I'm not a huge fan of Javascript and to be honest it would be nice to see it go away. There has to be a better way to do things. In fact I think everyone should be forced to sit down and agree on one standard for HTML, CSS, and every other fauly web language (ie PHP and it's very sloppy and poor naming conventions) and we start from scratch.

Browsers are free these days so starting from scratch won't be a huge loss to anyone and by using one standard companies should have the decency to share code to help spread the cost around and I think companies will be surprised how fast people are willing to upgrade their lame old browser when they have to.

And yet, you're posting in English (1)

HotButteredHampster (614950) | more than 5 years ago | (#25917689)

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

Re:And yet, you're posting in English (1)

Sloppy (14984) | more than 5 years ago | (#25917781)

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.

Re:And yet, you're posting in English (1)

HotButteredHampster (614950) | more than 5 years ago | (#25917929)

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 the world.

One could argue that the web platform is doing the same thing. Just a musing for a Friday.

HBH

Re:And yet, you're posting in English (1)

MightyMartian (840721) | more than 5 years ago | (#25917899)

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. (4, Informative)

TheLink (130905) | more than 5 years ago | (#25917251)

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

Re:Security issues. (3, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#25917357)

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.

Re:Security issues. (0)

tepples (727027) | more than 5 years ago | (#25917463)

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.

How about "in what way is the client permitted to view/modify that data?" In other words, "do the modifications that the client proposes introduce inconsistency into the model?" The constraints can become more difficult to verify on the server once more of the model moves to the client; compare cheating in online multiplayer games.

Re:Security issues. (1)

Timothy Brownawell (627747) | more than 5 years ago | (#25917557)

The constraints can become more difficult to verify on the server once more of the model moves to the client; compare cheating in online multiplayer games.

I thought there were two main issues with cheating, that the client is given data it isn't permitted to use (because you can't have a round-trip just to find out what suddenly popped out from behind that wall), and that alternate input methods aren't considered fair (you have to use mouse/keyboard/joystick, no scripts or bots). It has nothing to do with data integrity, it has to do with unenforceable rules that could be violated with a network sniffer and camera driving a fake mouse and keyboard.

Re:Security issues. (1)

TheLink (130905) | more than 5 years ago | (#25917697)

That's actually the point.

The rules ARE enforceable if you keep most stuff server side, but at the expense of increased latency, higher server load and very poor user experience.

And the "poor user experience" is what a lot of people are complaining about with webapps, and that's why they are shifting stuff client side.

While you can do some stuff safely, it does make me wonder what is likely to happen after all that blurring and layers of abstraction/indirection.

Truth be said, I don't wonder at all, it's inevitable - lots of PHBs are going to insist on something stupid and thousands of cheap clueless programmers are going to do it ;).

Re:Security issues. (1)

DarthJohn (1160097) | more than 5 years ago | (#25917875)

lots of PHBs are going to insist on something stupid and thousands of cheap clueless programmers are going to do it

Pity the ones that have clue enough to know what they're doing, but for some reason or other have to anyway.

Re:Security issues. (1)

Timothy Brownawell (627747) | more than 5 years ago | (#25917917)

The rules ARE enforceable if you keep most stuff server side, but at the expense of increased latency, higher server load and very poor user experience.

Some of the rules. I'd guess you could make a decent bot with a good camera and something that could pretend to be a USB keyboard.

And the "poor user experience" is what a lot of people are complaining about with webapps, and that's why they are shifting stuff client side.

This is only an issue if read permissions are time-sensitive and changing in real time, which I think is pretty much limited to games. In other cases, client-side prefetching is perfectly OK. Write caching is also OK, either write-back with a save/commit button (which will give an error if the client has been hacked and gotten out of sync with the server) or write-through (where you can asynchronously get an error and have your change locally revert one round-trip after you make it).

Re:Security issues. (1)

madfancier (1111009) | more than 5 years ago | (#25917759)

For that you constrain your database with foreign key constraints, and if you're using Postgres and ActiveRecord and Migrations - check out this gem [github.com] . This way you're guaranteed that whatever enters your database is always valid. Unless you screwed up something of course. : )

No surprise to Senator Ted (2, Funny)

jlowery (47102) | more than 5 years ago | (#25917193)

The internet, being a series of tubes, naturally adapts itself to the PVC [clearpvcpipe.com] , rather than MVC, model.

MOD THIS IDIOT DOWN (0)

Anonymous Coward | more than 5 years ago | (#25917361)

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

Re:MOD THIS IDIOT DOWN (0)

Anonymous Coward | more than 5 years ago | (#25917411)

And leave it to idiots like you to give him attention by calling him an attention whore. At least he takes the hit on his karma like a man, unlike us cowards.

Re:MOD THIS IDIOT DOWN (0, Offtopic)

jlowery (47102) | more than 5 years ago | (#25917627)

Oh settle down...

Slashdot wouldn't be Slashdot without the drive-by puns.

My karma is excellent, btw. Is there some super-excellent karma I should be going for?

Re:MOD THIS IDIOT DOWN (1)

acidrainx (806006) | more than 5 years ago | (#25917719)

No kidding. This guy is obviously having a shitty day and decided to take it out on your lame (but funny) joke. If I had mod points I'd mod you up.

History of the Internet (condensed) (5, Insightful)

girlintraining (1395911) | more than 5 years ago | (#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.

History of the Internet (not even close) (5, Insightful)

eldavojohn (898314) | more than 5 years ago | (#25917291)

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

Re:History of the Internet (not even close) (1)

mweather (1089505) | more than 5 years ago | (#25917327)

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.

Re:History of the Internet (not even close) (1)

eldavojohn (898314) | more than 5 years ago | (#25917351)

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

Re:History of the Internet (not even close) (0, Flamebait)

Threni (635302) | more than 5 years ago | (#25917535)

I use vb.net. I recently took a look at the way you do java web development. It's a bit pre-.net isn't it? There seems to be an awful lot of fucking around to do the sort of stuff you do with drag and drop or a few lines of code in .net. Yeah yeah, drag and drop isn't real coding. I know. Real coding is what I can get on with doing having first created an app for someone in 30 mins using (largely) drag and drop.

Re:History of the Internet (not even close) (1)

EvilRyry (1025309) | more than 5 years ago | (#25917891)

Real coding is what I can get on with doing having first created an unmaintainable, poorly designed, basic app for someone in 30 mins using (largely) drag and drop.

There, fixed that for you.

In all seriousness, clicky pointy tools like VS are fine and dandy but they tend to be more limited in their functionality compared to hand coding. And yes, you can get these sorts of tools for various Java web frameworks as well (you never mentioned which one you looked at).

Personally I prefer to have complete control over the HTML and CSS output when I'm doing anything that will have a life of more than a few months.

Re:History of the Internet (not even close) (1)

digitalgiblet (530309) | more than 5 years ago | (#25917541)

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.

Re:History of the Internet (not even close) (1)

sentientbrendan (316150) | more than 5 years ago | (#25917585)

>>>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 other hand is an enormous pain the ass for a lot of the tasks people use it for. Consider the word processor that google is trying unsuccessfully to write. If they put that together as a java applet, it would be trivial. However, since they went the ajax route, they have an application that is feature poor, and still manages to crash so often that it is unusable.

Re:History of the Internet (not even close) (1)

FishWithAHammer (957772) | more than 5 years ago | (#25917795)

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

Re:History of the Internet (not even close) (1)

EvilRyry (1025309) | more than 5 years ago | (#25917915)

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

Re:History of the Internet (not even close) (1)

gstoddart (321705) | more than 5 years ago | (#25917883)

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

Re:History of the Internet (not even close) (1)

MightyMartian (840721) | more than 5 years ago | (#25917339)

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:History of the Internet (not even close) (2, Insightful)

peragrin (659227) | more than 5 years ago | (#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.

Re:History of the Internet (not even close) (2, Insightful)

Lazy Jones (8403) | more than 5 years ago | (#25917475)

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. ;-)

Re:History of the Internet (not even close) (1)

sentientbrendan (316150) | more than 5 years ago | (#25917545)

>>... 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 was saying that the browser itself is not a real platform, which it isn't. The browser is a joke because its capabilities have more or less stagnated at what internet explorer 6 can provide.

Browsers are a huge pain in the ass to develop real applications for and require all sorts of insane hacks to do things that are trivial if you just write your own C++/Java/Whatever applications to run on the server and client.

Probably someday the browser will evolve into a great platform for writing clients, but that's maybe 10 years out.

For the time being, there are still some ease of deployment reasons to code ajax applications, but in a lot of cases there are technologies like java applets, flash, and even C++ and python clients that can be written when more complicated interface and behavior are needed.

Re:History of the Internet (not even close) (1)

thetoadwarrior (1268702) | more than 5 years ago | (#25917807)

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 everyone else. All this mentality has done is give people no reason to upgrade their browsers and as a result hold back web development. Instead of written something new and innovative you have to spend time has to be spent on writing different code to perform the same thing in JavaScript, CSS hacks, etc.

Yes there are a lot of frameworks that over come these issues but it's a shame that so much time has to be spent over coming problems that shouldn't exist rather than writing some new and inspirational.

Re:History of the Internet (not even close) (1)

Windows_NT (1353809) | more than 5 years ago | (#25917811)

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

How many architecture CANT you compile C++ code? 90% of the market runs windows anyways .. Allt he same people that think JAVA is a good thing because its neutral? I dont know anyone that runs Google earth on a VAX ...
You can get away with three binary distrobutions ... MAC, Windows, and Linux ... C++ with GTK works on all three .. problem solved.
Ok, enough chat i need to get back to my VB code :(

Re:History of the Internet (condensed) (5, Insightful)

abigor (540274) | more than 5 years ago | (#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.

Re:History of the Internet (condensed) (4, Insightful)

vux984 (928602) | more than 5 years ago | (#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.

Libraries are a problem in both C and JS (1)

tepples (727027) | more than 5 years ago | (#25917571)

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 exception if the executable isn't correctly signed by the platform owner.

Re:History of the Internet (condensed) (1)

girlintraining (1395911) | more than 5 years ago | (#25917553)

A "real" language has been classically defined to mean "a language which can compile itself." Perl, Python, and Ruby cannot do that (to my knowledge). Most languages used by web developers are interpretive languages, which fail this test.

Re:History of the Internet (condensed) (0)

Anonymous Coward | more than 5 years ago | (#25917579)

I'm pretty web savvy... While I've heard of salesforce.com I've never used it or know what it does. Taleo, never heard of it. I have a GMail account but I don't really use it because, quite frankly, I hate using a browser. Even Firefox feels clunky and slow, and don't get me started on IE. Thunderbird opens up in half the time. I relize I could connect to GMail via imap with Thunderbird but my point is, web apps tend to suck compared to native apps.

Re:History of the Internet (condensed) (1)

lkcl (517947) | more than 5 years ago | (#25917321)

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?

Re:History of the Internet (condensed) (1)

thetoadwarrior (1268702) | more than 5 years ago | (#25917857)

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.

Mod parent Insightful (1)

kbrasee (1379057) | more than 5 years ago | (#25917331)

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.

Re:History of the Internet (condensed) (1)

Draek (916851) | more than 5 years ago | (#25917383)

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.

Re:History of the Internet (condensed) (1)

mangu (126918) | more than 5 years ago | (#25917493)

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 crowbar'd into a web interface to be considered modern these days?

Applications have to be installed and supported in the users' computers if they don't have a web interface. If it's an application that will be used only by me, or by very few people, then I do the interface in Qt, using Python. Otherwise, I always try to do it as a web app.

But I agree with you that browsers are bloated. Web interfaces should be carefully adapted to work well, one cannot just try to do a direct conversion from a local GUI. These toolkits like GWT or PyJs have their limitations, they are useful for doing a quick job, but one should use their functions carefully, not abuse them.

Re:History of the Internet (condensed) (1)

sycodon (149926) | more than 5 years ago | (#25917495)

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 a mind boggeling number of methods, most of which are used to convert data into a form acceptable to another method. Many times, you just can't get there from here.

And formatting with HTML tables SUCKS!

And the class documentation is mostly something like this:

A: is blah blah of B

then look up B

B: is blah blah of A.

Or try this:

"Public Shared Function Find(Of T)(ByVal array() As T, ByVal match As System.Predicate(Of T)) As T
          Member of: System.Array
Summary:
Searches for an element that matches the conditions defined by the specified predicate, and returns the first occurrence within the entire System.Array."

This smells of code documentation generated by code.

WTF? Can't people write complete sentences describing what the freaking code does?

I long for the day of plain and simple client server architecture. Hell, it all practically works the same except they traded the clean, well documented and debugged clients for a myriad of incompatible web browsers using kludges to accomplish what used to be straight forward client functionality.

The ultimate goal of all of this crap is the Holy Grail of easily modifiable systems. But in the pursuit of this goal, development has become a nightmare of competing, half-implmented, half-assed and incompatible languages and frameworks.

Machines that can run web but not C++ (1, Informative)

tepples (727027) | more than 5 years ago | (#25917499)

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.

Re:History of the Internet (condensed) (1)

Abcd1234 (188840) | more than 5 years ago | (#25917515)

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 know any serious programmer who claims otherwise. But there are *many* programming languages out there *far* superior in their own domains, and Javascript is absolutely among them.

In short, yes, you're jaded, old, and behind the times. Open your mind. A world does, in fact, exist outside of systems-level application development.

Re:History of the Internet (condensed) (1)

girlintraining (1395911) | more than 5 years ago | (#25917599)

A "horrible" confluence of hacks that is fast, low-level, reliable, and object oriented and gives the programmer full access to everything? So you prefer slow, high-level, unreliable, procedural-based languages that give you little to no access to the underlying infrastructure? You're a visual basic programmer, aren't you?

Re:History of the Internet (condensed) (1)

thetoadwarrior (1268702) | more than 5 years ago | (#25917881)

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.

Re:History of the Internet (condensed) (1)

ccguy (1116865) | more than 5 years ago | (#25917519)

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.

History of a pain-in-the-ass (1)

Windows_NT (1353809) | more than 5 years ago | (#25917777)

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.
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 .. wtf?

Re:History of the Internet (condensed) (1)

gstoddart (321705) | more than 5 years ago | (#25917869)

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 with you that it's a big mess.)

Sadly, I see the same thing in Outlook. There seems to be a peculiar push to integrate everything into Outlook so that people can do all of their tasks from within that one application -- because it's familiar and everyone already has it open. Users seem to be increasingly demanding that any new applications they get rolled out to them be embedded in Outlook so they don't have to go through retraining. (At least, that's what Marketing tells me. :-P)

Somewhere along the line, people expected that everything would move into the single application they use for everything, instead of the previous "run this program to do this work".

Cheers

PS -- you're old, jaded, and behind the times. ;-)

Re:History of the Internet (condensed) (1)

sjames (1099) | more than 5 years ago | (#25917887)

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 of that mess there still exists nothing like a standard interface to play a streaming audio or even a consistant way to play a decent static sound with any degree of control.

The next approach we see is attempting to push as much of the work as possible into the browser (using it like a VM). There we pile the problems above along with developers that don't seem to understand that the client's system cannot be trusted to make any security decisions that affect more than that particular user accessing the system. Because the browsers don't even consider security as an issue during the design phase, we still have no way to use something like an iframe as a sandbox (why not just let the parent document publish a set of javascript functions that the iframe's contents may access (if any)?!?)

Then, there's the problem on the development side. WE can't seem to decide what a web designer is. In practice, web designers are porimarily visual arts people who through lack of choice do some cargo cult programming (with all of the problems THAT implies). For some reason, people can't get it into their heads that the functionality of a site/page should be done by an engineer with input from the web designer on the visual aspects of the page(s).

In part, that's because there is no clear separation of the tools. In a more traditional project, a visual designer uses image and layout editors to produce a look and feel. The programmers take the output of those, edit source files and project/makefiles in order to produce an application. The visual designer never touches *.c and doesn't even have a compiler. The programming team may or may not have an image editor, but if they do, they only use it to do format conversions (or for non-project work).

In contrast, for Web 2.123 Comet or whatever, a web designer places *.html files on a server in order to cause the browser to display them while a programmer might edit the very same files on the same server in order to get the very same browser to act like a VM. The web designer MIGHT have legitimate reasons to touch javascript and the programmers might have valid reasons to alter the HTML.

The result of all of that is that many AJAX projects end up as a hodge-podge of cargo cult programming, hacks and workarounds, and multi-branching wrappers to trick various crappy browsers into doing something reasonable.

Add on top of that that the browser specs themselves are loaded with ad-hoc addins and the real specs are besieged with corporate political infighting and you get the current state of affairs.

As a result of that, in-turn, you get various frameworks that try to tame the untamable and try to make the browser into something it's not ready to actually be (as you point out). Naturally, these break on a regular basis as new browser versions shovel their own crap into the mix.

I suppose the answer to your question is that everyone wants a sort of X terminal on steroids application with a genuinely write once run anywhere VM (That is, with absolutely NO platform specific extensions allowed for any reason) but what they have is a browser that sorta thinks it can be those things (with at least one of the major players bound and determined to bastardize it into an extended form of vendor lock-in). Meanwhile, there is also a legitimate desire for it to be able to display essentially static markup without having to have a programmer go over the static pages. Much of the 'programming' that happens there is to compensate for the spec not reflecting what the designers actually want to be able to do.

GWT is junk (0)

Anonymous Coward | more than 5 years ago | (#25917241)

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.

Haha, Python programmers (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25917247)

I don't think Python programmers have a right to complain about the other crappy systems because Python itself is a poor design. I almost don't even consider Python a scripting language because it's so verbose. Writing Python is almost like writing C/C++ code or whatever. The only advantage being the fact that it's interpreted.

Seriously, if I was considering writing something in Python I would rather just write in a regular compiled language so it can run with performance. If I want to script then I might use Lua, Perl or similar but definitely not Python.

Re:Haha, Python programmers (1)

Crimsonjade (1011329) | more than 5 years ago | (#25917285)

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.

Re:Haha, Python programmers (0, Flamebait)

lkcl (517947) | more than 5 years ago | (#25917349)

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 [advogato.org] for a list which one of the advogatians posted.

Re:Haha, Python programmers (0)

Anonymous Coward | more than 5 years ago | (#25917517)

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.

Re:Haha, Python programmers (1)

mangu (126918) | more than 5 years ago | (#25917683)

I almost don't even consider Python a scripting language because it's so verbose. Writing Python is almost like writing C/C++ code or whatever.

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.

not a problem, other than Javascript floats (1)

Tei (520358) | more than 5 years ago | (#25917255)

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.

Re:not a problem, other than Javascript floats (2, Funny)

sakdoctor (1087155) | more than 5 years ago | (#25917337)

And if it doesn't float it's a witch?

Re:not a problem, other than Javascript floats (0)

Anonymous Coward | more than 5 years ago | (#25917561)

Only if it weighs the same as a duck.

Does duck typing count? (1)

Giant Electronic Bra (1229876) | more than 5 years ago | (#25917815)

Burn her!

necessary introduction of Javascript and AJAX? (0)

Anonymous Coward | more than 5 years ago | (#25917279)

[citation needed]

Does it really blur the idea of MVC? (1)

PCM2 (4486) | more than 5 years ago | (#25917307)

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?

Re:Does it really blur the idea of MVC? (1)

mini me (132455) | more than 5 years ago | (#25917521)

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.

haXe (0)

Anonymous Coward | more than 5 years ago | (#25917335)

And don't forget about haXe [haxe.org] as well, which has been designed to be able to output JS, but also PHP, SWF, Neko, and more recently C++

Er, so what? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#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.

Not really an MVC problem (5, Insightful)

shutdown -p now (807394) | more than 5 years ago | (#25917393)

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.

Re:Not really an MVC problem (1)

cjonslashdot (904508) | more than 5 years ago | (#25917727)

I disagree. I feel that the model should be server-side.

Yet I agree that MVC is often implemented incorrectly. The client can have multiple views, each a kind of 'model' in its own right (but not the 'model' as defined by MVC), depicting some aspect of the central, shared (authoritative) model. The shared model should be on a server, since it is shared. That is the only way to ensure proper concurrency control. The shared model is usually a database, or a facade provided by an app server.

What people often do wrong is they don't handle the error conditions that the server model can produce when concurrent access causes conflicts.

Another thing people do wrong is they update the client view directly in response to user actions, but in the MVC model all view updates should come from the server.

There is a slight modification to this pattern, in which updates to a client view are made immediately by the client, but on a tentative basis, and the server can veto the change, in which case the client needs to be prepared to invalidate or restore the view to the correct state, as defined by the server.

The pure MVC pattern is more of an idea, rather than a full design pattern, since there are many complex issues that must still be decided, such as what types of objects will be sent between client and server (view and model), how invalid elements will be marked as such and refreshed, how the client should be notified of changes to the model made concurrently by other users, how the client will keep track of which view objects correspond to which model (server) objects, and how to ensure that corrupt client-side objects (e.g., object changes cancelled by the user) do not propagate to the server.

Re:Not really an MVC problem (1)

acidrainx (806006) | more than 5 years ago | (#25917831)

People use the something-to-JS compilers because it lets them remain in their comfort zone. While things are changing, a lot of programmers have no respect for JavaScript as a language and that's mostly due to the crappy scripts that are floating around that web.

Most people don't know that JavaScript is an incredible language with features like lambdas and closures; features that are found in functional languages like Scheme and Lisp. It's also one of the most object-oriented languages I've ever worked with where objects can be defined inline with properties added and removed at runtime. It actually gets quite complex with its prototypal inheritance pattern which is a real mind bender for people who were trained to use classical inheritance.

I'm not saying that it's perfect but there's a great deal of depth in it that's made it one of the most interesting languages I've ever learnt.

Idealism in the programming world (1, Interesting)

erroneus (253617) | more than 5 years ago | (#25917399)

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.

Re:Idealism in the programming world (1)

erroneus (253617) | more than 5 years ago | (#25917451)

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

Hello, my name is Inigo Montoya.... (1, Troll)

Kitanin (7884) | more than 5 years ago | (#25917407)

... necessary introduction of Javascript and AJAX.

You keep using that word. I do not think it means, what you think it means.

The old refrain is not as true anymore (1)

NinthAgendaDotCom (1401899) | more than 5 years ago | (#25917431)

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?

Oh, come on... (1)

Abuzar (732558) | more than 5 years ago | (#25917457)

... like that's news?
Slashdot: News that mattered.

Anyone Seen JavaScriptMVC (1)

Justin Meyer (1419339) | more than 5 years ago | (#25917483)

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 [javascriptmvc.com]

of course (1)

circletimessquare (444983) | more than 5 years ago | (#25917523)

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

Also worth mentioning (1)

Keyper7 (1160079) | more than 5 years ago | (#25917533)

Aptana Jaxer [aptana.com] goes the opposite way: use Javascript to do everything, both on client side and server side.

MVC Everywhere? Why? (0)

Anonymous Coward | more than 5 years ago | (#25917669)

Who says that MVC has to be the only way to build a web app?

It fits sometimes - sometimes it does not.

MVC is a broken paradigm (0)

Anonymous Coward | more than 5 years ago | (#25917733)

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.

Java - Javascript = bloat (1)

Animats (122034) | more than 5 years ago | (#25917763)

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.

Here is a POV (1)

creeves1982 (880009) | more than 5 years ago | (#25917809)

I am currently updating a very archaic administration system. It was written back in the days of PHP 3 and has not been touched since then. I am now developing this using AJAX and PHP 5. I started by developing all the different web services that this administration environment controls. It ranges from Login to Retrieving/Editing data. All PHP is doing is checking security and making database calls. Using AJAX, the application pulls in all the data and displays it on the page. By following this method, I have been able to improve the load time of each page from 6 seconds to ~
  1. Check the users authentication
  2. Get a list of all the "accounts" the user has access to
  3. Build the list of avialable functions the user has access to
  4. Check if the user has submitted data
  5. validate the data and process
  6. If the submitted user data is valid and has been processed successfully then go and include the success php page.
  7. build the html for the navigation
  8. build the html for the forms on the page

by following this approach of web services, now all a given php needs to do is: If this is a page to process data:

  1. Check authencation
  2. process data
  3. return success or error

If the page is to reterieve data:

  1. Check authenciation
  2. Read data from the data base
  3. format the XML

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

Javascript/AJAX change nothing (1)

BigGerman (541312) | more than 5 years ago | (#25917837)

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.

most scripting languages discourage abstraction (1)

peter303 (12292) | more than 5 years ago | (#25917923)

Because they arent set up to enforce OOP concepts. There are exceptions like Python, Javafx, etc. They end up with BASIC-like spaghetti then.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...