Re: and things are now moving towards the simplicity of how it used to be when creating desktop apps using web tech with the advantage that they're cross platform.
I suspect we'll need a new web standard that's GUI-friendly. For one, have the option of sending raw coordinates to the browser and have the (optional) layout/flow engine be on the server. That way you only have ONE layout engine instead of a different one for each browser version/brand, which is what we are really dealing with.
A. app -> server layout engine -> coordinates -> client -> screen
B. app -> markup/JS -> client -> DOM -> coordinates -> Screen
The problem with "B" is that each DOM is slightly different: different browser brands and versions. You have to test with about 50 variations to be sufficiently thorough. And as time goes on, they break more code. A more accurate diagram would fan out after "client" and have DOM1, DOM2, DOM3, DOM4, etc. Since the browser is dealing with raw coordinates in A, there fewer things to go wrong. Thin client = thin errors.
Another advantage of A is that you can choose different layout engines not bound to DOM standards and quirks. Or even have none and go WYSIWYG. (Web browsers don't really do WYSIWYG well in practice, partly because font-to-widget-size-ratios are not standardized.)
"A" is more stable. It's better factoring, period.
I suspect we'll need a new web standard that's GUI-friendly. For one, have the option of sending raw coordinates to the browser and have the (optional) layout/flow engine be on the server. That way you only have ONE layout engine instead of a different one for each browser version/brand, which is what we are really dealing with.
The problem with "B" is that each DOM is slightly different: different browser brands and versions. You have to test with about 50 variations to be sufficiently thorough. And as time goes on, they break more code. A more accurate diagram would fan out after "client" and have DOM1, DOM2, DOM3, DOM4, etc. Since the browser is dealing with raw coordinates in A, there fewer things to go wrong. Thin client = thin errors.Another advantage of A is that you can choose different layout engines not bound to DOM standards and quirks. Or even have none and go WYSIWYG. (Web browsers don't really do WYSIWYG well in practice, partly because font-to-widget-size-ratios are not standardized.)
"A" is more stable. It's better factoring, period.