7 ms·

Declarative UI is boss. I know Andy (former UIKit team) was quoted in the intro thread but I'll do it again: >I say with confidence as a former UIKit author:

• Touche 12y ago
  It's too bad that you can't separate virtual dom, the innovative part of React, from the rest of React which has its warts. They should receive credit for coming up with the idea, but there are better, more reactive frameworks using virtual doms now. React shouldn't win simply because they were first and have a big company behind them.
  • danabramov 12y ago
    Virtual DOM is an implementation detail of React for web. Its true innovation is its declarative component model. You are missing the point of React. https://medium.com/@dan_abramov/youre-missing-the-point-of-react-a20e34a51e1a https://medium.com/@dan_abramov/youre-missing-the-point-of-r...
    • Touche 12y ago
      I don't know what you mean by "declarative component model", can you explain?
      • danabramov 12y ago
        The mental model is much simpler because your `render` method describes UI at any point of time. Not just the DOM, but your own components too. On the inside, any component can have its own state, but from the outside, it's not visible, and components using it don't care or know about it. Separating `props` and `state`, component boundaries, lack of two-way binding and predictable top-down data flow make it easy to reason about where any data comes from, and how UI will change over time. Read this: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-...
        • Touche 12y ago
          This is true of all virtual dom libraries. There is no point of two-way binding when you have a virtual dom, and I'm not sure it even makes sense since you have to rerender the tree anyways. So we agree, you're just separating the concept from the implementation and I'm talking about them as one.
          • danabramov 12y ago
            There's a difference between “virtual DOM” and components. In React, components are not just functions that return their own virtual DOM. AFAIK for many vdom-based libraries this statement wouldn't be true. React components may have local state (as much as some people hate it, some find it useful), they have a lifecycle, can react to receiving new props with side effects, can implement diff bail-out hook. And you can nest such components declaratively.
            • Touche 12y ago
              The other libraries intentionally left out shouldComponentUpdate because they don't think it's something a developer should have to worry about. I don't know of any evidence to suggest that React is faster because of this feature. And declarative nesting is a feature of all of the frameworks I've come across, I'm not sure why you think that's unique to React. The advantage feature I would credit React for is the size of its community and influential advocates like you.
    • adrusi 12y ago
      The "declarative component model" is not an innovation, it's an obvious approach that has been used for ages when prototyping. You can achieve the same conceptual model of your interface by just generating the entire HTML of the page and rerendering it whenever something changes. This obviously doesn't perform and has some edge cases where it breaks things (textboxes, for example), but the idea is the same as react's components. FRP is based around the idea of declarative components, but a lot of developers have an aversion to it because of the academic aura around it. React's innovation is using virtual DOM to make declarative components usable without delving into FRP.
      • danabramov 12y ago
        >FRP is based around the idea of declarative components, but a lot of developers have an aversion to it because of the academic aura around it. Not just that. I may be stupid but personally I find it mentally simpler to `setState` than to `flatMapLatest`. To each their own I suppose. >React's innovation is using virtual DOM to make declarative components usable without delving into FRP. Precisely. >The "declarative component model" is not an innovation, it's an obvious approach [..] can achieve the same [..] by [..] obviously doesn't perform and has some edge cases where it breaks things (textboxes, for example), but the idea is the same React is not an academic paper, it's a tool. It doesn't need to have new ideas, it needs to execute on them in a practical way. Which it does.
  • rattray 12y ago
    You can: https://www.npmjs.com/package/virtual-dom https://www.npmjs.com/package/virtual-dom You should also check out Mithril: https://www.npmjs.com/package/mithril https://www.npmjs.com/package/mithril
    • Touche 12y ago
      I'm aware of these. But React gets all of the attention despite its warts like local component state or encouraging singletons for Flux.
      • danabramov 12y ago
        You can use Om if you like, right? Or Omniscient. Or Morearty. Not everyone is ready to go into FP-land right now. React lets you take these decisions yourself. Whether local state is practical for your team or not. You must be living in a very different world than mine if you think that compared to its rivals (Angular, Ember, etc), React is somehow “encouraging” local state. Sure you could go more functional than that, but take a look at the mainstream frameworks and you'll see it's such a long way to go, that had React not allowed local state, it would not have gotten adoption at all.
        • Touche 12y ago
          There are going to be lots of different types of frameworks that encourage different patterns all backed by this concept. I'm not saying React is the worst of the bunch but I also don't think it's clearly the best. All I'm saying is that when people praise React I wish they were really praising what you call "declarative component model". React is receiving 100% of the attention in this space when imo it should be receiving about 75%.
          • danabramov 12y ago
            >All I'm saying is that when people praise React I wish they were really praising what you call "declarative component model". I long for time when these concepts are boring enough no one thinks of React anymore. Sadly we're not there yet.
  • vog 12y ago
    I believe Riot.js provides a lightweight alternative: https://muut.com/riotjs/ https://muut.com/riotjs/
    • danabramov 12y ago
      Riot.js claims to use virtual DOM whereas, if you look into its source, it doesn't[1] and works with DOM directly. It really has nothing to do with React's approach, at all. [1]: https://github.com/muut/riotjs/blob/master/lib/view.js#L75 https://github.com/muut/riotjs/blob/master/lib/view.js#L75
