5 ms·

Every day, I have to work with two applications developed this way, with the "Javascript UI" pattern. It's the most frustrating period of my day, bar none. Wh

Every day, I have to work with two applications developed this way, with the "Javascript UI" pattern. It's the most frustrating period of my day, bar none. When you build one of these things, you spend most of your dev time running it locally, and as a result it's snappy. You can do things like loading a blank page for your task list, then flowing in tasks via Ajax and it will render pretty much instantly. It's so fast that you'll even consider loading those tasks one at a time. For the rest of us, using an application like YouTrack or Flow (getflow.com) is sheer torture. View an item, hit the back button, wait 10 seconds for the list page to come back up, reload its content, and rebuild the page before your eyes before you can even start trying to scroll back to where you were. Compare that to the old user experience where that list page would be a chunk of HTML generated at the server in 50ms and handed to you across the wire. Your browser would cache it, so the back button operation I describe above wouldn't even involve a trip to the server most of the time. Your browser would remember its previous scroll position. It was fast and it worked. It never occurred to any of us that people would decide to throw it out and replace it with something worse. So if you're considering building one of these things, step one needs to be spinning up an EC2 box on another continent to act as your "dev" server. Latency is suddenly your number one priority in life, with your app being secondary. Please don't complain about this fact, since it's something you chose for yourself. Thanks.

prateekdayal 15y ago
I think you would never feel this with Pivotal tracker, Gmail or other well designed apps. Its easy to cache rendered htnk elements in js and show them when back button is pressed and then update them in the background (in fact this is what we do). If the initial page load is a problem, you can use a CDN to distribute the javascript files. I am not sure about the scroll problem though. Thanks for pointing it out
- jasonkester 15y ago
  Gmail seems to fix the "back" issue by going out of their way to break the "open in new window" experience. Ctrl+clicking messages to open them in new tabs takes up so much of your life waiting for them to load that you quickly become trained not to try doing that. The thing is, the more pieces of the browser that you try to replace with javascript, the more opportunities you have to get them subtly wrong. Just watch the discussion here whenever somebody submits an article using that wordpress plugin that tries to replicate an iPad's scrolling functionality inside of your iPad. It's just barely different, but that's why it's so annoying. If it were completely different, it actually wouldn't be a problem at all. But it's not. It just feels like it's not working right.
- simonw 15y ago
  Gmail's terrible performance / unresponsiveness is the bane of my working life at the moment. I'd be a lot happier if I could open real HTML pages for emails in new tabs.
  - india 15y ago
    Gmail does have a basic html view[1]. [1] https://mail.google.com/mail/?ui=html&zy=h https://mail.google.com/mail/?ui=html&zy=h
nvictor 15y ago
and it's even worse when you throw mobile into the mix.
tintin 15y ago
Totally agree! Ever tried the new Twitter? You now have to wait 12 seconds to see the Tweets. Why not load the page in 1 sec. without the use of Javascript and use Javascript for realtime updates? Because it's cool to use Javascript and make your page slow as hell? Whats wrong with page-reload-apps that are lightning fast? Maybe the hip Javascript developers don't realize a Javascript driven page needs at least 3 request (page + javascript + content) instead of 1 (page)?
- Roboprog 15y ago
  Some potential mitigating factors, if you break it up as follows: * a tiny anchor HTML page with data key info * a general purpose .js file (or small number of such) * template HTML pages * content (e.g. - JSON) The tiny "anchor" page should be small (latency still hurts, of course); The JS should be cached locally once the app has been used for the day; The HTML templates pages should also cache; The content must be loaded, suffering latency -- however, if the content is large, your app can display something while the content is being generated (perhaps by a big, slow, legacy data source???). Another consideration: if all content is delivered via a REST API as JSON or (ugh) XML, there is a better chance it will be properly encoded for display. Hopefully, I can save a nice JavaScript fragment in a submission to said site, and the AJAX page construction code will simply add it to the resulting page to be displayed, rather than to be run. Hmmmm, perhaps I want my testing fixtures to fill the test database with XSS samples while I am at it, such as the newer entries in http://ha.ckers.org/xss.html http://ha.ckers.org/xss.html (or a more recent list), and then to display that data on a few pages of manual testing.
