search

localvoid / uix

[UNMAINTAINED] Dart Web UI library
BSD 2-Clause "Simplified" License
77 stars 4 forks source link

Support server-side rendering #4

Open danschultz opened 9 years ago

danschultz commented 9 years ago

There's a lot of benefits to being able to render components server-side. Would be amazing if uix supported this.

localvoid commented 9 years ago

Tradeoffs in server side and client side rendering

I really don't want to create layers of leaky abstractions just to support content publishing websites that actually doesn't have complicated user interfaces on pages that display content.

Right now I just don't see any good way to implement API for building complex user interfaces in Dart that will work on client and server.

danschultz commented 9 years ago

I really don't want to create layers of leaky abstractions just to support content publishing websites that actually doesn't have complicated user interfaces on pages that display content.

Any website can benefit from an isomorphic approach, not just content publishing sites. Montage is one where we'd like to take advantage of server-side rendering. Even intranet sites mentioned in the article you listed would benefit from this approach. Keep in mind that intranet users are users too, and making the perceived performance of a site faster benefits the user's experience.

Right now I just don't see any good way to implement API for building complex user interfaces in Dart that will work on client and server.

Which API are you referring to, uix?

localvoid commented 9 years ago

Which API are you referring to, uix?

any API that doesn't hide dart:html with some really bad abstraction.

When configured imports will be implemented in Dart, I'll add support for server-side rendering, it is actually quite easy to do.

I just don't want to "fix the web" with some broken abstraction on top of dart:html that will work only in simple cases. If Dart adds support for conditional compilation it will be significantly easier to write "isomorphic" components with uix, all other ways that I can think of will fail as soon as component requires non-trivial form of interaction.

danschultz commented 9 years ago

I'm not sure if configured imports are the right answer to this problem, as it doesn't abstract the components from the environment for the developer.

With a configured imports approach, it places more burden on the developer to wrap any code that uses dart:html with conditional blocks, i.e. // @ifdef BROWSER and // @endif. This'd become especially tedious when working with browser events.

For abstracting events, I think introducing a concept of synthetic events is the right place to start. It could also serve as the basis for dealing with cross device events, if you ever wanted uix to work on -- fingers crossed -- Dart mobile.

localvoid commented 9 years ago

There is no point to abstracting environment from the developer, it is quite important to understand that server-side rendered html output should not always be equal to progressive enhanced html to provide good user experience. For example, Flickr is an example of a good app that can render html on the server and progressively enhance when js is loaded, even when js isn't fully loaded and user tries to interact with some non-trivial input element, they're providing some form of feedback with a small js code that is injected in every html. Implementing a good "isomorphic" app will require to write specific code for browser and server environments.

uix will never work on native mobile platforms like React native, it is not that hard to implement similar project that will work on mobile platforms, and provide similar experience for building UIs. I just don't believe in "one size fits all" solutions, native mobile platforms have different set of problems.

Even in React if you try to implement proper material design Button, it will require access to the native dom api.