3 ms·

I agree with the central thrust of what you're saying here; its definitely easier now than it has ever been, and things are now moving towards the simplicity of

by arc619 7y ago

I agree with the central thrust of what you're saying here; its definitely easier now than it has ever been, 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. However this improvement is in spite of using a tool designed for a different medium, rather than because of it, and the years and abstractions its taken to get here express this. Having said that, cross platform is better going from web to desktop than the other way round.

tabtab 7y ago
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.

by arc619 7y ago

tabtab 7y ago

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.