[DUG] Auckland Event Details

Mon May 5 19:53:17 NZST 2014

Hi,

I agree that this is certainly the risk. However the converse direction, largely abandoning their current customer base while striking out in hopes of finding a new customer base would be a massive risk. Microsoft got away with eventually when they dropped VB6 and replaced it with VB.NET but I believe they only managed this because VB6 was such rubbish (it wasn’t really an OO language) and they are Microsoft, they controlled the OS, the mindshare and didn’t need to make one cent out of development tools. Even then it was still a major s***storm for a while with their VB6 customer base complaining loudly about the world ending and being stabbed by Microsoft.

Personally I see some appeal in Embarcadero’s approach for new customers, although I’m not one myself so my view might be skewed. The ability to develop one GUI and have it translate passably well (albeit not perfectly) across multiple platforms is bound to be attractive to some (it is to me). For some software the ability to run un-interpreted code is also a significant plus. Delphi is also pretty efficient, time-wise, to develop in and is also well proven in enterprise situations compared to some recent cross platform software (Elements included – it’s might be great but it is a fairly new product). Of course FireMonkey itself isn’t well proven in enterprise situations so Embarcadero face a challenge there.

The very fact that Embarcadero have done the hard yards to get Delphi cross compiling to these other platforms tells me that for now at least Delphi is not a PowerBuilder like product. In fact I feel much happier today that we’re not locked into a dead end with Delphi than I was pre FireMonkey. I just hope they keep improving everything so the IDE, language and our apps keep getting better and also so that when we finally decide we want to produce some FireMonkey apps ourselves it is fully ready for primetime (as a corollary it is worth pointing out I’m sure I would be much less sanguine about FireMonkey if we had jumped head first into developing in it when it was first released! ;-).

Cheers,

David.

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith
Sent: Monday, 5 May 2014 6:29 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Auckland Event Details

The danger of following that line of thought is that your customers are only ever your existing customers, unless you are also offering something to attract new customers, that pool simply keeps dwindling.

FireMonkey has little/no appeal to new customers for all the reasons that it is so appealing to the legacy base, but even for the legacy base it's greatest strength - the ability to keep using your legacy code - is also it's greatest weakness.

With FireMonkey Delphi has become the new PowerBuilder (or whatever legacy development environment you prefer, that is today surviving but hardly thriving).  I am sure all the current PowerBuilder users out there are very grateful that it was kept so easy for them to remain locked in to their product as well.  ;)

On 5 May 2014 17:53, David Brennan <dugdavid at dbsolutions.co.nz> wrote:

Hi Jolyon,

If our current application suite was written in Elements instead of Delphi then you are quite correct, I wouldn’t see them any differently. I suspect (without knowing many details about it) that I would be quite happy with Elements – I might not be madly impressed at being forced to develop different GUIs for each platform but it looks like there are probably other benefits which would counter my annoyance at that.

The whole point is that our current application suite is NOT written in Elements. It is written in Delphi with a big VCL front end. The same presumably goes for the majority of Embarcadero’s customer base. The decision Embarcadero made on HOW to embrace cross platform needs to be evaluated in that context. 

You seem keen to keep evaluating Embarcadero’s decisions in the context of purely what is the best resulting development environment. That is a very interesting conversation to have (and I genuinely have been finding it interesting reading your posts on Elements) but in a vacuum like that it is only partially relevant to the actual real world decision Embarcadero faced. IMO.

Regards,

David.

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith
Sent: Monday, 5 May 2014 5:42 p.m.

To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Auckland Event Details

@David:

Then I'm not sure how you see the elements approach as significantly different, other than in the degree of effort required to create the portable object library.

Platform dependence arises in Elements in only two ways:

1) You write code that is dependent upon some platform specific language feature or framework

2) You compile the code

Other than that, your code is portable to any platform supported by the compiler(s).

By it's nature, any GUI code is platform specific, so all the GUI work is caught by #1

But the upside of that is that your GUI code is platform specific, not lowest common denominator (and you are encouraged - dare I say forced - to develop your applications the way we always should - with the GUI at arms length from the functional code).

FireMonkey scores big Brownie points because it allows you to keep all your business code locked up in the GUI where many people habitually find themselves plumping it thanks to the RAD philosophy of the past (which the VCL facilitates and never really grew out of).  Such implementations will be attracted by the ability to simply "migrate to FireMonkey"and not have to think about how to develop properly for the new platforms.

