Every time someone invents another framework, 1000s of hours are lost to rewriting these widgets - colour pickers, date pickers, drop-downs, combo-boxes etc etc. And that's before people complain about lack of flexibility and all the missing features their predecessors have accrued over time. More wasted time as people try to get to grips with yet another style of configuration, operation and tweaking to fit real world use cases.
I'm all for innovation and advancing the state of the art, but there has got to be a better way of dealing with these basic components. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping StackOverflow in business.
This seems to be one of the things Web Components aim to solve. I expect webapp frameworks of the future to be nothing more than wrappers around Web Components.
> All we're doing here is creating projects for those with time on their hands
I bet this guy learned a ton and has a nice widget on his resume.
> frustrating those with none
The idea is that they gained some advantage from chosing the latest and greatest framework. If that's not worth having to make a widget like this yourself, then you should've chosen old reliable instead.
React encourages writing core logic in a DOM agnostic way. What you're saying is not only true of different frameworks; once code touches the DOM it's poison for reusability, and you can see it even inside of the react ecosystem. The key is to abstract out a pure logical model, and then build your actual DOM-touching instances ontop of that.
This is a curious objection to level against other people doing professional work (which you aren't obligated to consume) for free. Is your life in any way worse because React exists or this dev decided to write some very nice color pickers? If so, doesn't whatever the objection is generalize to "all human activity which doesn't directly benefit me?"
Every time someone invents another genre, 1000s of hours are lost to rewriting these pop songs – 'unrequited devotion', 'overdue break-up', 'manic anthem', 'bittersweet nostalgia', etc etc. And that's before people complain about the tired tropes and outdated attitudes their predecessors have accrued over time. More wasted time as people try to get to grips with yet another style of hipness, coded-language, and personalization to fit real world expressive uses.
I'm all for innovation and advancing the state of the culture, but there has got to be a better way of dealing with these basic emotions. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping the Record Industry in business.
Well, maybe it's true that one has to rewrite the basic components for React. But then - it is one of rare "frameworks" where the components can be really isolated from themselves and compose at the same time.
I'm not a React specialist and I have the following question : Is it that common to write the CSS inside the JSX file?
Since I started learning React, the hardest part to swallow was that my HTML and JS now live in the same file. Now I see that this library also puts the CSS and since I'm not entirely sure if this is good or not, can someone point some Pro's and Cons and if it's common or not.
Many people's gut reaction is that the folks doing inline styles just don't know CSS well enough and haven't learned the techniques advanced CSS developers use to solve these problems. Regardless of how you feel about inline styles, that gut reaction is wrong – they've been there, done that, and believe this is an even better way.
Having the HTML and JS in the same file makes sense, since the HTML and the DOM manipulation code (which is what you usually see in the .jsx) tend to be tightly coupled; when they are, putting them in separate files really only gives the illusion of modularization.
Having CSS in the same file will either make sense, or not, depending on how you view the html. If you feel strongly about the separation of semantics and presentation, then you will still want to keep them separate. Many people are just trying to get what is in the webpage to look like the design prototype, so their CSS would end up tightly-coupled anyway, and the previous argument to JS+HTML applies.
[edit]
Also, a lot of what is in .css right now isn't about making a paragraph look like X, a quote look like Y, etc. but rather about applying styles to specific DOM elements for various reasons. Once you're at that point, the downsides to CSS clearly outweighs the advantages.
It works in some cases as a pattern of keeping components very modular and only loading the styles on the page that a single component needs. And I think it works well in cases where a component is very unique and wouldn't share any styles with other components.
That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications.
There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.
Try dragging within the colorpicker rainbow sections... Its super slow, for every drag event React-engine will perform a diff on the domtree.... This is not the way to implement such components. React is nice for non-continuous dom updates. But it will be never quicker than drawing to the screen yourselve, or updating the components yourselve... Its a lot faster than diffing a tree every few milliseconds.
I've tried half a dozen libraries to solve this problem for Literally Canvas (http://literallycanvas.com). They all have one or more dealbreakers. In this case, it's superficially that the controls are too close together to be touch-friendly. But it looks really extensible and easy to change, so I'll give it a shot anyhow. Thanks!
If you know of a color-picker design that is better spaced (mobile friendly) go ahead and open up a issue on the repo and paste it in there. I am going to be going through this week and making a couple more!
ReactJS is quicker than you'd expect for a gigantic JavaScript-based DOM diffing engine, but somehow this got distorted into the misconception that it's faster than native. It's not.
Like with most new technologies, we're currently in the phase where we're overusing it. In the long run, this will hopefully even out into a state where React-style DOM abstraction instead becomes just one more tool to be used when appropriate.
Where did you notice a lot of lag (what device and where on the site)? I thought the performance was very good within a single widget, but there's obviously some debubble going on when updating the linked components
The Sketch colour picker in the second sample in More Examples has no alpha, yet displays an editable field for it. Furthermore, while a text box for the colour component has focus, dragging of the label below it changes the colour, but not the value in the text box. And I think for all "dialog-like" colour pickers the text box labels should actually be labels for the text box, that is, when clicked, they should put focus on the text box.
Very nice work. Sincerely, thank you for the writeup! I'm still trying to gauge whether React is good for me or not, and this is very readable :)
I noticed that it is trivial to break the whole thing in a way that would probably put off average users. (See Bug Report at bottom.)
I would like to read ideas here that weigh the merits of Web Components and other compartmentalized (web) programming techniques and their ability to still have the ability to fail globally, especially if they promote an environment that gives the (perhaps false) notion that 'What I do in this will not be a problem for you'. Is this a function of React(and similar), the programmer, or other? Is it even a thing at all?
Bug Report: Changing an integer value to "g" in the R field of "Sketch" breaks ALL widgets with the only apparent way of fixing is clicking a swatch or entering a valid hex where available. Clicking Up or Down arrows in 'Chrome' does not fix. Clicking in color areas of 'Chrome', 'Sketch', or 'Photoshop' does not fix. Inputting Valid RGB values into any field does not fix but reverts to NAN.
Thank you so much for the bug report! There are so many edge cases, I cant believe I didnt even catch this one -- being so basic. I have created a github issue for it and hope to fix this tonight!
This looks awesome; the color pickers I've seen for react so far are either really minimally complete or too rigid. Nice to have a solid one to reference/use if I need it. Thanks for your work on this!
This is really cool! Sorry if this is kind of a dumb question but I know nothing about web development: can I use this without running node on the server? I'd like to use this for a WebGL distance field renderer I'm working on but host things on my Github page and thus can only do client side stuff. Getting a server is a possibility but for just one tiny project it doesn't seem worth it.
Yes, you can absolutely run React components without the use of a server. You can edit an html file locally and put a react component in there. That's usually the first thing most React tutorials have you do.
If you're using a backend server you're just rendering the react stuff to html and sending it to the client.
Yeah, you totally can! It's all front-end with React and Webpack. You can use Webpack in development and just have it build the static html and js files for gh-pages. Thats how the documentation site is built :)
The documentation is awesome, I noticed it is pretty similar to React-CSS's documentation. Is that the original source of this documentation style or is there some library I can use for my own personal project?
Thanks! I built it originally for `reactcss` but have used it on 3 projects now. I am going to be releasing it at the end of next month with a nice writeup!
Wow! I feel like this is one of the first packaged widgets I've ever come across (could be very very wrong). Great example of how React and web components will make the future of the web more awesome.
In fairness. The vast majority of the code in this library is describing the UI, and event handlers, which is exactly what React is used for. It's not like there's a ton of non-React code in here that could be abstracted out into a separate library.
[+] [-] ts330|10 years ago|reply
I'm all for innovation and advancing the state of the art, but there has got to be a better way of dealing with these basic components. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping StackOverflow in business.
[+] [-] symlinkk|10 years ago|reply
[+] [-] tinco|10 years ago|reply
I bet this guy learned a ton and has a nice widget on his resume.
> frustrating those with none
The idea is that they gained some advantage from chosing the latest and greatest framework. If that's not worth having to make a widget like this yourself, then you should've chosen old reliable instead.
[+] [-] HeyImAlex|10 years ago|reply
[+] [-] jewel|10 years ago|reply
In the long run, shadow DOM should make it easier to make framework agnostic widgets.
[+] [-] dominotw|10 years ago|reply
[+] [-] tonyblundell|10 years ago|reply
[+] [-] patio11|10 years ago|reply
[+] [-] gojomo|10 years ago|reply
I'm all for innovation and advancing the state of the culture, but there has got to be a better way of dealing with these basic emotions. All we're doing here is creating projects for those with time on their hands, frustrating those with none, and keeping the Record Industry in business.
[+] [-] spankalee|10 years ago|reply
[+] [-] mateuszf|10 years ago|reply
[+] [-] drinchev|10 years ago|reply
I'm not a React specialist and I have the following question : Is it that common to write the CSS inside the JSX file?
Since I started learning React, the hardest part to swallow was that my HTML and JS now live in the same file. Now I see that this library also puts the CSS and since I'm not entirely sure if this is good or not, can someone point some Pro's and Cons and if it's common or not.
[+] [-] exogen|10 years ago|reply
Many people's gut reaction is that the folks doing inline styles just don't know CSS well enough and haven't learned the techniques advanced CSS developers use to solve these problems. Regardless of how you feel about inline styles, that gut reaction is wrong – they've been there, done that, and believe this is an even better way.
[+] [-] graffitici|10 years ago|reply
http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...
[+] [-] aidenn0|10 years ago|reply
Having CSS in the same file will either make sense, or not, depending on how you view the html. If you feel strongly about the separation of semantics and presentation, then you will still want to keep them separate. Many people are just trying to get what is in the webpage to look like the design prototype, so their CSS would end up tightly-coupled anyway, and the previous argument to JS+HTML applies.
[edit]
Also, a lot of what is in .css right now isn't about making a paragraph look like X, a quote look like Y, etc. but rather about applying styles to specific DOM elements for various reasons. Once you're at that point, the downsides to CSS clearly outweighs the advantages.
[+] [-] kylecesmat|10 years ago|reply
That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications.
There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.
[+] [-] clessg|10 years ago|reply
https://www.youtube.com/watch?v=ERB1TJBn32c
[+] [-] TeeWEE|10 years ago|reply
[+] [-] TeeWEE|10 years ago|reply
[+] [-] stevejohnson|10 years ago|reply
[+] [-] casesandberg|10 years ago|reply
If you know of a color-picker design that is better spaced (mobile friendly) go ahead and open up a issue on the repo and paste it in there. I am going to be going through this week and making a couple more!
[+] [-] sktrdie|10 years ago|reply
[+] [-] Udo|10 years ago|reply
Like with most new technologies, we're currently in the phase where we're overusing it. In the long run, this will hopefully even out into a state where React-style DOM abstraction instead becomes just one more tool to be used when appropriate.
[+] [-] watty|10 years ago|reply
[+] [-] awinder|10 years ago|reply
[+] [-] ygra|10 years ago|reply
The Sketch colour picker in the second sample in More Examples has no alpha, yet displays an editable field for it. Furthermore, while a text box for the colour component has focus, dragging of the label below it changes the colour, but not the value in the text box. And I think for all "dialog-like" colour pickers the text box labels should actually be labels for the text box, that is, when clicked, they should put focus on the text box.
[+] [-] ademup|10 years ago|reply
I noticed that it is trivial to break the whole thing in a way that would probably put off average users. (See Bug Report at bottom.)
I would like to read ideas here that weigh the merits of Web Components and other compartmentalized (web) programming techniques and their ability to still have the ability to fail globally, especially if they promote an environment that gives the (perhaps false) notion that 'What I do in this will not be a problem for you'. Is this a function of React(and similar), the programmer, or other? Is it even a thing at all?
Bug Report: Changing an integer value to "g" in the R field of "Sketch" breaks ALL widgets with the only apparent way of fixing is clicking a swatch or entering a valid hex where available. Clicking Up or Down arrows in 'Chrome' does not fix. Clicking in color areas of 'Chrome', 'Sketch', or 'Photoshop' does not fix. Inputting Valid RGB values into any field does not fix but reverts to NAN.
[+] [-] casesandberg|10 years ago|reply
https://github.com/casesandberg/react-color/issues/11
[+] [-] casesandberg|10 years ago|reply
[+] [-] thedaemon|10 years ago|reply
[+] [-] casesandberg|10 years ago|reply
[+] [-] dbbolton|10 years ago|reply
[+] [-] casesandberg|10 years ago|reply
https://github.com/casesandberg/react-color/issues/6
[+] [-] markthethomas|10 years ago|reply
[+] [-] Twinklebear|10 years ago|reply
[+] [-] ClayM|10 years ago|reply
If you're using a backend server you're just rendering the react stuff to html and sending it to the client.
[+] [-] TN1ck|10 years ago|reply
[1] http://workshop.chromeexperiments.com/examples/gui/#1--Basic...
[+] [-] casesandberg|10 years ago|reply
[+] [-] KiaFathi|10 years ago|reply
[+] [-] casesandberg|10 years ago|reply
[+] [-] mshenfield|10 years ago|reply
[+] [-] awinder|10 years ago|reply
[+] [-] vezzy-fnord|10 years ago|reply
You are.
[+] [-] JDDunn9|10 years ago|reply
[+] [-] ultrafez|10 years ago|reply
[+] [-] andrewingram|10 years ago|reply
[+] [-] tajano|10 years ago|reply
[+] [-] smaili|10 years ago|reply
[+] [-] webosb|10 years ago|reply