Structuring a program with a large number of small components is very awkward when templates and code are in separate files.
As far as that 1000 foot view, a nice tree view of React components is vastly superior to a wall of text cluttered up by meaningless implementation details like "div".
I agree. We've developed a fairly complex Ember application, and the component hierarchy feels cluttered with everything separated by component and template. E.g. I have /my-component/component and /my-component/template instead of just my-component.js. Its funny coming full circle in MVC apps, but I find myself frustrated writing 1-5 line templates -- that I have to import. Why can't I just put it in the same file as the component, and have one file? Subjective to be sure, but I'd much prefer React style components in our project.
The smallest unit in UI design is a component, and React maps well to that, allowing you to treat components as functions (you can compose, specialize). You'll realize the power of that once you work with real UI designers who understand designing from inside-out as opposed to dumping a PSD mock of the entire page.
I'm not sure what you mean. There's nothing in React that would prevent you from making your pages just one huge component. You can split the code any way you like.
JSX is a bit of a weakness IMO - I absolutely rather have templates in separate files to reduce complexity/concerns located in a file. It also adds build tool complexity, which there is too much of in frontend currently.
Otherwise, working in React is generally clean, but one can get that benefit by utilizing ES6 modules in general. React brings a lot of good things to the table, which is probably best exemplified by Angular 2 pulling a lot of ideas from it.
Good point; How does one view the resulting react-page anyway? CTRL+U shows <body><script.../></body> no matter what state the SPA is in..
(This will show you the actual DOM, not the React components... but since you were talking about 'view-source', this might help you too.)
https://chrome.google.com/webstore/detail/react-developer-to...
I may be alone on this, but I've enjoyed working with Mithril much more than I ever did React. If you haven't given it a shot, I highly recommend you do.
Why is a low learning curve important? Several reasons. If you're a developer, it's not a huge investment to learn (how difficult was it to learn backbone / angular / ember?). If you're a startup / company, you don't need to look for X developers, where X is a difficult-to-pick-up JavaScript framework. You also save money by having a shorter on-boarding period for those non-X developers.
I've worked in a hackathon group that picked Mithril up and created amazing results with it right away. I teach at a coding school, and by far Mithril has been the easiest JS framework for my students to learn and work with. For being so powerful, Mithril is quite easy to get started with – and that means a lot.
Mithril didn't quite have everything we needed, though, so we made a small wrapper that provides nicer templating, event delegation, etc.: https://github.com/dailymuse/mithril-coat
You can use the same approach for other libraries:
Add a function as `config` attribute to your virtual DOM element. That function gets the real DOM element as a parameter, and you can act on it with third party libraries.
I was wondering if anyone had tried both Mithril as well as Deku(https://github.com/segmentio/deku) who would like to share their experience?
All I really want is an easy way to get performant DOM manipulations. With React I have to build the whole view around the component system, which isn't so flexible. Am I right in thinking that Mithril allows you to put the view together any way you want, as long as the end result is an object it can diff into the DOM?
It's not ideal for all use cases. But for updating the DOM based on changes to the data, I find it to be a useful option.
Square built and fast library on top of D3 called Crossfilter. Speed is pretty amazing when you see the data source. http://square.github.io/crossfilter/
That's correct. Virtual DOM nodes are plain JS objects with `tag`, `attr` and `children` attributes (the last two being optional).
The `m()` helper gives you some sugar on top of that.
Idiomatic Mithril view code, however, is more about declaratively generating vDOM nodes based on a model and/or a view model than, say, jQuery-style DOM manipulations...
You have a talent for clearly explaining complex abstractions. Nice work!
Maybe JS developers should go through it, through this circle of hell, to avoid it in future, so JSX is necessary evil.
//despite of that, I sincerely thankful for people behind React, for their new ideas and how they changed fields of JS frameworks and mobile apps. Big respect!
Don't think of React as "a container for logic and a system for doing views". Think of it solely as view logic.
It's not mixing views with program logic. It's only view. There's nothing to mix. It just happens --- wonderfully --- to use a real programming language to represent those views.
The notions of logic, controllers, models, storage, and all that jazz are why there's also Flux (or Backbone or whatever else it is you want to use; we use Flummox, it's fine).
Logic and representation are not two unrelated pieces to keep them separate.
//You can use "they" to replace "he/she".
JSX is not HTML, mixing logic/presentation is not a concern because you're not dividing your rendering between backend/frontend, and finally you don't even have to care about the final HTML representation of your component, it's just an implementation detail.
Finally, it's all declarative since you're never modifying a DOM tree - and declarative is a pre-requisite for good UI frameworks.
On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using JSX I need to calculate the result of a `for` loop before the actual template and it looks much more complex and cumbersome.
You can inline eqivalent JavaScript statements in JSX, without typical template language limitations in terms of allowed expressions or scope:
{this.props.foo > 5 && <div>...</div>}
{this.props.foos.map(foo => <div>{foo}</div>)} var R = React.createElement
So what it eliminates is the need to learn React. Anyone who understands how Clojure atoms work and how to use Hiccup-style HTML templating will be able to use Reagent with almost zero learning curve.
When the DOM is treated as the source-of-truth for the page's information, the synchronously-visible changes are very useful. However, getting away from treating the DOM as the source-of-truth, which React forces you to do, gets you a lot of power as changes to the DOM can be batched more efficiently automatically.
I still find the structure of an angular app a lot easier to grasp, it might be that I'm used to it but I remember the first time using Angular that it all made sense to me. I liked it instantly. Coming from Backbone, it certainly was a breath of fresh air. I can't say the same thing about React. Sure it's faster, and if you think your app is going to mutate into something big, consider using it. But I personally wouldn't make it my default choice.
If you think React could be a good fit, simply use it. Comparing frameworks is very time-consuming and doesn't get you any closer to your goals. Actually, any framework is better than pause-deciding-which! :)
The separation of the view and logic is an arbitrary separation that isn't always efficient. It's like owning a bunch of power tools and organizing by color instead of by function.
Templates have components like search bars and login forms and they have logic related to those components. Why should component logic and template code be separated when both the logic and template components serve the same function? Code should be organized by segregating things into widgets. This, to me, makes more sense.
I think the only thing missing from React is the ability to incorporate local css styles into the widget. Again like I said if there are styles associated exclusively with a widget, there's no point in segregating styles into some separate css file.
Logic, structure, and style should be unified and organized by function, not by category.