5 ms·

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

17 points by libria 15y ago

richcollins 15y ago
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).
- coliveira 15y ago
  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.
- programminggeek 15y ago
  Have you looked at this? http://cappuccino.org/ http://cappuccino.org/ It's basically Cocoa on javascript using Objective-J
  - richcollins 15y ago
    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")
- Zev 15y ago
  By "dynamic" do you mean "interpreted"? Because Objective-C is a pretty dynamic and flexible language, otherwise.
  - richcollins 15y ago
    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.
    - bonch 15y ago
      > 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).
      - richcollins 15y ago
        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)
- bonch 15y ago
  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.
  - richcollins 15y ago
    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");
    - bonch 15y ago
      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];
programminggeek 15y ago
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.
- bonch 15y ago
  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).
- richcollins 15y ago
  The niceness is in the Javascript, not HTML. HTML is made for text layout, not stateful UIs.
  - bonch 15y ago
    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.
    - richcollins 15y ago
      Right the DOM is the problem. Javascript exists without the DOM. Just imagine Cocoa written using Javascript instead of Objective-C
- wslh 15y ago
  You missed WPF.
equark 15y ago
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?
- azakai 15y ago
  > 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.
  - equark 15y ago
    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.
  - junkyarddog 15y ago
    For the F# developer, WebSharper ( http://websharper.com/ 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/ http://groups.inf.ed.ac.uk/links/formlets/ which has some articles describing the Form abstraction by Philip Wadler, et al.
watty 15y ago
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.
- azakai 15y ago
  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.
  - watty 15y ago
    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.
    - yid 15y ago
      One man's ass-pain is another's eccentric but ultimately reasonable idiom.
wslh 15y ago
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.
- equark 15y ago
  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.
nxn 15y ago
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.

17 points by libria 15y ago

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).

coliveira 15y ago
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.
programminggeek 15y ago
Have you looked at this? http://cappuccino.org/ http://cappuccino.org/ It's basically Cocoa on javascript using Objective-J
- richcollins 15y ago
  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")
Zev 15y ago
By "dynamic" do you mean "interpreted"? Because Objective-C is a pretty dynamic and flexible language, otherwise.
- richcollins 15y ago
  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.
  - bonch 15y ago
    > 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).
    - richcollins 15y ago
      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)
bonch 15y ago
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.
- richcollins 15y ago
  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");
  - bonch 15y ago
    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];

programminggeek 15y ago

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.

bonch 15y ago
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).
richcollins 15y ago
The niceness is in the Javascript, not HTML. HTML is made for text layout, not stateful UIs.
- bonch 15y ago
  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.
  - richcollins 15y ago
    Right the DOM is the problem. Javascript exists without the DOM. Just imagine Cocoa written using Javascript instead of Objective-C
wslh 15y ago
You missed WPF.

equark 15y ago

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?

azakai 15y ago
> 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.
- equark 15y ago
  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.
- junkyarddog 15y ago
  For the F# developer, WebSharper ( http://websharper.com/ 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/ http://groups.inf.ed.ac.uk/links/formlets/ which has some articles describing the Form abstraction by Philip Wadler, et al.

watty 15y ago

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.

azakai 15y ago
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.
- watty 15y ago
  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.
  - yid 15y ago
    One man's ass-pain is another's eccentric but ultimately reasonable idiom.

wslh 15y ago

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.

equark 15y ago
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.

nxn 15y ago

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.