Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What's old is new. Silverlight had a big focus on declarative UI that continues to today with XAML: https://msdn.microsoft.com/en-us/expression/cc941385.aspx


My first job was as a Silverlight developer. I used to complain all the time about XAML, and as a huge React fanboy, its been lurking in the back of my mind. Why would I like JSX but not XAML? Especially since early Silverlight projects used 'code-behind', which is essentially just a c# file that is paired with each component. How is this different than React? At all?

I think the biggest difference is that XAML was really terrible to work with in part because of proprietary components and the massive tooling around it. I remember I'd have to use Blend whenever I wanted to change how something looked. And then there wasn't a great application structure that moved along with it. I pushed really hard for us to switch from code-behind to MVVM for our application architecture. It worked great, and made everything much easier, though it was really abstract and styling was difficult still. But that was my first job--maybe if I went back it would seem trivial.

I don't know if this applies to XAML, but once you start thinking of React in a component architecture model (knowing JS helps too!), the declarative style makes so much sense.


I also came from a XAML background to React and had the same feeling.

This is a long shot, since most people have a love/hate relationship with the VisualStateManager, but I have been trying to build a declarative visual state thing over at https://github.com/jgable/react-vsm. It's not done, only messed around over a couple weekends, but the gist is there.


Same here, style in XAML is very verbose, and conditional rendering is not created from the code with ternary operator and conditions, but with templates in XAML that are very verbose and it is hard to remember how to use them. Also the use of 2 way databinding cause a lot of problems.


It's also the lack of support of CSS in XAML. JSX didn't re-invent HTML with proprietary tag names and strange layout attributes... though this whole CSS in JS thing I can start to get behind if the tooling improves.


Similar story here. I don't miss the mental context switching. I also always hated how many template languages/frameworks stuff DSLs into strings.


It's also how Backbone has always worked.. Canonical Backbone has you `this.model.bind('change', this.render)` where `this.render` is a pure function (typically just passing `this.model` to a Handlebars template).


Silverlight's UI system was MVVM, based on AngularJS-like two-way data binding (actually, KnockoutJS is inspired by it).

Sure, the UI is pretty much pure, but it moves all the state who-did-what-in-what-order mess to the View Model, so the problem is just moved, not fixed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: