Article: Direct Ajax - Goodbye to Ajax Deadly Sins

Discussions

News: Article: Direct Ajax - Goodbye to Ajax Deadly Sins

  1. The programming techniques lumped under the name of Ajax can have unintended consequences that actually make development more difficult and hurt application performance. In response, Robbie Cheng offers a model he calls Direct Ajax that, in effect, involves server-based processing rather than the traditional Ajax division of labor. Read Article

    Threaded Messages (47)

  2. I really didn't like: 1. Fast Prototyping The UI, and the backend of an application are no longer separated.. 2. Easy Maintenance No more client codes. For 1. I think that while you are moving UI to backend it will have performance issue on the other and it will be an spaghetti code (not good to maintenance) For 2. I think "JSR 303: Bean Validation" is the answer for not worry about client/server side codes. If you don't make an small client code validation it will be constant unnecessary request going to server. we don't need sophisticated client code, only the most simple to avoid performance and to communicate with user soon as possible. I really don't image an email field with wrong email typed where user need to go to server to have communication of this simple error.
  3. The codes[ Go to top ]

    I cringe every time I see an article where someone is speaking about "the codes". I know the author is probably not a native speaker (neither am I), but couldn't this be somewhat edited?
  4. Back to JSP? Oh no![ Go to top ]

    And what about things like Gears and utilizing client machine power for some computations? This feels like dumb terminal all over again. Oh, and I just love these ZK marks in the comparison matrix :)
  5. The question is how to provide an elegant solution for both prototyping and formal development (such as MVC). The choice shall be the developer's. JSF is a bad example that enforces too many things to make it hard to learn. IMO, BeanShell and Groovy is really good for protyping, while annotation-like databinding is good for MVC. You might take a look at Groovy: http://pastebin.com/f3eea6d28 MVC: http://www.simonmassey.org/zktodo2.html
  6. For 1.
    I think that while you are moving UI to backend it will have performance issue on the other and it will be an spaghetti code (not good to maintenance)

    Marcos, This is a misunderstanding, we're not going to mix the UI code and business logic. Direct Ajax aims at ease the development coast of Web application by handling the Ajax stuffs for developers.
    For 2.
    I think "JSR 303: Bean Validation" is the answer for not worry about client/server side codes. If you don't make an small client code validation it will be constant unnecessary request going to server. we don't need sophisticated client code, only the most simple to avoid performance and to communicate with user soon as possible.
    It's not about validation only, a real Web application involves more complex activities, ex. accessing server resources. Bean Validation doesn't solve these issues.
  7. Excuse me if I misunderstood the article. Did you just reinvent DWR?
  8. Quite oppositely, direct Ajax the author mentioned is about controlling everything in the server, while DWR is more like a way to 'control' the server from the client. I think Direct Ajax is the same as so-called server-centric, which is my favorite. After all, almost all resources reside at the server. On the other hand, client-centric solution is more responsive. Just my two cents.
  9. completely biased[ Go to top ]

    smells distinctly like zpam
  10. More about For 2. I think "JSR 303: Bean Validation" JBOSS SEAM already do an great job as an framework providing client validation without a lot of job.
  11. Google Web Toolkit , Echo?[ Go to top ]

    Looks like "Direct Ajax" is something GWT, Echo and Swing to HTML frameworks are already doing. I still was not sure if author was proposing to use plain form POST to capture user actions or Ajax remote calls?
  12. Firstly, he decided to develop in-house JavaScript codes for the UI, the first draft of which took his team 2 months to finish. Then he discovered that the layout was a mess on different browsers. Due to a lack of JavaScript knowledge, he then decided to adopt an off-the-shelf Ajax widgets framework along with a Java-to-JavaScript framework in order to overcome this browser incompatibility issue; that, of course, meant re-building the UI from scratch.
    So what's the conclusion of it? Simple: Don't do stupid things. The gays were developing in-house JavaScript framework, and after two months they have tested it on different browser and discovered that is doesn't work well... Come on, we all know for 10 years that there are differences between browsers - and there are plenty of libraries which hide those differences, and planty of people who can cope with it. So if somebody did one project wrong, doesn't mean the client-side javascript and ajax is wrong.
  13. JavaScript is done wrong quite often[ Go to top ]

    Come on, we all know for 10 years that there are differences between browsers - and there are plenty of libraries which hide those differences, and planty of people who can cope with it.
    So if somebody did one project wrong, doesn't mean the client-side javascript and ajax is wrong.
    Well, interestingly enough most commercial websites DO create JavaScript errors you might not even notice but for a small icon when not running in debug mode. A lot of online banks do for example with noone doing anything about it. A lot of webshops do. Apparently without anyone doing anything about it. Because stuff somehow works anyway. So, well client-side Javascript is not wrong per se but it is done the wrong way more often than not.
  14. May be casual but I've written some days ago an article with similar analysis at CometDaily.com (focused on Comet). Some comments: Direct Ajax = Server-centric web development using Ajax There is no need to invent a new concept or term. I agree with the article, server-centric development frees the developer to build client-server RPC code to transport data. In spite of I'm in the boat of server-centric programming (I'm the author of ItsNat), server-centric is not the panacea, any approach has drawbacks and advantages, for instance, server-centric isn't appropriated for UI intensive applications. Both paradigms aren't incompatible and can be mixed if the server-centric framework used isn't "markup intrusive" (the case of ItsNat). Some concepts I don't like from the article: Direct UI, Direct DB, Direct Live, Direct Web service: may be appealing initially, though all of them propose the coupling of static view layout, view-logic and business logic all in the same file, the bad approach of the old practice "all in the same file" present on bad designed JSP based applications coded before the MVC era. @adgsa awewr:"The gays were developing in-house JavaScript framework" And what is the internal name? JSPink? RainbowJS? Is a joke :)
  15. I have never liked using Ajax. Messing with JavaScript and HTML tags is a pain in the butt. I use FLEX. Period.
  16. An architecture that won't scale[ Go to top ]

    You better use a good framework to avoid all these problem in the first place. Also, I don't think Direct AJAX will solve the layout problem in cross browser.
  17. Yet another Ajax framework intended to shield programmers from JavaScript. Sigh...
  18. Thanks for posting the article. Our team used to work with Swing. We are developing Web applications recently. We don't like JavaScript. More important, the desktop programming model for Web applications is exactly what we love.
  19. Used to do Swing, now doing web?[ Go to top ]

    Thanks for posting the article.
    Our team used to work with Swing. We are developing Web applications recently. We don't like JavaScript.
    More important, the desktop programming model for Web applications is exactly what we love.
    Ralf: You pretty much made a summary on how we are doing web apps with IT Mill Toolkit. Programming model follows the ideology of Swing programming (components, events, listeners, etc). What we have discovered is that the learning curve in these kind of scenarios is minimal when jumping from desktop programming to RIA programming. With Swing you are developing B2B apps for desktop, with IT Mill Toolkit you developing B2B apps for web. Have a look, you might like what we have here in our hands. With Best, Ville Ingman Oy IT Mill Ltd http://www.itmill.com/itmill-toolkit/
  20. Yet another Ajax framework intended to shield programmers from JavaScript. Sigh...
    [jump back into the past ..] C? Yet another high level language intended to shield programmers from Assembly. Sigh... While some of us can program Javascript (and thus AJAX), we would rather not spend our days dealing with cross browser issues, "low level" programming and the ever-so-fun "find the Javascript bug" game . We have business needs to fulfill. Sometimes going "low level" is needed. But when one is building applications that need or might need a browser based, non-plugin UI, using a framework that allows you to more easily build and application is more than likely the way to go. It all depends on the web-whatever you are building.
  21. JavaScript is not assembly[ Go to top ]

    Yet another Ajax framework intended to shield programmers from JavaScript. Sigh...

    [jump back into the past ..]
    C? Yet another high level language intended to shield programmers from Assembly. Sigh...

    While some of us can program Javascript (and thus AJAX), we would rather not spend our days dealing with cross browser issues, "low level" programming and the ever-so-fun "find the Javascript bug" game . We have business needs to fulfill. Sometimes going "low level" is needed. But when one is building applications that need or might need a browser based, non-plugin UI, using a framework that allows you to more easily build and application is more than likely the way to go. It all depends on the web-whatever you are building.
    I get the comparison because of the platform inconsistencies, but those inconsistencies are really in the DOM and not the language itself. JavaScript 1.5 is extremely consistent across browsers. As for JavaScript being "low-level", that's ridiculous. It's an extremely flexible and powerful language. It has garbage collection, inheritance, polymorphism, closures, object literal syntax, lazy evaluation, and other features all with very small syntax. Don't even try to compare it to assembly. Are there wrinkles? Hell yes. Is the tooling support kind of crap? Yes, but getting better. I like that there are frameworks out there that can hide JavaScript from end users. Choice is important. If you find it more productive, that's great, but a layer of abstraction does not mean higher level.
  22. JavaScript 1.5 is extremely consistent across browsers
    For the browsers that use it.
    As for JavaScript being "low-level", that's ridiculous
    That is why it was in quotes. I am not saying JavaScript is bad or not powerful.
    Don't even try to compare it to assembly
    You missed the point. I was NOT comparing Assembly to JavaScript. I was comparing the mentality of people who think abstractions are bad or not necessary.
    but a layer of abstraction does not mean higher level
    Not that Wikipedia is always right ... http://en.wikipedia.org/wiki/High-level_programming_language
  23. To me, the question of whether JavaScript is a good language or not (actually, I think it is), or whether it's well supported in web browsers, or even whether it has good tooling are all irrelevant. The main reason I think coding UIs directly in JavaScript is not a good idea is that JavaScript won't also be used on the server side (JavaScript on the server never got any traction). I mean, WHY pay the extra development and maintenance cost of using two major imperative programming languages for the same application? It's totally counter productive.
  24. Not that Wikipedia is always right ... http://en.wikipedia.org/wiki/High-level_programming_language
    A higher level language DOES imply an abstraction layer, but an abstraction layer does not imply that one language is higher than the other. I can run JavaScript on Java using Rhino, that doesn't make it a higher level language than Java. What we're talking about here is providing a layer of code to hide platform differences. This is done all the time using JavaScript libraries. I think abstraction layers are wonderful. Software engineering as a practice is all about building layers of abstraction to be able to modularize and maintain code. All I'm saying is that you can do it without having to go to another language. However, I recognize that there are many advantages to doing so. I think you should use whatever makes you the most productive.
  25. but an abstraction layer does not imply that one language is higher than the other
    I said "higher level" not higher. I am not degrading JavaScript.
    What we're talking about here is providing a layer of code to hide platform differences
    It is a bit more than that.
    I can run JavaScript on Java using Rhino
    Actually, you run it in the JVM. Even so, it doesn't provide any abstraction.
    All I'm saying is that you can do it without having to go to another language
    True. I said that wasn't the point of my example.
    However, I recognize that there are many advantages to doing so
    Exactly. That is what I am saying. So what is the problem? The problem is people who toss abstractions out with the bath water.
    I think you should use whatever makes you the most productive
    Yes. But sadly, most people forget about/ignore future productivity.
  26. This concept the author is referring is nothing new, It is pretty old actually is the classic server centric development as backbase or Echo framework. I agree with many comments that ZK tend to keep to close all the layers of a web system and can be a mess to maintain. I have seen some people use ZK and embed the script on the xml template is horrible and messy, to work with ZK requires best practices if not will build spaghetti code in big systems. I prefer GWT approach you can decouple easy the layers and just use Java. The RPC calls in GWT I dont see a big deal if you know your tool well you can do it pretty well with it.
  27. I miss RichFaces[ Go to top ]

    I miss RichFaces at the table. IMHO it's better than ICEFaces.
  28. Thanks for making a statement on server-side programming model in RIA-development. I totally agree that server-side programming is something that can help your development, big time. As said, one can leave client-server integration and browser differences for the framework in use. Although this isn't anything new and have been utilized by e.g. IT Mill Toolkit since 2001, and with great success. So, if you are going to make comparisons with other frameworks, try to say at least that you made comparisons with "some" frameworks that already utilize the same approach that you are. So far you have missed at least RichFaces and IT Mill Toolkit and the question remains; were these frameworks left out on purpose or by mistake. I hope the cause is either lack of time or a mistake. With Best, Ville Ingman Oy IT Mill Ltd, Finland http://www.itmill.com/itmill-toolkit/
  29. @Ville Ingman, I checked your framework and it looks pretty cool, The design its just Java Ala Swing that is impressive and is good that is reusing GWT and the best of all it use Apache2 license. I will start to play with it right away. A Book could be good for starters. Regards.
  30. @Otengi Miloskov; I'm glad to hear you got interested. And don't forget to give us some feedback at http://forum.itmill.com/ after having a deeper look ;) And yeah, a book would be nice indeed. So far you have to, besides our forum, manage with our Manual within the download-package and our community site http://dev.itmill.com/ that holds various articles etc that anyone can contribute to. But, back to the topic. Once again I feel these kind of discussions tend to be carried away from the point itself. There seems to be a trend of comparing oranges and mandarins, and here we are talking if Javascript is good for you or not. * If you want to have a cool mini application or a site-extension within your web site, then heavy Javascript is the right tool for you (or a powerful JS-framework like Dojo or GWT etc) * If you want to have cool and cinematic effects on your web-site, well, I'd skip the whole Javascript part and jump to Flex/Flash * If you want to develop something that you can imagine as a Swing application but in web, and you are going to maintain the software for years, then you definitely don't want to have any Javascript in your hands (I guess many of you would agree on this). So here is the sweetest spot for server-side programming model and probably no where else. These rule of thumbs are not the laws of physics, but help at least myself to keep on track. Occasionally. :) - Ville
  31. * If you want to develop something that you can imagine as a Swing application but in web, and you are going to maintain the software for years, then you definitely don't want to have any Javascript in your hands (I guess many of you would agree on this). So here is the sweetest spot for server-side programming model and probably no where else.
    Well, in my case, we are already maintaining a large Java web app (1.3+ million lines) with nearly 200 GWT modules. We hardly have any JS code, except for the old JSP+Struts pages, which used lots of small JS functions (it was a lower-level programming model, I guess...). So, in our case, moving from a server-side programming model to a client-side one with GWT did only bring benefits. Just ask the other developers if they would like to go back... ;) (Sure, newer tools such as ZK, Echo, etc. are better than Struts or JSF, but still, it's a flawed model.)
  32. +1
  33. Well, in my case, we are already maintaining a large Java web app (1.3+ million lines) with nearly 200 GWT modules. We hardly have any JS code, except for the old JSP+Struts pages, which used lots of small JS functions (it was a lower-level programming model, I guess...).
    @Rogerio, GWT provides a way to control UI objects in pure Java. This is its major advantage, but its programming is still primitive to me since I have to update not only the server code but also the client code if the spec is changed? The problem of maintenance headache remains.
  34. GWT provides a way to control UI objects in pure Java. This is its major advantage, but its programming is still primitive to me since I have to update not only the server code but also the client code if the spec is changed? The problem of maintenance headache remains.
    True, there are inherent difficulties associated with having a process boundary between code in the presentation/UI layer and code in the business/domain layer. However, centralizing all code in the server and therefore in a single JVM process is not the best answer to those difficulties, IMO. To me, the more primitive programming model is the one that treats the client side as a dumb terminal.
  35. To me, the more primitive programming model is the one that treats the client side as a dumb terminal.
    A server-centric approach doesn't implies this, any web browser is a very sophisticated ***visual*** terminal. A server-centric approach usually implies the browser is used for the task it was conceived: to visually render web pages and receive user input. There is no need to send business code the client (of course you can), furthermore, it becomes problematic because the data is usually very big and resides in the server, we must to send only small bits and request new data again and again with the need of data bridges and data management duplication in client and server. Security is another concern of client-centric, management and testing of big files of JavaScript code etc. Any server-centric AJAX solution uses/generates JavaScript under the hood but the main difference is this JavaScript code is managed entirely by the framework. A server-centric solution may be used to construct sophisticated DHTML applications too.
  36. A server-centric approach usually implies the browser is used for the task it was conceived: to visually render web pages and receive user input.
    Browsers may have been initially conceived with only web SITES in mind, but they evolved to better meet the needs of web APPLICATIONS, and continue to evolve in that direction - for example, Google says the focus of Chrome is in web apps, not sites. The reality is that modern web browsers are the new application platform of choice, as the popularity of business web apps shows.
    There is no need to send business code to the client (of course you can), furthermore, it becomes problematic because the data is usually very big and resides in the server, we must to send only small bits and request new data again and again with the need of data bridges and data management duplication in client and server.
    There is always some business code in the UI code, even when strict separation of layers is attempted. Otherwise, it wouldn't be possible to provide decent usability. About data transfer between client and server, in a client-centric model you only send/receive actual business/application data, not markup. And this communication tends to be in larger and less frequent chunks, as opposed to the frequent, fine-grained, chatter in a server-centric model. Consider for example a situation I recently implemented in a GWT screen, as specified in a written use case: there are two input fields (combo-boxes), and the second one must only be enabled when a certain item is selected in the first one. In GWT, this was trivial, and required no client-server roundtrip: just attach a listener to the first combo's onchange event, then enable/disable the second combo according to the currently selected item in the first one. With a server-centric framework, the onchange event would have gone to the server, along with the state of every input field on the screen.
    Security is another concern of client-centric, management and testing of big files of JavaScript code etc.
    Security is a concern with any tool, but I understand that the ease a tool like GWT provides may lead to inadvertent security holes, if developers are not careful. GWT has explicit support for JUnit client code, and there is really no need to use JavaScript directly in almost every situation (in my current project, none of the hundreds of use case implementations in GWT have a single line of JS code - only a few infrastructure classes do).
    Any server-centric AJAX solution uses/generates JavaScript under the hood but the main difference is this JavaScript code is managed entirely by the framework. A server-centric solution may be used to construct sophisticated DHTML applications too.
    Just like GWT, which also manages all the JS code produced from Java code. Extra custom JS code can be used with any of these frameworks too (or maybe not with ZK?).
  37. @Otengi Miloskov: "A Book could be good for starters" How about: http://itmill.com/documentation/itmill-toolkit-5-reference-manual/
  38. IT Mill Toolkit book[ Go to top ]

    @Otengi Miloskov (and others)
    A Book could be good for starters.
    There is a reference manual, and the plan is to publish a printed manual (I'll have to check the schedule for that, now that you reminded me...) I know it's being printed on-demand, but is not yet being distributed. The reference manual is online here: http://www.itmill.com/documentation/itmill-toolkit-5-reference-manual/ Best Regards, Marc
  39. He is also the author of an ZK book, so it might be biased:p But I really need such kind of comparisons. I used ZK in a project a year ago. The result was good though the project is small. I tried GWT last week and found their approach very different. Both are good frameworks, but no conclusion yet -- maybe after I have a chance to use GWT in a real project. I don't like JSF. It is over complicated to me.
  40. These days, it just doesn't make sense to have the UI logic of a business web application execute on the server. Consider that client machines have been quite capable for years; consider all the technical advances and innovations recently occuring in web browser technology (Firefox 3.1, Google Chrome, IE 8, etc.) ... doesn't it seem silly to simply ignore all this and continue developing web applications as if we still were under the technical constraints of the 1990's ?!? Just like running business logic in stored procedures inside the RDBMS doesn't make much sense anymore, running UI logic in the application server is outdated, IMO, now that we have tools like GWT available.
  41. These days, it just doesn't make sense to have the UI logic of a business web application execute on the server.

    Consider that client machines have been quite capable for years; consider all the technical advances and innovations recently occuring in web browser technology (Firefox 3.1, Google Chrome, IE 8, etc.) ... doesn't it seem silly to simply ignore all this and continue developing web applications as if we still were under the technical constraints of the 1990's ?!?

    Just like running business logic in stored procedures inside the RDBMS doesn't make much sense anymore, running UI logic in the application server is outdated, IMO, now that we have tools like GWT available.
    It really depends on what you are going to achieve, a project I am working on we did a mixed rendering approach some stuff was rendered on the server and then included via innerHTML and some stuff was rendered dynamically on the client. It is true, javascript engines become faster, but as long as we have to drag around absymalities like IE6 and this browser has been an absymality from day 0 in its existence. You cannot rely on proper dhtml implementations and you cannot rely on speed javascript and dom execution! Hence it really often makes sense to execute on the server. Especially as long as you have to support IE6 with its lousy dom operations performance! Just my 2c to the problem!
  42. I agree with Werner, the sad true is MSIE 6.0 holds 25% of the browser market. Furthermore, the DOM engine of v7 is basically the same as v6, same quirks, same bugs.
  43. I agree with Werner, the sad true is MSIE 6.0 holds 25% of the browser market. Furthermore, the DOM engine of v7 is basically the same as v6, same quirks, same bugs.
    This is true, however in my experience I don't find significant performance or functionality problems with IE 6.0. In fact, I still do all the development and testing on IE 6.0, in my current GWT project (and this app still uses the old GWT 1.3). For the larger screens, there IS a noticeable pause while GWT is building the UI through DOM calls, but this pause is short enough (at least, our users are not complaining ;).
  44. These days, it just doesn't make sense to have the UI logic of a business web application execute on the server.

    Consider that client machines have been quite capable for years; consider all the technical advances and innovations recently occuring in web browser technology (Firefox 3.1, Google Chrome, IE 8, etc.) ... doesn't it seem silly to simply ignore all this and continue developing web applications as if we still were under the technical constraints of the 1990's ?!?

    Just like running business logic in stored procedures inside the RDBMS doesn't make much sense anymore, running UI logic in the application server is outdated, IMO, now that we have tools like GWT available.
    When an application is distributed, rather than monolithic, there are potential problems created by the need for serialisation, the introduction of latency, limitations on bandwidth, potential for security vulnerabilities, and possibility of partial failure. Sometimes these are significant. There may not be any single partitioning scheme that is close to optimal for all systems. UI logic should run where it best serves the needs of the system. 'Outdated' is not an argument that should carry much weight.
  45. Just like running business logic in stored procedures inside the RDBMS doesn't make much sense anymore, running UI logic in the application server is outdated, IMO, now that we have tools like GWT available.


    When an application is distributed, rather than monolithic, there are potential problems created by the need for serialisation, the introduction of latency, limitations on bandwidth, potential for security vulnerabilities, and possibility of partial failure. Sometimes these are significant.

    There may not be any single partitioning scheme that is close to optimal for all systems. UI logic should run where it best serves the needs of the system. 'Outdated' is not an argument that should carry much weight.
    I agree with what you say. My point wasn't about distribution - actually, I am all for Martin Fowler's "First Law of Distributed Object Design": Don't distribute. 8^) My point is that the web browser can now be seen as the new application platform, and therefore web applications should take maximum advantage of its capabilities, instead of insisting on doing everything in the server. To me, the only true competitors are Silverlight and Flex, not server-centric frameworks like Struts, JSF, Wicket, ZK, Echo, etc. These frameworks I do indeed consider outdated, but this is only my opinion. Maybe in a few years this view will be more widespread... only time will tell.
  46. If any user in the world would be "honest" we could return to the "fat client" approach and SQL queries could live in the client too. However we live in a real world, in this real most of the application logic must be replicated in the server too because the client isn't trustworthy.
  47. I agree with what you say. My point wasn't about distribution - actually, I am all for Martin Fowler's "First Law of Distributed Object Design": Don't distribute. 8^)

    My point is that the web browser can now be seen as the new application platform, and therefore web applications should take maximum advantage of its capabilities, instead of insisting on doing everything in the server. To me, the only true competitors are Silverlight and Flex, not server-centric frameworks like Struts, JSF, Wicket, ZK, Echo, etc. These frameworks I do indeed consider outdated, but this is only my opinion. Maybe in a few years this view will be more widespread... only time will tell.
    The fact that logic now *can* run in web browsers does not imply that it *should*. I take issue with any assertion that any particular logic 'belongs' in any particular place. It belongs where it works for you. If you are using a large amount of data to create a dense user interface artifact, such as a graph or heat map, it is can be inefficient to send the raw data to the client and perform the UI logic there. Given infinite time, the optimal user experience comes from putting logic in any tier based on careful analysis of the issues related to distribution. Good engineering involves trading that off those benefits against the cost in development effort and system simplicity. The "Don't Distribute" architecture is not viable because web browsers are a bad data tier. Something server centric, like the mainframe/dumb terminal architecture, has less 'distribution' issues, than most others, so if the architectural goal is to maximise business function, while we minimise distraction, then a server centric architecture is a better choice. Partitioning what is, and what is not, 'UI logic' takes effort and judgement. This partitioning, while sometimes useful in an of itself, is typically less useful that partitioning based on business needs. Enterprise software development is immature in understanding and articulating non-functional requirements. I postulate that this is because they are less critical than functional requirements. And without understanding non functional requirements architectural choices are hard to reason about.
  48. Just what everyone knows[ Go to top ]

    I think this article just presents the problems everyone face during development of an interactive web site, with a junior team with not enough knowledge to face the project. Direct Ajax is not new. The idea to have business logic implemented in the client is the worst idea an architect could have. Those kinds of designs are always avoided. This article justs reinvents the wheel.