I really like the core concepts of React, especially the way it is designed to help you organize your code into reusable components.
I think the key to making React take off is building a centralized repository for components that are open source. Then building your webapp would be as easy as importing the components you need:
I'm working on an app that takes this idea a step further. It is a platform that lets people create apps by defining a data schema and UI components to edit and display this. Once an app/schema/component is defined, it can be "forked" by others and further customized. Think github not for source code, but live apps[1].
One of the key requirements for this was a way to run untrusted scripts client-side (server-side is somewhat easy), since the platform lets users write arbitrary UI components. React works wonderfully here (in theory); we can isolate the React component in a sandbox (iframe with sandbox attribute set) and copy the Virtual DOM back to the main window after sanitization.
Add:
The beauty of React is that the developers recognized the limitations of other approaches; components in web apps cannot be solved with a rehash or an improvement on existing ideas. Giving up the usual design patterns and DOM hackery in favor of an esprima-based Javascript parser and serious Math is some creative thinking.
That is pretty interesting. So using Fora you can jumpstart a new app by defining all your data models, and then select a bunch of components to build a skeleton view that makes use of those models?
If so this will be very useful, especially since it sounds like it will allow us devs to spend more time on the business specific logic, and making the interface beautiful, instead of spending lots of time gluing together components and models.
Yup that is what it is. It builds on the notion that many apps are actually forums, with various levels of customization. Flickr, Pinterest, HN and even Amazon and Tiger Direct (TigerDirect will have products, reviews etc as 'posts') are actually forums. So we use the term forums and apps interchangeably.
The social aspect is equally important:
- There are millions of developers who don't participate in improving apps today because creating and hosting an app isn't a friction-less process. On Fora, if you see an app/forum that fits your needs, click fork, edit some JS+React/JSX in the browser, and you have a new app.
- Everybody sees all source code for all apps/forums; so it's great to learn. And then improvements help everybody. Like wikipedia for code. .
- Many people know enough JS to tweak stuff. React mostly takes just JS knowledge, so you don't need to know the framework like Angular. Ah, and also isomorphic UI code that runs on the server and browser. Also for all it's issues, one thing JS has going for it is that you can read and edit in a browser.
So I have a word of caution. As someone else in the thread mentioned, React is very intuitive for beginners. There's another framework I've used that was also intuitive for beginners: Backbone. The reason why Backbone is inferior to Angular and Ember is because it optimized for the beginner. Angular and Ember are optimized for the experienced developer on a large code base.
Specific to your suggestion, which I think is awesome, is the idea of composibility. The easiest kind of component to write is a large component with lots of options, like jQuery plugins. This is the hardest kind of component to use outside of its intended use case.
What makes Angular so good is that the core directives are all extremely composable. They can be used all over the place without hacking.
To make your dream come true we as component authors must design carefully to make smaller, more focused tools, rather than large components, because large components are harder to adapt to applications outside their main use case.
React has been designed to work in Facebook's codebase, to build large features worked on by many experienced developers. The fact that it is intuitive for beginners is a side-effect, not the primary objective.
Don't forget that Facebook invested a what I would call inproportionally lot in the PHP ecosystem primarily to let new employees pick up the pace as fast as possible.
I wouldn't be surprised if React was kept intentionally newbie-friendly, too.
While it isn't impossible for a complex library to become popular, I would be very surprised if a library/framework wasn't kept intentionally "newbie-friendly".
Curious why you think Backbone is optimized for beginners as opposed to Angular. I get that Backbone and React have fewer concepts to learn and thus are more approachable. But if you're building serious applications I'd say Backbone and React require MORE experience, because there are fewer choices made for you than Angular (and especially Ember).
I would agree; Backbone and React are tools that help you do the job, but they don't decide how the job is done. That's up to you. Angular is like the cookie-cutter.
Well they just edited their initial post to specifically use a `bower` command rather the theoretical `react` command, so I'm not sure. What would the different be between your VB-style controls and something like this confirmation popup:
React has a much richer notion of what a 'component' is. To date, most JavaScript libraries lack shared assumptions about how you will build your UI. jQuery plugins make only the extremely minimal assumption that you will apply the plugin to some DOM element - beyond that, how the plugins behave, how they manage their state, properties etc. is not defined by any standards or even assumptions.
The confirmation popover you link to is a good example. It's a black-box component which exposes a fairly minimal interface. The constructor for this component works like this:
new ConfirmationPopover(msg, [title])
To attach the popover to an element you need to do:
popover.show(el, [fn])
However, if we take another component from the same library, the swipe component[1], we see different conventions. Its constructor:
Swipe(el)
It also has a show method which takes totally different parameters:
.show(i, [ms], [options])
This is why I describe such systems as package managers or library managers - they're just a way of importing and exporting code and don't do anything to aid reuse. They're not particularly likely to play well together, lack standard interfaces and are almost certainly not composable in any meaningful way.
React components are different because React defines some standard details of how components behave, how to extend them, how to inspect them and pass data back and forth. Components can contain other components, and all components have a relative place in the render tree. This makes possible standard developer tools that can be used to observe and inspect components in a DOM-like tree structure[2].
So, you could certainly use bower to distribute React components. What's different about React isn't how the code is distributed but the fact that you can have expectations about how, say, a React photo gallery component would behave that you would not get from some other JS library.
Heh... was just in the process of updating my comment with Bower when you replied. I agree that this could work with Bower as the package manager.
However, it would be more convenient if there was a distinction between packages that are designed to be UI components, and packages like AJAX libraries, async, and other logic libraries, which are a better fit for bower.
Distributing the UI components via bower is doable, but it wouldn't be nearly as nice as a dedicated component ecosystem where it is easy to search and discover relevant React components.
The best interface for a react UI component repository would be something that had information like:
* A picture of what the component looks like
* How large the component is in KB
* Which CSS frameworks it requires or supports
* Cross browser support information
Bower is a very simple package manager right now with little information about the package beyond its name, a line of descriptive text, and a link to the Github.
Overall the experience would be better for React devs to develop a customized package manager interface well suited to the type of packages being delivered.
Of course there is nothing stopping UI component creators from distributing their components on both Bower and a React specific package manager, but I think for purposes of discoverability a React specific one would be better suited.
Yes definitely, although I imagine most components will be internal to your own applications as opposed to shared publicly. Web Components is a great model for publicly shared components but not sure how much value it adds for private components. If you are into the component based approach see parcelify and / or cartero as those tools could simply your build process.
Long story short, React has a much more graceful system of making the components generalized instead of the adhoc system that Ember and Backbone use.
Ember and Backbone have features that are similar to components, but components from two different sources will rarely work well, because often one component will break another. Anyone who has tried to put a bunch of different Backbone views from different people together has probably experienced this pain first hand.
React is designed from the ground up to allow components to work well together.
Can you expand more on what you mean by two Ember components will "break each other"? This isn't something I've experienced when putting components together.
Can you also expand on what React design decisions has made vs. Ember that allow components to work well together? We've spent a lot of time thinking about creating a unified interface for Ember components, so I'd like to better understand where it's broken down for you.
so as i understand, the benefit is that React encourages standard I/O. but i also understand that nothing is stopping anyone from using a standard I/O with Backbone or Ember (which i recognize is why you say "from different people").
my point is that it's a people problem as much as a tooling problem. or is it impossible to build incompatible React views?
i'm currently working on a library that makes it easy to share patches (GUI included) for audio applications. i'm using React. one problem i struggle with is that without my own additional standard, nothing is preventing anyone from making a component that can't patch in. which is the same problem i would have if i were using Backbone.
if you're looking for a "standard" way to share components you need to make assumptions about what type of GUI you are building- not just how you are building it.
I think the key to making React take off is building a centralized repository for components that are open source. Then building your webapp would be as easy as importing the components you need:
I think this is definitely the future of how front end web development will be one day.