Page 1 of 1

Is HTML5 really the future proof way?

Posted: Sun Jun 14, 2015 5:32 pm
by yoxola
Almost every developer heard of interested about HTML5 development nowadays, I'm not the one jumping into the boat early, after toying it for months I have some concerns, if you have more experience please share the thoughts if possible.

The issues:
1. It's still a evolving standard even W3C announced it's hitting the milestone, people still try improving HTML5 here and there, thinks working today may be deprecated later if you can't follow it quickly.

2.HTML5 is actually a superset of most known web technologies, you can't just learn so much things easily especially if you want to touch the backend (database, server etc), and it highly depends on many 3rd party libs so if something worng in the core it's pretty hard to find.

3.It's interpreted by design, and highly depends on developers' skill to optimize/tweak the code, bad practice make the HTML5 page a resource hog or malfunction on defferent devices.

4.Limited multimedia format support, maybe I'm the only one want to use MOD/XM music on browser, but in the good-old-days I can just import a lib and use it (there's a MOD music lib in JS but not optimized yet).

The benefit:

1.Cross device, but not fully guaranteed tho, at least a possible replacement for Flash.

2.Embeddable design if you use chromium runtime, not tightly integrated into system (like .net) make HTML5 a safe option to deploy your program, however the current runtime is very big(~60MB) tho.

3.Make modern and cool UI easier that before as there're many existing JS examples inherited since early web age.

4. At least many developers are improving it, just hoping it'll get better...

Re: Is HTML5 really the future proof way?

Posted: Mon Jun 15, 2015 8:16 am
by the.weavster
yoxola wrote:3.It's interpreted by design, and highly depends on developers' skill to optimize/tweak the code, bad practice make the HTML5 page a resource hog or malfunction on defferent devices.
Firefox has two JIT compilers for regular JavaScript: Baseline and IonMonkey. You can read more here. Mozilla also have OdinMonkey for asm.js.
Google's V8 also contains a JavaScript compiler.

Probably the biggest mistake you can make to slow down your JavaScript code is to change the data type of a variable. SpiderBasic could be a big help in that regard.

Re: Is HTML5 really the future proof way?

Posted: Mon Jun 22, 2015 10:45 am
by HanPBF
I would distinct HTML5 in the areas GUI and access-desktop-like-things (e. g. file system and database access).

Regarding the GUI, a declarative model like HTML possible to change with a DOM/JS imperative code is the "standard" today.
Styling is done with CSS; also declarative. (Or, see XAML, etc.)

Many tools advertise with native development for the mobile devices (Xamarin, Embarcadero, Xojo).
I don't know how big the gap is between native and HTML5 at those devices.

For the desktop, I liked the HTA idea from Microsoft. Easy to understand and works.
XUL runner is a "read-some-hundreds-documents" beast and maybe You get it to run.

I am currently awaiting TideKit to come up and fill the gaps between web and desktop development.

The reason why rich clients are not as good as they could be is, that the big players like google, etc. don't want to give there technology away -> they want You to put Your data into the cloud (== there servers!).
The chrome browser is fantastic for using as GUI (s. node-webkit), but is often blocked from enterprise development like opera is.

So, in short I think
- declarative GUI (s. also Dialog lib of PB) is standard
- rich JS based clients are not so easy to use due to many exceptions in what they can do

Re: Is HTML5 really the future proof way?

Posted: Tue Aug 04, 2015 8:01 am
by HanPBF
TideKit stopped their project some weeks ago.

Maybe PB5.40 will have a webgadget that better communicate with PB.

So, instead of using Node.js+WebKit (=nw.js) we could use PB with webgadget.

Re: Is HTML5 really the future proof way?

Posted: Tue Aug 04, 2015 9:44 pm
by tj1010
It is future proof.. WebSockets, Canvas, and Video and Audio. They can improve codec support over time but they have some good ones picked now.

You can pretty much do anything you can imagine right now without frameworks. I use jQuery and HTML5 for everything now, SVG or Google Charts for things too.

EDIT: Support for new CPU instruction acceleration too internally. SkyLake has some nice ones coming starting 11/17

Re: Is HTML5 really the future proof way?

Posted: Fri Aug 07, 2015 8:56 pm
by HanPBF
see also Microsoft universal apps...

slow? JS is half as fast as C using asmjs and bytearray and some typing.

It can be used for the interface programming on nearly every device.
PB is good for fast calculations or native access to operating system things.
Of course, iOS and android want there system work best with native approach; but phonegap develops forward.

yes, PB would be much faster when You need a really fast surface (see RiscOS on Rasperry as an example for that kind of speed...).
But at what big effort? ProGUI???
More updates to PB language itself, less work on the libraries; they are good as they are.
Or using free available libraries and bind them up native in PB; that's a good way to go / keep goin'.

Re: Is HTML5 really the future proof way?

Posted: Sat Aug 08, 2015 1:50 am
by Deluxe0321
HTML is perfect to have a fluid, easy customizable user interface without to much work *if* combined with convenient "native ui" aspects..

example**: HERE ( fully written in PB )
** a combination of a canvas, webgadget and scintilla ( most standard/native PB code, except reading zip files ).

Thank you,
Deluxe

Re: Is HTML5 really the future proof way?

Posted: Sat Aug 08, 2015 10:00 am
by HanPBF
Very nice UI, indeed!

How does webgadget (JS) communicate with PB native parts?

Re: Is HTML5 really the future proof way?

Posted: Mon Aug 10, 2015 3:43 pm
by tj1010
Alexi wrote:
tj1010 wrote:You can pretty much do anything you can imagine right now without frameworks
tj1010 wrote:I use jQuery and HTML5 for everything now...
:D

Well, performance is still really bad. And realtime stuff like games (especially 3D) based on javascript seems to stay bad at performance even for the next years. But it's really nice for interactive applications, or less process power demanding games.

I use jQuery for less code and I don't have to worry about IE differences.

The only people doing 3D stuff outside of demoscene are large teams; at least, 3D stuff that isn't vaporware. Video people and web devs are unaffected by lack of canvas and thread optimizations which are mostly the result of browser overhead anyway.