Windows 8: HTML5 and AJAX/JavaScript == Modern UIs | Hacker News Reader

Windows 8: HTML5 and AJAX/JavaScript == Modern UIs

samgentile.com

17 pointslibria35 comments

It makes perfect sense that HTML5/JS would overtake traditional UI frameworks on the client side. Doing Win32, Java Swing, etc. was a horrible experience compared to the relative niceness of HTML/JS.

Adobe Flex/AIR was probably the best client UI dev experience I've had. MXML and Actionscript 3 is VERY similar to HTML/JS. Given the benefits of so many platforms moving towards HTML/JS as a kind of common language for UI development, these are exciting times.

The niceness is in the Javascript, not HTML. HTML is made for text layout, not stateful UIs.

Javascript is an implied part of DOM scripting. HTML5 is an umbrella term covering all of these technologies and is much more than text layout.

Right the DOM is the problem. Javascript exists without the DOM. Just imagine Cocoa written using Javascript instead of Objective-C

You missed WPF.

I've done a little bit of WPF and it's in many ways identical to Flex. The only thing I never understood is why MSFT couldn't even get their own people to adopt it much outside of the beautiful Zune software.

Visual Studio 2010 is developed under .NET/WPF.

People have been predicting web-based desktop development for 15 years now, and it never happens. Netscape even wanted to replace the Windows 95 shell. Apple tried to push web apps for third-party iPhone development, and people didn't want it. There are just too many advantages to native performance and development, not to mention that Javascript isn't the sanest language in the world (to be expected since it was hacked together in 10 days at Netscape).

We don't need "modern" UI frameworks we need well designed UI frameworks. HTML isn't designed for stateful UIs. I'm hoping that Cocoa will eventually move away from Objective-C and towards a more dynamic (expressive) language (Javascript would be great).

A major problem with web-based UIs is the lack of sane defaults. The default for HTML is a document with basic formatting. You need somebody with good design skills to create an App that doesn't look awful.

On the other hand, frameworks such as UIKit provide all you need for a nice-looking UI. Developers just need to worry about the application code, and worry about UI design much later in the process.

By "dynamic" do you mean "interpreted"? Because Objective-C is a pretty dynamic and flexible language, otherwise.

Objective-C does have performSelector, but its awkward to use. It lacks the ability to easily add slots to objects and you often have to work with C types.

Perhaps "expressive" would be a better distinction. Javascript is a much more expressive language, meaning that I have to do a lot less work to accomplish the same end.

> Objective-C does have performSelector, but its awkward to use. It lacks the ability to easily add slots to objects and you often have to work with C types.

-performSelector: takes a selector string, and its variants allow you to pass objects as arguments. I'm not sure why you think it involves C types or why you cite it as the feature that makes Objective-C dynamic (there's considerably more to it than that).

I was talking about Objective-C not performSelector, although performSelector does illustrate some problems with C types. You can't return a value with perform selector precisely because of C types (unless you wanted performSelectorReturningInt ... etc)

Have you looked at this?

http://cappuccino.org/

It's basically Cocoa on javascript using Objective-J

I like cappuccino the framework but not Objective-J the language. It mostly takes the bad parts of Objective-C and puts them on top of Javascript (with the exception of "forward")

Objective-C is already a dynamic language. Its ability to drop to low-level C at will makes it too flexible and powerful to abandon for something slow and cumbersome like Javascript.

Which is more cumbersome?

    //Objective-C
    
    #import <Foundation/Foundation.h>
    
    @interface Order : NSObject {
    	NSString *id;
    	Customer *customer;
    	NSDate *timestamp;
    	NSString *productId;
    }
    
    @property (nonatomic, retain) NSString *id;
    @property (nonatomic, retain) Customer *customer;
    @property (nonatomic, retain) NSDate *timestamp;
    @property (nonatomic, retain) NSString *productId;
    
    @end
    
    #import "Order.h"
    
    @implementation Article
    
    @synthesize id;
    @synthesize customer;
    @synthesize timestamp;
    @synthesize productId;
    
    - (void)dealloc
    {
    	[self setId:nil];
    	[self setCustomer:nil];
    	[self setTimestamp:nil];
    	[self setProductId:nil];
    	[super dealloc];
    }
    
    //Javascript
    
    Order = Proto.clone().newSlots("id", "customer", "timestamp", "productId");

I fully agree. I used to be a big fan of Objective-C and saw no need for a more expressive language.

Then I started coding in PyQt (a Python, Qt bridge). Now I know: Objective-C is not a high level language, even though it has some high level aspects. Also, coding in a high level language can improve productivity by a huge margin, even if you are coding against a low level framework.