• Ronsenshi 12y ago
  I've been against mixing logic and views for the longest time and I still wouldn't mind if separation would have been introduced, but recently I gave up. Either I'll be unnecessary stubborn and miss this awesome new tech or I'll shovel my opinion aside and do try working with this approach.... or at least until someone else introduces new framework that comes with code separation. It's not the end of the world.
  • tracker1 12y ago
    Are user triggered events for a view part of the view, or something else? I think this is where such a separation of concerns comes in... a view is more than just how it is rendered, it is also events for the view. There are also child components, and handling these events, or encapsulating them into events to be triggered by a given view. When you think of it this way, it makes sense. From a designer perspective it doesn't, and you have to adapt designs into a view, just the same, you usually do anyway.
    • lumpypua 12y ago
      I think you've got it exactly backwards. Events are not part of the view. Events happen to be triggered by the view and they affect global state which is then reflected in the view. This is the separation of concerns you want. Components don't need to know about events beyond triggering the ones they need. Components only worry about rendering state.
  • lumpypua 12y ago
    The react philosophy of the world is that mixing mutable state and views is bad, logic and views is fine. To be honest this makes a lot of sense to me as a functional programmer. After learning react something conked in my brain. As I rehashed the arguments against logic in views, I realized that they recapitulated FP's arguments against uncontrolled mutable state, just without the nuance. Nothing wrong with purely functional logic/computation itself. And that delineation feels a lot less arbitrary than "logic in views is bad". To be clear, I'm not arguing you should implement domain logic in your views. That's a dumb strawman. But the religious fervor that people have against logic in views is absurd. Reexamine why you think logic in views is bad, and I think you'll find the arguments are actually against 1. poor factoring resulting in ridiculously complex views (and hiding logic is a halfass, crappy way to control complexity) or 2. mutable state.
• xanadohnt 12y ago
  MS have been doing declarative UIs for literally 8 years (XAML).
  • aboodman 12y ago
    That isn't declarative in the same way... that's markup. The kind of declarative that is used in React is more like functional programs. You write programs, using actual code, that compute ("declare") exactly what the UI should look like from top to bottom, given each possible input. This is in contrast to a model where you mutate an existing UI model each time something interesting happens.
    • seanmcdirmid 12y ago
      Declarative is a vacuous word that means anything you want it to depending on context. We used to call functional programming "functional" and logic programming languages like Prolog "declarative." Then declarative started meaning markup, then declarative started meaning...immutable functional code? In PL, we mostly just avoid the word altogether these days since everyone has a different idea about what it means. React is closer to an immediate-mode UI model: you write programs that compute exactly what the UI should look like on each frame, rather than mutating a scene graph each time something interesting happens (as occurs in retained-mode UI models). Substitute DOM for scene graph, and the distinction might hold. But I'm not sure.
      • aboodman 12y ago
        I think that the reason people started calling React 'declarative' was because 'functional' was interpreted to mean (purely) functional, with no side effects. But yes, exactly. React is similar to an immediate mode graphics API. Except that also has weird connotations, because people think of things like canvas that are very low-level: all you get are lines, arcs, and fills. React's primitives are at the same level of abstraction as the DOM, you just work with them in immediate mode, not retained mode.
        • 12y ago
• tootie 12y ago
  JSX mixing presentation logic and views seems to me like they have reinvented PHP. PHP is derided for this, but also for it's shaky implementation and semantics. JSX seems like Good PHP and that's a big deal because PHP is wildly successful despite being awful.
  • nkohari 12y ago
    JSX isn't really HTML, though. It's a way to describe React components in a familiar syntax that resembles HTML. It's a far cry from concatenating strings of HTML like you do in PHP.