Hacker News, Reddit, Stack Overflow Stats
|Why people like using this tool||
Companies using this service
"No-one got fired for buying IBM" of front-end 'frameworks', React is a view library that manipulates DOM in an efficient way. Our front-end is build around React & it's ecosystem.
React is choice number 1 when it comes to JS development at Kurzor. We choose React because it solves many issues with web applications in a elegant way. Writing an app in components is useful for coordination and isolation of concerns. React forces you to abandon state and use vertical passing through props instead. And having as many Pure Components as possible helps to write cleaner code.
With React we usually use: Redux, React Router, React Toolbox, Styled Components.
When I have to build front-page components, React helps organize the concepts behind each piece of the UI. However, I prefer to use more native approaches to building elaborate user interfaces than the web.
I mostly use React via a Clojure wrapper called Reagent. Reagent is dead simple and faster than bare React is out of the box. If I have to write a UI myself, I would strongly move to use React via Reagent.
This is the best component framework and API available today for building modern web sites and apps. I really enjoy how minimal it is, and powerful at the same time. It removes opinionated development and replaces it with logic and data philosophies, which has in turn fostered a robust and lively code and support community.
Components in the project are written using the React framework. React Native then takes it a step further using their native components that are interpreting as mobile views.
Favourite frontend framework. Used it in three web projects (+ one project in React Native).
We use react to build responsive and interactive web applications on our data platform.
Powers the more advanced aspects of our front-end interface, esp. the real-time inbox.
React with AEM
html 코드를 짜다 보면 여러 엘리먼트를 조합해 사용하는 경우가 많은데, 이런 것은 하나로 묶어 관리 해야 하지 않을 까 했는데, 그때쯤 나온 라이브러리 이다. 프레임워크가 아니라 라이브러리라 러닝 커브가 적으나, 결국 이것 저것 필요하게 되지면서 점점 프레임워크 처럼 되어 버린다. jsx 는 정말 편리하고 가독성을 높여주는데 그것 때문에 babel 에 webpack을 써야 되는게, 정말 싫다.
I've used React for templating here because I don't like the angular brackets and react seemed like the cool thing to learn
The vast majority of the app's frontend was built in ReactJS with Redux.js as its flux implementation.
All frontend logic consisted of a plain React app without state management of some sort.
Used to dynamically render Front-end by directly manipulating the DOM. Very powerful Library especially with used with Flux.
React in conjunction with RefluxJS is used to create an extendable and responsive dashboard for our clients to analyse their daily business activities in their restaurants.
React is heavily used in Shimo.im. We use it in the homepage, spreadsheet and other places.
Our Console section uses React to create a view for each message logged from our users' devices. Each message has a different type of information, from simple strings to cookies data or DOM trees. Define each type of message declaratively eases our product's development cycle.
Web-frontend programming prior to React: like banging rocks together. With React: Like wearing fusion powered underwear. Gives you a nice warm feeling. Using React for Cloudcraft.co allowed us to create a beautiful UI in record time (1 month start to launch), with virtually no bugs popping up during development. The functional approach to just rendering your component given a state just makes so much sense, with React figuring out the delta between your current and desired representation. It's the future kids!
→ Yet Core
Our UI is built with Reagent, a ClojureScript wrapper around React, allowing us to build UI components that manage their own state instead of performing constant stateful DOM manipulations.
React is amazing for applications that have a lot of moving pieces. The underlying abstraction makes it easy to keep track of highly stateful UIs while keeping code complexity down, so we don't spend as much time fixing bugs.
React forms the core of the single-page application allowing us to declarative build the app in a modular way.
At the beginning of last year, Netflix UI engineers embarked on several ambitious projects to dramatically transform the user experience on our desktop and mobile platforms. Given a UI redesign of a scale similar to that undergone by TVs and game consoles, it was essential for us to re-evaluate our existing UI technology stack and to determine whether to explore new solutions. Do we have the right building blocks to create best-in-class single-page web applications? And what specific problems are we looking to solve? Much of our existing front-end infrastructure consists of hand-rolled components optimized for the current website and iOS application. Our decision to adopt React was influenced by a number of factors, most notably: 1) startup speed, 2) runtime performance, and 3) modularity.
React has exceeded our requirements and enabled us to build a tremendous foundation on which to innovate the Netflix experience.
Before two weeks ago or so, it used to be Backbone views and models, and everything was on our main store app, and our mobile web app, but actually, we just switched our mobile web app to using ReactJS for the interface. So it’s using Backbone models but ReactJS front-end components. Really, it was borne out of the frustration with how the Backbone model-view bindings worked, and it wasn’t especially performant for large views, and we had to do lots of tricks to make it performant. But swapping that out with React views meant that it could be both simpler and faster without having to spend a lot of time on that.
One other interesting thing about that is, since React actually works okay with the Backbone models and the Backbone router and stuff like that, we didn’t have to rewrite the mobile web application and update it to ReactJS. Rewrites are almost always a bad idea. We were able to upgrade pieces of it at a time, move on to React, and now the entire thing is using React and just has the Backbone router and models and stuff like that that we already had, so it's a lot faster.
jQuery is used mostly because I needed jQuery UI for the modal dialog. Otherwise, I use it to reference DOM elements when I'm too lazy to type "document.getElementById(...)".
The Ajax calls you can make with jQuery makes integrating the front end with the back end very smooth.
jQuery has it's quirks, but they're well understood. We opted for a more traditional web app using older, more well-tested technologies like jQuery instead of newer "single page application" type apps.
copy and hack menu.js file if meeting SG issues
Frontend utility library. Use was fairly minimal: lodash, ReactJS, and 'native' ES6 functions now fill the gap jQuery used cover. Will likely be removed in an upcoming iteration.
Used jQuery for web application development, created button responsed to right/center/left button mouse click events in web application.
Extremely versatile integration with views. Easy to create forms, interaction, animation and comms with backend service.
→ My Stack
jquery가 없었다면 저는 프론트엔드를 정말 어려워했을 것입니다. jquery를 좋아하고 사용하는데 부담이 딱히 없으며 문서를 보고 새로운 함수 등을 익히는 중입니다.
jQuery is used offload some of the work to the client (browser) so not everything has to be done on the server side.
jQuery's pretty useful for DOM manipulations within Angular directives. We're considering switching to a lighter-weight alternative though, such as Zepto.
The best known DOM manipulation library we know of. Still not a silver buller.
Also, its Deferred object is very useful.
I only use the modal dialog thingy in jQuery UI, which displays when the player is not currently playing. I'm not big on the DOM and so it would have taken me a lifetime to figure out how to do this on my own, as compared to the 5 minutes to install jQuery UI and invoke it.
The JQuery libraries are embedded in my home page that allow my site to be viewed the way I want them to.