On the desktop, this is a more than worthwhile tradeoff. Mobile devices still benefit from the performance advantage of Objective-C as opposed to, say, MacRuby.

Verbosity also promotes to poor design decisions. I often skip creating additional classes that would result in better factored code because it's too much work.

"Because it's too much work" tends to be a bad excuse, though.

If creating a new class took an hour would it be a bad excuse? How about a day?

Getting rid of "Too much work" is the point of software.

Objective-C is always going to win the contest for Smalltalk-esque verbosity, but I would hardly consider the code you wrote to be cumbersome. In the modern Objective-C runtime using garbage collection, you can write this:

    // Order.h
    #import <Foundation/Foundation.h>
    
    @interface Order : NSObject
    @property (copy) NSString *id;
    @property (retain) Customer *customer;
    @property (copy) NSDate *timestamp;
    @property (copy) NSString *productId;
    @end
    

    // Order.m
    #import "Order.h"
    
    @implementation Article
    @synthesize id;
    @synthesize customer;
    @synthesize timestamp;
    @synthesize productId;
    @end

Apple engineers have confirmed that they're working on making @synthesize the default behavior for properties, so eventually you won't have to write that either. A real-world app would be using Core Data for its model objects, negating the need to write this class at all while adding automatic faulting, data integrity, and undo/redo:

    Order *order = [NSEntityDescription insertNewObjectForEntityForName:@"Order"
                    inManagedObjectContext:self.managedObjectContext];

Thank you for further solidifying my point.

What is it with people trying jQuery and immediately jumping the gun into "I can solve all of the world's problems with this!" land? Sure, it's great for DOM interaction, but that's simply not enough for any decent UI framework. The jQueryUI project has what, like 10 widgets despite being around for years? Wooooweeee, you can sure base an OS UI off of that! And I don't care how many jQuery plugins I can find on Google; trying to fit them in together in some cohesive manner is a joke compared to an actual full featured UI framework that uses a MVC or MVVM structure.

Seems to be down, anyone have a backup?

HTML/JS/CSS has been the worst UI experience I've had, I'm interested to read how this has changed. It's gotten increasingly better since jQuery was released but still feels like pulling teeth working with cross browser hacks.

With modern JS frameworks you don't need to mess with cross-browser stuff at all. That's basically a solved problem.

Given that, HTML/JS/CSS is quite good. And the obvious benefit is your code will run everywhere.

Well I've used modern frameworks and it's still far from running exactly the same across all browsers and OS's - especially if you'd like to use CSS3/HTML5. It's still a major pain in the ass to do something as simple as center a div vertically on a page. I don't consider that modern.

One man's ass-pain is another's eccentric but ultimately reasonable idiom.

Sorry, but Windows Forms or WPF are far ahead of HTML5. Just look at the amount and quality of third party libraries over .NET. And the speed of development is really fast, just a drag & drop in the IDE and some events to fill.

There is nothing inherent about HTML5 can't do this, it's just a lack of tooling and libraries. The Windows 8 demo shows that the performance is already there. Look at GWT for a possible development model. It's very possible that MS will deliver something that looks very much like GWT UI Builder or Blend but targeting HTML5 and scriptable by Javascript if necessary. I'd be very surprised if MS didn't have a drop-and-drop designer solution given that this is their bread and butter.

Javascript + HTML5 is a a pretty ideal view layer, but MS almost certainly will need to provide a higher level story like GWT to satisfy their developers and support large teams. Google has shifted entirely to GWT over hand-coded javascript for their applications. It seems unlikely that MS would have worse tooling than Google, particularly given that MS can leverage their development tools (.NET + future compiler as a service).

Is there any information on what development model MS is thinking about?

> Google has shifted entirely to GWT over hand-coded javascript for their applications.

Interesting. Source?

> It seems unlikely that MS would have worse tooling than Google, particularly given that MS can leverage their development tools (.NET + future compiler as a service).

It would not be hard to build a .NET to JS compiler as a parallel to GWT. In fact there are already a few such projects, one of them even a Microsoft one (Volta).

I would not be surprised to see Microsoft put some effort behind such a project. However there have been no indications so far.

No source. Just look at every new product they release. All of them that started post GWT are based on GWT as far as I can tell. The new AdWords interface being the latest and Wave coming before that. Even small apps, like their new discovery API browser are GWT based. It makes sense too. They need to support long-run development of large applications. That just becomes much easier given something like GWT and all the associated tooling that comes with it.

For the F# developer, WebSharper ( http://websharper.com/ ) seems to offer a great implementation based on the Formlets abstraction. For some theoretical background, have a look at http://groups.inf.ed.ac.uk/links/formlets/ which has some articles describing the Form abstraction by Philip Wadler, et al.

Reply on news.ycombinator.com