5 ms·

The sensible way to build more complex web apps these days is to have a (invisible) client side model, and have the controller communicate with the server as is

by dmaclay 18y ago

The sensible way to build more complex web apps these days is to have a (invisible) client side model, and have the controller communicate with the server as is required (typically to fetch data, sometimes to poll). The server becomes more of a router and data repository, with less intelligence. It is sometimes easier to think of the server as a secondary, dumb user with a huge amount of data on tap. And the more intelligence you can push out to the client side the better the system will scale.

jimbokun 18y ago
I like where you're going with that. Now we just need a catchy acronym. :) REST may be the applicable acronym for the server side (or at least, one design for implementing what you describe). But I haven't heard any design patterns with a catchy acronym for what all the cool kids are doing in the browser with Javascript. Perhaps that's for the best. Often a catchy acronym is a sign that a technology will soon either stagnate or be considered passe.
- IsaacSchlueter 18y ago
  jimbokun and dmaclay, It really depends on the application. Remember, the client is always untrustworthy. You can trust them with their data, but nothing else. In three-legged cases, like an ad or some other third-party developed app hosted in your page, you can't even trust the client-side to have unlimited access to the client's data! Plus, there are remote script hacks that potentially will compromise the user's state or other information. a catchy acronym for what all the cool kids are doing in the browser with Javascript At Yahoo, we call it Progressive Layered Enhancement. Start with working markup and server-side logic, and then enhance it in layers to add functionality for the browsers that can handle it, so that it always works, even if a layer is missing or broken. Having worked on a Microsoft stack in the past, I can say that it was nice to have a single language from end to end. It just really sucked that the language was VisualBasic. So, I get the excitement behind GWT and Pyjamas. Not that the author is wrong, I just think he doesn't really treat the material very well.
  - lkcl 18y ago
    "So, I get the excitement behind GWT and Pyjamas. " cool. very few people do! and don't forget rubyjs / rwt. "Not that the author is wrong, I just think he doesn't really treat the material very well" well, you can't have everything :)
  - jimbokun 18y ago
    "At Yahoo, we call it Progressive Layered Enhancement." PLE! We have our catchy acronym :). Good point about the security implications. That must be an integral part of any web application design methodology. For traditional kinds of desktop applications, that wasn't so much of a concern. In my day job, we have a Java back end with a lot of user interaction implemented with Javascript in the browser. Data access server side stuff actually plays to a lot of Java's strengths, I think, and the more dynamic nature of Javascript is a good fit for DOM manipulation in the browser. I'm not sure I would want to pick one of them to run both places.
    - dmaclay 18y ago
      We use Adobe Flex, and at times have the Flex app write to a HTML page in the browser (for the vastly better markup). The .swf format makes things a bit more secure, although you can decompile Flex apps. For the most part we are targeting the flash engine for performance and functionality.

by dmaclay 18y ago

jimbokun 18y ago

I like where you're going with that. Now we just need a catchy acronym. :) REST may be the applicable acronym for the server side (or at least, one design for implementing what you describe). But I haven't heard any design patterns with a catchy acronym for what all the cool kids are doing in the browser with Javascript. Perhaps that's for the best. Often a catchy acronym is a sign that a technology will soon either stagnate or be considered passe.

IsaacSchlueter 18y ago
jimbokun and dmaclay, It really depends on the application. Remember, the client is always untrustworthy. You can trust them with their data, but nothing else. In three-legged cases, like an ad or some other third-party developed app hosted in your page, you can't even trust the client-side to have unlimited access to the client's data! Plus, there are remote script hacks that potentially will compromise the user's state or other information. a catchy acronym for what all the cool kids are doing in the browser with Javascript At Yahoo, we call it Progressive Layered Enhancement. Start with working markup and server-side logic, and then enhance it in layers to add functionality for the browsers that can handle it, so that it always works, even if a layer is missing or broken. Having worked on a Microsoft stack in the past, I can say that it was nice to have a single language from end to end. It just really sucked that the language was VisualBasic. So, I get the excitement behind GWT and Pyjamas. Not that the author is wrong, I just think he doesn't really treat the material very well.
- lkcl 18y ago
  "So, I get the excitement behind GWT and Pyjamas. " cool. very few people do! and don't forget rubyjs / rwt. "Not that the author is wrong, I just think he doesn't really treat the material very well" well, you can't have everything :)
- jimbokun 18y ago
  "At Yahoo, we call it Progressive Layered Enhancement." PLE! We have our catchy acronym :). Good point about the security implications. That must be an integral part of any web application design methodology. For traditional kinds of desktop applications, that wasn't so much of a concern. In my day job, we have a Java back end with a lot of user interaction implemented with Javascript in the browser. Data access server side stuff actually plays to a lot of Java's strengths, I think, and the more dynamic nature of Javascript is a good fit for DOM manipulation in the browser. I'm not sure I would want to pick one of them to run both places.
  - dmaclay 18y ago
    We use Adobe Flex, and at times have the Flex app write to a HTML page in the browser (for the vastly better markup). The .swf format makes things a bit more secure, although you can decompile Flex apps. For the most part we are targeting the flash engine for performance and functionality.