4 ms·

But has it been solved if you take into account the various constraints/issues: - clients that range from tiny phone screens to full desktop screens - incompa

by mercer 9y ago

But has it been solved if you take into account the various constraints/issues: - clients that range from tiny phone screens to full desktop screens - incompatibility when it comes to what features clients support, and even how they support it - a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers) - serious limitations in payload file size for the entire UI codebase - much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'. - backend systems that are not optimized for these kinds of things I am a relatively 'young' programmer, so maybe I'm utterly wrong about thinking that, considering the above, we're in kind of uncharted territory. By all means correct me! All that said, I do get the feeling 'we' in the javascript world reinvent the wheel more than necessary. But perhaps that's because none of the historical solutions are 'complete' enough to get enough mindshare in the way that, say, Ruby On Rails was, or jQuery. Also, personally I'm becoming more convinced that until all this stabilized, many of use (or at least I personally) might benefit from just not aiming that high when it comes to UI. If I'm honest with myself, an 'old-fashioned' backend that produces HTML with perhaps a few dynamically loaded components (as just HTML fragments, even) is perfectly fine and I truly doubt it would have a negative impact. (hey carsongross, this is where you bring up intercooler.js!)

user5994461 9y ago
Have you ever done desktop UI? It does your checklist for 2 decades.
- mercer 9y ago
  I've done stuff with Delphi back in the day, but I'm not too experienced. Would you mind explaining point by point how desktop UI 'does' this? For example, I can't really think of a desktop app where most of the crucial app/UI logic is reliant on async communication with a server. Most data is stored locally and permanently. I'd actually really like to hear because I have been eying native development lately!
  - vturner 9y ago
    Young developer here too, but I started about a decade ago with robotics/desktop development. Thus, I can sympathize with the comment earlier that desktop UI has done all this: clients that range from tiny phone screens to full desktop screens -- Desktop UI could support this if developers wanted to its just resizing a window. You just don't see it because devs assume the existence of a mouse which allows easing panning in a scroll bar window. - incompatibility when it comes to what features clients support, and even how they support it - Desktop UI has or had solutions: Swing, JavaFX, QT, Adobe's Flex. - serious limitations in payload file size for the entire UI codebase: There have been desktop XML UI for so long. The oldest I can recall would be Adobe's that went along with ActionScript to build Flex apps. - much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'. -- The desktop analogy here is some long running process. Whether that is a slow disk, long computation, or some network access, desktop UI solved this a long long time ago with a rendering thread and worker threads. - backend systems that are not optimized for these kinds of things - not sure what you mean here.
    - mercer 9y ago
      I think we're talking cross purposes. I'm not saying that there we never came up with better things; far from it! Rather, disregarding how we got here, the situation we're in now provides challenges that sort of justify the complexity and confusion we're in now. Maybe this comment better expresses what I'm saying: https://news.ycombinator.com/item?id=14218425 https://news.ycombinator.com/item?id=14218425
  - pjmlp 9y ago
    I can think of native desktop applications on banks with 3 tier architecture, using DCOM and CORBA in the 90's, just as one possible example.
    - Silhouette 9y ago
      Oh, you're an evil person for bringing those up. Now I'm going to have COM and CORBA nightmares for days! It still blows my mind that we managed to write half a screenful of code, essentially just to call a function. On the bright side, I will never forget a manager of that era who was very good with buzzwords but not so good with the technologies behind them. We had some existing software built using COM, Microsoft had just announced the first version of .NET (though no-one quite knew what .NET actually meant yet) and the Internet was taking off as a mainstream technology for the general public. The manager in question would wander around the department asking us if we were using this new .COM framework to build our new software...
clarry 9y ago
https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS
ktRolster 9y ago
a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers) This is the problem, right? It's not that the other problems are unsolved, it's that we're buiding on a lousy foundation. But even that is just an annoyance, something we know how to overcome, it's not a fundamental impossibility.

by mercer 9y ago

user5994461 9y ago

Have you ever done desktop UI? It does your checklist for 2 decades.

mercer 9y ago
I've done stuff with Delphi back in the day, but I'm not too experienced. Would you mind explaining point by point how desktop UI 'does' this? For example, I can't really think of a desktop app where most of the crucial app/UI logic is reliant on async communication with a server. Most data is stored locally and permanently. I'd actually really like to hear because I have been eying native development lately!
- vturner 9y ago
  Young developer here too, but I started about a decade ago with robotics/desktop development. Thus, I can sympathize with the comment earlier that desktop UI has done all this: clients that range from tiny phone screens to full desktop screens -- Desktop UI could support this if developers wanted to its just resizing a window. You just don't see it because devs assume the existence of a mouse which allows easing panning in a scroll bar window. - incompatibility when it comes to what features clients support, and even how they support it - Desktop UI has or had solutions: Swing, JavaFX, QT, Adobe's Flex. - serious limitations in payload file size for the entire UI codebase: There have been desktop XML UI for so long. The oldest I can recall would be Adobe's that went along with ActionScript to build Flex apps. - much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'. -- The desktop analogy here is some long running process. Whether that is a slow disk, long computation, or some network access, desktop UI solved this a long long time ago with a rendering thread and worker threads. - backend systems that are not optimized for these kinds of things - not sure what you mean here.
  - mercer 9y ago
    I think we're talking cross purposes. I'm not saying that there we never came up with better things; far from it! Rather, disregarding how we got here, the situation we're in now provides challenges that sort of justify the complexity and confusion we're in now. Maybe this comment better expresses what I'm saying: https://news.ycombinator.com/item?id=14218425 https://news.ycombinator.com/item?id=14218425
- pjmlp 9y ago
  I can think of native desktop applications on banks with 3 tier architecture, using DCOM and CORBA in the 90's, just as one possible example.
  - Silhouette 9y ago
    Oh, you're an evil person for bringing those up. Now I'm going to have COM and CORBA nightmares for days! It still blows my mind that we managed to write half a screenful of code, essentially just to call a function. On the bright side, I will never forget a manager of that era who was very good with buzzwords but not so good with the technologies behind them. We had some existing software built using COM, Microsoft had just announced the first version of .NET (though no-one quite knew what .NET actually meant yet) and the Internet was taking off as a mainstream technology for the general public. The manager in question would wander around the department asking us if we were using this new .COM framework to build our new software...

clarry 9y ago

https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS

ktRolster 9y ago

a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers) This is the problem, right? It's not that the other problems are unsolved, it's that we're buiding on a lousy foundation. But even that is just an annoyance, something we know how to overcome, it's not a fundamental impossibility.