But back to Elements.... I think the fact that the technology is so successful at embracing the different platforms causes some people to think that Elements code is only ever Java code, or Cocoa code or .NET code, and ne'er the 
twain shall meet.

This isn't so.

When you write portable code, then it is mapped to platform specifics only at compile time.

Both of these declarations are legal Oxygene code:

  customers: array[0..10] of Customer;
  customers: ^NSArray;

The first is platform agnostic and as long as you work with that array also using portable code, then that code will compile for Cocoa, Java or .NET equally well.  The second is obviously tied - declaratively - to Cocoa.

I think perhaps some blogging on more examples in this area is called for.  :)

On 5 May 2014 17:18, David Brennan <dugdavid at dbsolutions.co.nz> wrote:

Hi Jolyon,

What I said was: “Any solution needs to provide either a near perfect one way migration path or long-term single sourcing between VCL apps and the new platforms.”

Embarcadero’s current approach is the latter route. I can use exactly the same source code between VCL and Firemonkey apps. The GUI layer certainly needs to be different but I regard this as an unfortunate inevitability whichever route Embarcadero went (as I said in my original reply, the only alternative would be to update VCL to seamlessly cross compile onto other platforms which everyone seems to have agreed was just too hard).

You are correct that I haven’t tried to migrate any of our current applications to Firemonkey and I have spent a relatively small amount of time developing test apps in it. However large parts of our code, including the most important and complex parts, can be compiled without VCL forms and are used without the GUI in several different DLL styles (eg ISAPI, COM DLLs, etc). There would of course still be plenty of work to be done in incorporating this code into a Firemonkey app (new GUI, GUI links to our business objects, mobile compatible data layer) but our core logic should in theory be fine. The only hiccup I can see is the new object reference counting used on the mobile platforms which may require some tweaking of how we handle lifetimes of some objects to make sure they get freed properly when desired. 

Even if some effort is required the key point is that after we have performed this effort our core logic can be compiled to all platforms (including Windows). That is my main goal out of any cross platform solution and anything which does not deliver this automatically fails.

I do agree that lack of support for Windows Apps may become a concern. Last I heard Microsoft were deliberately locking out native solutions which don’t use their exception handler. However this is only a real problem for us if Windows RT takes off and currently it seems to be doing the opposite. 

Regards,

David.

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith
Sent: Monday, 5 May 2014 4:27 p.m.

To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Auckland Event Details

@David:  What you say they shouldn't do (treat Delphi+VCL as legacy) is exactly what they are doing, they just haven't come out and said as much.

Consider that their Windows 8 support consists of little more than GUI styling.  FireMonkey does not work very well (in terms of making sense) in this space and you might argue that this is OK because Windows won't be as relevant in the mobile space (many would disagree) where FireMonkey is more firmly planted.  But for the VCL to be struggling to remain current on the desktop, should be a source of concern.

The best you can do with either approach is create something that looks the part but which doesn't stack up once you peel back the GUI paint job.

So, that being the case, if FireMonkey is the "future"of Delphi on future relevant platforms, where does that leave the VCL and longer term support for the Windows desktop ?  Which, growth of other platforms notwithstanding, will remain very relevant for a long time to come.

>From what you say I get the impression that you haven't yet actually tried to migrate any code to the FireMonkey world.

Unless your legacy code was implemented in a fortuitously forward-thinking manner, I suspect that a great deal of what you think might/should be portable in your VCL code in particular may well turn out to depend on things that aren't available to you in FireMonkey, or certainly not in a way that you will be able to seamlessly and effortlessly migrate to.

@Xander:

Cost is one reason to discount Xamarin.  Elements cost me US$699 - that's both Oxygene (ObjectPascal) and Hydrogene (C#) for .NET, Java and Cocoa.

Why would I need both languages ?

Well, I intend to learn C#, but I have shorter term project goals where being able to leverage my productivity in ObjectPascal will be useful.  With Elements I can mix and match as I develop my C# skills.  Because there are no framework/runtime "walled gardens" in the way, work done in one is directly usable in/with the other and - indeed - in the platform native development environments to boot.

i.e. if it is easier to create a "Cocoa encapsulation"of some C API using C# than to do so in ObjectPascal, then I can do so, but then I can use the classes thus created directly on the ObjectPascal side, if I prefer to use that for (e.g.) some GUI app that consumes that API.

And I can publish my encapsulation and Objective-C developers can use it in their Xcode solutions.