- brunoc 15y ago
  There are ways around that. One of the easy ways is to simply in-line your JSON model when you generate the initial page. So essentially your webpage contains the html structure you need, followed by something like <script> Myapp.start( { tasks: [ { id: 1, title: 'do something' } ]) </script> So essentially you bootstrap your application in order to avoid a large AJAX call right off the bat.
  - prateekdayal 15y ago
eik3_de 15y ago
> step one needs to be spinning up an EC2 box on another continent to act as your "dev" server To reduce bandwidth and latency, I'd rather recommend using a throttling proxy such as Charles Proxy on your machine.

prateekdayal 15y ago

I think you would never feel this with Pivotal tracker, Gmail or other well designed apps. Its easy to cache rendered htnk elements in js and show them when back button is pressed and then update them in the background (in fact this is what we do). If the initial page load is a problem, you can use a CDN to distribute the javascript files. I am not sure about the scroll problem though. Thanks for pointing it out

jasonkester 15y ago
Gmail seems to fix the "back" issue by going out of their way to break the "open in new window" experience. Ctrl+clicking messages to open them in new tabs takes up so much of your life waiting for them to load that you quickly become trained not to try doing that. The thing is, the more pieces of the browser that you try to replace with javascript, the more opportunities you have to get them subtly wrong. Just watch the discussion here whenever somebody submits an article using that wordpress plugin that tries to replicate an iPad's scrolling functionality inside of your iPad. It's just barely different, but that's why it's so annoying. If it were completely different, it actually wouldn't be a problem at all. But it's not. It just feels like it's not working right.
simonw 15y ago
Gmail's terrible performance / unresponsiveness is the bane of my working life at the moment. I'd be a lot happier if I could open real HTML pages for emails in new tabs.
- india 15y ago
  Gmail does have a basic html view[1]. [1] https://mail.google.com/mail/?ui=html&zy=h https://mail.google.com/mail/?ui=html&zy=h

nvictor 15y ago

and it's even worse when you throw mobile into the mix.

tintin 15y ago

Totally agree! Ever tried the new Twitter? You now have to wait 12 seconds to see the Tweets. Why not load the page in 1 sec. without the use of Javascript and use Javascript for realtime updates? Because it's cool to use Javascript and make your page slow as hell? Whats wrong with page-reload-apps that are lightning fast? Maybe the hip Javascript developers don't realize a Javascript driven page needs at least 3 request (page + javascript + content) instead of 1 (page)?

Roboprog 15y ago
Some potential mitigating factors, if you break it up as follows: * a tiny anchor HTML page with data key info * a general purpose .js file (or small number of such) * template HTML pages * content (e.g. - JSON) The tiny "anchor" page should be small (latency still hurts, of course); The JS should be cached locally once the app has been used for the day; The HTML templates pages should also cache; The content must be loaded, suffering latency -- however, if the content is large, your app can display something while the content is being generated (perhaps by a big, slow, legacy data source???). Another consideration: if all content is delivered via a REST API as JSON or (ugh) XML, there is a better chance it will be properly encoded for display. Hopefully, I can save a nice JavaScript fragment in a submission to said site, and the AJAX page construction code will simply add it to the resulting page to be displayed, rather than to be run. Hmmmm, perhaps I want my testing fixtures to fill the test database with XSS samples while I am at it, such as the newer entries in http://ha.ckers.org/xss.html http://ha.ckers.org/xss.html (or a more recent list), and then to display that data on a few pages of manual testing.
brunoc 15y ago
There are ways around that. One of the easy ways is to simply in-line your JSON model when you generate the initial page. So essentially your webpage contains the html structure you need, followed by something like <script> Myapp.start( { tasks: [ { id: 1, title: 'do something' } ]) </script> So essentially you bootstrap your application in order to avoid a large AJAX call right off the bat.
- prateekdayal 15y ago

eik3_de 15y ago

> step one needs to be spinning up an EC2 box on another continent to act as your "dev" server To reduce bandwidth and latency, I'd rather recommend using a throttling proxy such as Charles Proxy on your machine.