On Friday, 6 March 2015 at 11:34:15 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 6 March 2015 at 10:55:34 UTC, ketmar wrote:
>> wow, what a shitload of crap! exactly what i mean when i wrote "most
>> people doing it wrong".
>
> Describe what is right?
>
> To most developers, doing it right means saving developer time and if possible push "design declarative programming" onto designers.
>
> Which is basically what shadow-dom allows you to do. There are some quirks with styling still, but there is overall progress.

I've been working with various GUIs (Swing, Cocoa, JavaFX, SWT, GTKD, TKinter etc.) and I am working with HTML/CSS/JS (have to!). Frankly speaking, I hate JS and wish there was a way to get rid of it (please, don't try to convince me that JS is somehow good - it isn't - and that there is jquery and blah dee blah. Please don't.).
What I can tell from my own personal experience is that in _theory_ something like HTML5 would be very nice, due to the fact that it is supported, maintained and improved on all platforms (manpower & brainpower), so that you come pretty close to the "write once, run everywhere" ideal. Given the plethora of platforms nowadays, especially in the mobile sector, it is impossible to develop a GUI application for each platform. What you want is something based on browser technology that is understood everywhere, without having to worry about any platform specific quirks or pitfalls. Something that is only a thin layer that is agnostic to the logic, the data processing that goes on in the app. Unfortunately, the only way to do this today is HTML5+JS (it's the JS bit that annoys me).

In the old days (before smartphones), people would develop applications for Windows, OS X, and maybe Linux (if it was in the budget). But today this is simply impossible. So yes, from a developer's point of view, you want something like HTML5/CSS/JS, only better, regardless of what's the GUI ideal. Using technologies (other than HTML5) that interface to native widgets, is not maintainable, you're always one step behind.

To cut a long story short, ideals and pragmatism are at loggerheads here, but at the end of the day, you have to get your apps out there for as many people and as many platforms as possible, with the least effort possible. So HTML5 and related technologies win in this respect. And users don't care what's under the hood. They simply ask "Can I download an app?". If they can't, they are very annoyed. D should find a way to interact with the "app world".

On Friday, 6 March 2015 at 11:30:58 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 6 March 2015 at 10:42:37 UTC, Russel Winder wrote:
>> On Fri, 2015-03-06 at 10:01 +0000, via Digitalmars-d wrote:
>>> 
>> […]
>>> Components are coming to HTML5:
>>> 
>>> […]
>>> 
>>> It could work out nicely.
>>> 
>>
>> On the other hand for a non-browser UI, it doesn't really make sense!
>
> Not sure what you mean by a "non-browser UI". You need a model, a layout engine, a composition engine and know-how. Competing with browser engines is a lot of work.
>
> It is going to be very hard to compete with reusable UI components implemented in html+javascript, when they have worked out the quirks, due to:
>
> 1. ease of development
> 2. ease of modification
> 3. volume of UI components
> 4. styling know-how
> 5. integration
> 6. installed base
>
> What you need is a reactive layer that access native data. And webtech provides the basic building blocks for it, thanks to the requirements of asm.js/pnacl.

I am hoping mobile applications and application stores bring an end to the non-sense of bending documents into applications.

Or that we get to have the second comeback of XHTML, and finally have something like XAML on the browser, which was XHTML original idea.

--
Paulo

On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:
> To cut a long story short, ideals and pragmatism are at loggerheads here, but at the end of the day, you have to get your apps out there for as many people and as many platforms as possible, with the least effort possible. So HTML5 and related technologies win in this respect.

A web UI like that of fossil? Fossil doesn't use JS in its UI.

On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:
> Or that we get to have the second comeback of XHTML, and finally have something like XAML on the browser, which was XHTML original idea.

There's already XUL, I use it, a small program eats ~100MB of RAM.

On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:
> I am hoping mobile applications and application stores bring an end to the non-sense of bending documents into applications.

Yes, the model-view separation could be better for large datasets ( > 5000 items), but you can do it just fine now that hardware/engines are fast enough (by absolute positioning relative to the list view). Once most platforms are fast enough you can get good updates/framerates even if HTML5 is somewhat inefficient for some display strategies. The good thing is that we are really close to that threshold now, and that better refresh rates than 60hz makes no sense.

> Or that we get to have the second comeback of XHTML, and finally have something like XAML on the browser, which was XHTML original idea.

I think HTML5 brings very nice semantics to document markup, so you can use XHTML5 if you want. And Shadow-DOM/Polymer with two-way binding (variables and UI-elements are automatically updated when one change) is more like an extensible display-graph than a document, but you can also turn XML-ish/JSON-ish data into a pre-filled form to have a custom editor in a document like fashion.

Quite a few quirks and some boilerplate at the moment, but one can play with it already. I am testing Dart+Polymer+Paper Elements for an Chrome based admin interface right now. I think it is moving in the right direction, although at bit "complicated" without tooling.

When the quirks are ironed out, the tooling certainly will come... Overall, I think it will be easier to use than Cocoa et al, with roughly the same capability, but a lot more ready made components. If Google keeps investing in the tech... The only problem would be that it might be too complicated for avarage web devs without tooling, and that the tooling-devs wait for avarage web devs to pick it up. Catch 22.

On Fri, 06 Mar 2015 12:29:45 +0000, Chris wrote:

> To cut a long story short, ideals and pragmatism are at loggerheads here, but at the end of the day, you have to get your apps out there for as many people and as many platforms as possible, with the least effort possible. So HTML5 and related technologies win in this respect. And users don't care what's under the hood. They simply ask "Can I download an app?". If they can't, they are very annoyed. D should find a way to interact with the "app world".

that's exactly what Component Framework can provide: solid foundation to build upon. clear separation of data and UI and software as components which can interoperate seamlessly. there is no such thing as "application package" in CF, there is only "CF extension package". add "everything is a document" here, and you will have a killer.

the worst thing of current software is that it's bundled in form of "applications". and then people try to glue that "applications" together, and... and the whole thing is a mess.

people with virtual machines was almost there... almost. it seems that they were too scared with the idea, and choose to go "traditional" way. sure, you can't sell the thing that can't build "standalone applications" (technically, CF can, but they sux). apple tried that with OpenDoc and failed. microsoft tried that with COM and failed.

but that doesn't mean that the idea is wrong, it's just bussines is not ready to bundle "extensions" instead of "applications". especially when your extension can be freely used by any other extension. so we have what we have.

On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:
> to!). Frankly speaking, I hate JS and wish there was a way to get rid of it (please, don't try to convince me that JS is somehow good - it isn't - and that there is jquery and blah dee blah. Please don't.).

It isn't good, but once you figured out what to avoid, you can use a subset of it pretty well. Like C++ and D ;^)

It feels weird to type "Object.create(null)" to get a dictionary-like object, but it will probably be fixed in ECMAScript 6?

> worry about any platform specific quirks or pitfalls. Something that is only a thin layer that is agnostic to the logic, the data processing that goes on in the app. Unfortunately, the only way to do this today is HTML5+JS (it's the JS bit that annoys me).

Yeah, but I think if you only do the GUI (the View part of MVC) in JS using shadow dom it should be quite ok. And nothing should prevent one from generating the JS bindings from D to JS/HTML5 from D code.

> Using technologies (other than HTML5) that interface to native widgets, is not maintainable, you're always one step behind.

I agree. The alternative is to develop only for a few markets (e.g. iOS/Cocoa). People are also quite used to the common UI paradigms used on the web by now, so "learnability" is not the same as in the 80s/90s where regular users would be terribly confused when encountering innovative UI components. Text books on usability probably lags a bit behind there...

Qt et al might work in markets where there is little competition (low volume narrow markets), but I have trouble seeing a future for it without a major player backing it 100% to gain market share.

I believe Google depends on HTML5 domination to keep Apple/Microsoft from getting "too big".

> technologies win in this respect. And users don't care what's under the hood. They simply ask "Can I download an app?". If they can't, they are very annoyed.

Yep, and businesses ask for features they wanted last week. So time to market matters ("can you deliver this new feature within 2-4 weeks?").

On Friday, 6 March 2015 at 12:49:11 UTC, Kagamin wrote:
> On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:
>> Or that we get to have the second comeback of XHTML, and finally have something like XAML on the browser, which was XHTML original idea.
>
> There's already XUL, I use it, a small program eats ~100MB of RAM.

I never cared about XUL, as it always meant bundling together with a browser.

..
Paulo

On Friday, 6 March 2015 at 13:02:05 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:
>> I am hoping mobile applications and application stores bring an end to the non-sense of bending documents into applications.
>
> Yes, the model-view separation could be better for large datasets ( > 5000 items), but you can do it just fine now that hardware/engines are fast enough (by absolute positioning relative to the list view). Once most platforms are fast enough you can get good updates/framerates even if HTML5 is somewhat inefficient for some display strategies. The good thing is that we are really close to that threshold now, and that better refresh rates than 60hz makes no sense.
>
>> Or that we get to have the second comeback of XHTML, and finally have something like XAML on the browser, which was XHTML original idea.
>
> I think HTML5 brings very nice semantics to document markup, so you can use XHTML5 if you want. And Shadow-DOM/Polymer with two-way binding (variables and UI-elements are automatically updated when one change) is more like an extensible display-graph than a document, but you can also turn XML-ish/JSON-ish data into a pre-filled form to have a custom editor in a document like fashion.
>
> Quite a few quirks and some boilerplate at the moment, but one can play with it already. I am testing Dart+Polymer+Paper Elements for an Chrome based admin interface right now. I think it is moving in the right direction, although at bit "complicated" without tooling.
>
> When the quirks are ironed out, the tooling certainly will come... Overall, I think it will be easier to use than Cocoa et al, with roughly the same capability, but a lot more ready made components. If Google keeps investing in the tech... The only problem would be that it might be too complicated for avarage web devs without tooling, and that the tooling-devs wait for avarage web devs to pick it up. Catch 22.


I am doing web development alongside native since the .com days, those quirks will never go away as long as the trend of building hack on top of hack continues.

--
Paulo

On Friday, 6 March 2015 at 13:22:47 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:
>> to!). Frankly speaking, I hate JS and wish there was a way to get rid of it (please, don't try to convince me that JS is somehow good - it isn't - and that there is jquery and blah dee blah. Please don't.).
>
> It isn't good, but once you figured out what to avoid, you can use a subset of it pretty well. Like C++ and D ;^)
>
> It feels weird to type "Object.create(null)" to get a dictionary-like object, but it will probably be fixed in ECMAScript 6?
>
>> worry about any platform specific quirks or pitfalls. Something that is only a thin layer that is agnostic to the logic, the data processing that goes on in the app. Unfortunately, the only way to do this today is HTML5+JS (it's the JS bit that annoys me).
>
> Yeah, but I think if you only do the GUI (the View part of MVC) in JS using shadow dom it should be quite ok. And nothing should prevent one from generating the JS bindings from D to JS/HTML5 from D code.
>
>> Using technologies (other than HTML5) that interface to native widgets, is not maintainable, you're always one step behind.
>
> I agree. The alternative is to develop only for a few markets (e.g. iOS/Cocoa). People are also quite used to the common UI paradigms used on the web by now, so "learnability" is not the same as in the 80s/90s where regular users would be terribly confused when encountering innovative UI components. Text books on usability probably lags a bit behind there...

Except the browser only offers a 80s/90s view of the desktop.

No way of providing an immersive experience with all the UI features the native platforms expose to their applications.

I lost count how many times I had to explain that the feature X, that the customers like so much in a given native application, is not possible in their new web based UI.

Last one was an upload progress bar with status with amount of uploaded data for files dragged into the browser, working the same way across all required browsers.

>
> Qt et al might work in markets where there is little competition (low volume narrow markets), but I have trouble seeing a future for it without a major player backing it 100% to gain market share.
>
> I believe Google depends on HTML5 domination to keep Apple/Microsoft from getting "too big".

They have Android for that.

ChromeOS might sell well in Amazon US, but I never saw one in my travels around Europe, except for the ones at German Saturn shops bundled with every type of promotion to try to get them out of the shop, with decreasing prices every time I come by.

--
Paulo