The same applies in the Java space.  Also, in that case, I prefer Visual Studio to Eclipse or any of the other Java development environments (plus Java is even worse than C# as a squirrely brackets language).

Which is another point worth mentioning.... RemObjects implementation of ObjectPascal and - to a lesser extent - C# improve significantly on Java, C# and Objective-C in key areas, without losing compatibility at the code-gen level.

@Leigh - why not use Java ?

I think my answers above should explain why I prefer not to use Java.  :)

For context:

I currently do most iOS / OS X development in Xcode and Objective-C.

I use Oxygene for Java (Android) being careful where possible to create relevant code in my Android projects in a portable, platform independent form with a view to re-using it in future Xcode/Oxygene/Hydrogene projects.

I anticipate using Hydrogene and/or Oxygene for .NET

On 5 May 2014 15:50, David Brennan <dugdavid at dbsolutions.co.nz> wrote:

Thanks for the reply. 

The single source requirement was based on my own requirements but I strongly suspect I’m not alone in this. We have a million odd lines of code and having to maintain two versions of that code to support iOS/Android would automatically rule any solution out for us. 

Maintaining two versions of the GUI is also annoying but marginally more palatable because a decent case can be made that the GUI requirements between the different formats are sufficiently different to mandate making new form designs anyway. Even so, I would still strongly prefer that being my choice rather than foisted on me, and I would also prefer to be able to use our current components on the new GUI (in our case primarily DevExpress VCL). However I accept that it was close to impossible to port VCL to the mobile platforms so a new GUI layer was inevitable.

Looking at overall approaches (and ignoring you specific recommendation with Prism) I believe there are two aspects to what you are saying Embarcadero should have done:

1.       Their GUI layer should be platform specific. Thus one would need to develop a new version of a form for each target platform. I can see the arguments both ways on this and suspect it comes down to how much effort a developer wants to spend on each platform. For the foreseeable future any iOS/Android apps we release are unlikely to be our core business so from my point of view I prefer being able to develop a single tablet size version of each form, add a few platform specific runtime customisations to the layout and release to all platforms. But I recognise others may prefer the other route. 

2.       Their language should cross compile into the most common environment of each platform. That means Java for Android, Cocoa for OSX/iOS, .NET/Win32/Win64 for Windows. That is a pretty impressive trick and I am indeed impressed that RemObjects have managed to pull it off. The question is whether Embarcadero could have achieved something similar while maintaining single source backward compatibility for their existing customer base. We would still need to be able to compile our current applications for Windows with minimal changes. This means VCL still needs to compile too, as do applications which directly access Windows APIs etc (although obviously it would be acceptable to need to replace both VCL and Windows API calls before single sourcing to another platform). I think it might have been possible but Embarcadero decided to go the native instructions way instead.

Back to your specific suggestion, you say that Embarcadero should have made Delphi + VCL a legacy solution and made Prism the new solution. In order for this to work IMO either Embarcadero would need to provide a robust tool to convert VCL projects to Prism projects OR you would need to be able to single source code between Delphi and Prism. Otherwise the migration hurdle is just too large – a development house would need to move ALL their code and rebuild ALL their GUI in Prism at once to make the switch, small steps over time would be impossible. Embarcadero would also have come under a lot of pressure to enhance Prism so you could compile directly to Win32/Win64, otherwise a portion of their customer base who demand to the metal code in Windows would not make the switch.

This is all in my opinion, but it is in my opinion as the owner of a Delphi software development house. Hence I think my situation is relevant. You blithely say ‘simple’ leave Delphi + VCL as their Win32 solution with Prism/Elements as the new platform. But I don’t think it is ‘simple’, as I explained in the previous paragraph. Any solution needs to provide either a near perfect one way migration path or long-term single sourcing between VCL apps and the new the platforms. 

In that context I can see why Embarcadero have gone the way they have and it seems reasonable to me. My only beef with it is whether the implementation they chose (Firemonkey) was the right one – I think they needed to be much more ambitious with their initial design of Firemonkey, do everything properly to make it a really top class component suite, and then spend three years carefully developing it before releasing it. Instead they purchased it then rushed it out the door, and have been spending a lot of time since then trying to fix design flaws, something which is much harder to do once it is already in use and backward compatibility is an issue.

Regards,

David.

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith

Sent: Monday, 5 May 2014 2:41 p.m.

To: russell at belding.co.nz; NZ Borland Developers Group - Delphi List

Subject: Re: [DUG] Auckland Event Details

@David:

Your prescription that the approach must support single source is arbitrary.  Heck, not even Embarcadero achieved this goal completely satisfactorily, so by that criteria FireMonkey itself is a failure.

RemObjects approach is the more robust one.

Rather than trying to pretend that platform differences can be abstracted away or reduced to lowest common denominator (as if the various user communities of the various platforms were not themselves making their choices precisely because of those differences, in many cases), those differences should be embraced and the developers empowered to take full advantage of them in order to provide the best solutions possible for each platform, not limited to providing a solution that can be deployed on all platforms.

What should Embarcadero have done ?

Simple.  Instead of tossing Prism into the long grass, they should have brought Elements into the fold.  Kept Delphi + VCL as their Win32 solution with Elements as their .NET and mobile platforms offering.

But, frankly, as an Elements user who has previously experienced Borland/Inprise/Codegear/Embarcadero's product management, development, marketing and pricing at first hand, I am actually very relieved that they didn't (and suspect that RemObjects themselves might have resisted any attempt to do so).  ;)

The very fact that an outfit such as RemObjects have both the technical nouse and capacity to deliver something like Elements whilst Embarcadero, with far more resources at their disposal, are left buying up other people's technologies and trying to create a marketing message around them whilst rushing out poor quality releases (XE6 Hotfix 1 was out before the ink had dried on the XE6 release EULA!) to keep the money mill churning, should tell you everything you need to know about Delphi's future.

If RemObjects can do it, and if Embarcadero are everything that their supporters crack them up to be, then Embarcadero should have been able to deliver their own "Elements", especially given that they would have been able to focus exclusively on a Pascal solution, if they so chose, without the added distraction of a C# front end.

@Leigh....

Yes, Oxygene/Hydrogene (hereafter: Elements) when targetting Java, produces Java byte code.  Just like the vast majority of Android code out there (with the exception of games - the one type of app that the NativeActivity support in Android was only ever intended for).  Oh, and the FireMonkey apps.

One thing this means is that unlike FireMonkey, your target platform is not confined only to Android and the Java environment provided there.  For example, if you really wanted to, you could use Elements to create an Eclipse plug-in.

Elements can produce Java code, hence Elements supports all Java based platforms using all of the capabilities that those Java platforms supports because - to all intents and purposes - when compiling for Java, Elements is Java.  Just with a different language front-end.

As such, yes, it runs at Java speed, just like all the other Java code on those Java based devices, Android or otherwise.  But it does so without having to drag in a bloated runtime and a custom UI rendering engine (and that's incorporated into EVERY FireMonkey app, btw).  Your apps take full advantage of the device capabilities.

That includes, for example, ART, which is the Android technology that allows Java based Android apps to be installed as pre-compiled, native code binaries.  Just like FireMonkey apps, but without the embedded bloatware, and with the ability to run on any Android device (that support ART, or indeed of course all the ones that don''t).

But equally, when compiling for Cocoa, Elements is an LLVM compiler.  All of the same advantages apply - you have complete, platform native access to the platform with all of the benefits that accrue.  Whether that is Cocoa (OS X) or CocoaTouch (iOS).

Similarly, Elements for .NET... any .NET based platform is available to you, be that Windows.NET, Windows RT or Windows Phone.

How is the .NET support in FireMonkey these days, by the way ?   ;)

On 5 May 2014 12:59, russell <russell at belding.co.nz> wrote:

Always interesting to read strong opinions … even when presented as facts and focusing on a few topics.

The analysis looks plausible. I cannot assess it well as I write for a niche community  and RAD Studio serves me fairly well.

Russell

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith
Sent: Monday, 5 May 2014 11:13 a.m.

To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Auckland Event Details

What makes less sense is the way that they added support for those platforms.  You are right to highlight the manner in which they have managed to tick boxes.  Unfortunately it is purely an exercise in ticking boxes.  Far less useful as a solid basis for continuing to be able to keep those boxes ticked.

Delphi was always a niche product.  Despite the marketing, their cross-platform solution is not Delphi for "iOS/OS X/Android" (and it painfully clearly is not Delphi for .NET, let alone WinRT or WinPhone).  It is "Delphi for FireMonkey", with the ability to deploy to any platform that FireMonkey manages to cajole a semblance of support for within the constraints of what the approach allows.

