|Hacker News, Reddit, Stack Overflow Stats|
|Why people like using this service||
|Companies using this service|
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.
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 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.
The JQuery libraries are embedded in my home page that allow my site to be viewed the way I want them to.