i.e. you cannot build true Android solutions using FireMonkey because the way that FireMonkey works rules out certain capabilities of that platform.  Similarly your FireMonkey Android apps will not benefit from ART.  Sure, your FireMonkey app is "native code", but is also bogged down by the non-platform native frameworks required to make even "Hello World"possible, so whilst true platform native apps gain all the benefits that that platform delivers, FireMonkey remains stuck in it's own world.

i.e. FireMonkey created a niche within a niche.

Having attracted the interest of Delphi developers to the platforms that FireMonkey ticks the boxes for, many of those developers will quickly realise the limits and look instead at the alternatives, at which point they realise just how far behind Delphi has fallen over the years while Embarcadero wasted their time on the Smoking Chimp.

As for the renewed interest in developing the VCL, this can be seen as a return to core value, or it could be seen as a belated recognition that FireMonkey is not in fact the secure future for Delphi/Embarcadero that it was supposed to be, and worst of all, without any viable strategy for supporting the platform on which that core value rests - i.e. the latest and future versions of Windows - even that core value is now at risk.

For myself, I now use a combination of RemObjects Elements and Xcode for most of my work.  Delphi is now very much a legacy platform.

On 5 May 2014 10:46, David Brennan <dugdavid at dbsolutions.co.nz> wrote:

It was a good seminar IMO. I understand why Embarcadero have decided to spend so much time adding support for OS-X, iOS and Android, at some point we may even take advantage of it. More importantly though I’m glad they seem to have realised that now they have ticked those boxes they need to return to address quality across the product. 

I just hope that XE7 will continue that trend so that the Delphi IDE and executables continue to improve in speed and robustness. I’m also hoping that XE7 will see a big push to make Code Insight bulletproof (or as bullet proof as such a thing can be, given that if you screw your syntax up completely midway through a big change it is always going to struggle, but it would be nice if it returned to fully operational once you tidy things up a bit!).

Cheers,

David.

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jeremy Coulter
Sent: Monday, 5 May 2014 10:10 a.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Auckland Event Details

Yeah let us know hen its done. We didnt attend the presentation for various reasons, although it would have be good, so am looking forward to hearing what Marco had to say.

Jeremy

On Mon, May 5, 2014 at 9:51 AM, Alister Christie <alister at salespartner.co.nz> wrote:

I managed to spend a number of hours with Marco after the presentation, and have about an hour and a quarter recorded, which I will make available after Marco has reviewed it.  It was great talking with him, it seems that Embarcadero made a good choice appointing him Product Manager for Rad Studio.

Alister 

Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
Follow us on Twitter http://twitter.com/salespartner
PO Box 13085
Johnsonville
Wellington

On Wed, Apr 30, 2014 at 8:43 AM, Gary Benner <gary at benner.co.nz> wrote:

HI All,

Sorry this is a little late but just got back from a trip overseas. 

To endorse Alister's comment, great opportunity to meet Marco.

cheers

Gary

Please see below details for the RAD XE6 Launch. Please will you forward this email invitation to members of the NZDUD to register/attend the event. 

Date and Venue:

Friday, 02 May: Auckland

Venue: Rydges Auckland - 59 Federal Street Cnr Kingston Street, Auckland 1010, New Zealand

Time: 8.30am Registrations, 9:00am – 12:00pm 

http://forms.embarcadero.com/AP14Q2NZDeveloperDirectLIVE 

The event will be hosted by Damien Bootsma with special guest-speaker, Marco Cantu, RAD Studio Product Manager, global luminary & author of over a dozen books on Delphi. This event is not to be missed, so register NOW, as spaces are limited! 

Be amongst the first to see live previews of RAD Studio XE6 and all of the great new technology, with the latest enhancements to the VCL and more. 
Here's a glimpse of what is in store:

Empowering your VCL codebase and developer productivity

• Give Your VCL apps a new look-and-feel with improved VCL Styling 
• Introducing Win 7/8 taskbar buttons

Database, integration and scalable services with RAD Studio XE6

• Core Database Features Improvements
• New FireDAC Database Explorer and more
• Working with JSON and XML
• Building scalable and secure DataSnap services

Embrace and Extend Your Mobile and VCL applications

• App Tethering
• Not reinventing the wheel with new BAAS Client components

"Turning on" to mobile and The FM Application Platform

• Introducing Android support in C++Builder XE6
• App Monetization with Advertising and In-App Purchases

Evolution within a revolution: Summary and Q&A

If you are an application developer, technologist or development team leader and interested in modernising your VCL apps & extending your applications to mobile devices for your customers, then this event is for you!

Kind regards,

Mike

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20140505/5b014518/attachment-0001.html 