5 ms·

If you have even medium complexity you're better off using something like React with Babel or Typescript. Much more sane way of event handling than JQuery, and

If you have even medium complexity you're better off using something like React with Babel or Typescript. Much more sane way of event handling than JQuery, and no mucking with HTML by hand. I agree with JQuery for the most simple sites, but React+transpiler will give you much better compatibility

ergo14 8y ago
Thing is react is only compatible with react ;-)
- thermodynthrway 8y ago
  It's extremely easy to use React in small parts of the page and spread it out over time. It's a couple lines of code to init React in a div and fully supported. You can even communicate between React bits spread across the page. React also let's you mark areas/divs within its domain as "don't touch this". So in those areas you can use things like that old map widget you love so much, without resorting to iframes Angular is a huge fail in this regard. Zero support for mixing with "non angular" pages.
  - FLUX-YOU 8y ago
    Angular is a nightmare for complex UI interactions for components that are spread out. I'm sure experienced people know how to do that properly, but it's really difficult starting out.
    - thermodynthrway 8y ago
      Angular's learning curve is the worst I've ever seen. We mostly use it because "Enterprise" but I prefer React when we get permission for that reason. Too much abstraction, too much magic. It's possible to do just about anything but the docs are sparse enough that you'll be crawling through github PR's and source to figure out how to achieve it sometimes
    - EugeneOZ 8y ago
      Angular is an amazing tool for building reusable components and interoperation between them is pretty easy to implement (just use "input/output" handlers). I'm not saying it just to say something opposite, it is really my opinion and it's what I do almost every day.
  - feverdream 8y ago
    Can you elaborate on this? In my limited experience with React, it takes over your whole application, or at least the whole page. How do you mark areas as "don't touch this"?
    - kroltan 8y ago
      I'm not sure on the "don't touch this" part, but in regards to "taking over the application", it certainly doesn't. React's entry point is the `ReactDOM.render` function, which takes some React elements, and a root node. that root node can be _any_ DOM node (Actually no idea if you can mount React into a inline SVG, but at least any _HTML_ node you certainly can). You can also have multiple `ReactDOM.render` calls, no problem at all. That initial React element can very well take values and callbacks from your Angular or whatever application. It can get messy if you nest `ReactDOM.render` within roots that are managed by React, but so would nesting any other UI framework, but the use cases for that are... Exuberantly exotic, to say the least.
    - thermodynthrway 8y ago
      I haven't had to do so much myself, but the docs have decent info on how to obtain it. https://reactjs.org/docs/integrating-with-other-libraries.html https://reactjs.org/docs/integrating-with-other-libraries.ht...
    - testvox 8y ago
      React components mount to any element you want. And everything they do will happen within that element if you are using react conventionally. There is no issue mounting components alongside/inside legacy apps.
    - mhink 8y ago
      So, the way to look at it is that you “mount” a React application at a specific part of the DOM. Anything under that point is managed by React components. Usually, people have a single “mount point” very close to the <body> element, and a single script file whose primary purpose is to call ReactDOM.render to “mount” a React component representing their application at that point. However, that doesn’t prevent you from having DOM outside that mount point, and it doesn’t prevent you from having code which does other things that don’t have anything to do with the React-managed part of the page. This is a great way to migrate a legacy application to React: you choose one small section of your page to replace with React, and then have the remainder of your page interact with it by 1.) choosing when to call ReactDOM.render again to ask it to update, and 2.) passing in callbacks so the React ”mini-app” can notify the rest of your application when something happens. You can go the other way, too, although it’s a little less safe. If you have a React component which renders, say, a <div> with no children, you can get a handle to the DOM element itself and interact with it just like you would in a non-React application. The only constraint here is that you have to make sure to clean up e.g. event handlers and release references to those elements if something causes the “owner” React component to unmount. This is how people make wrapper libraries which let you use non-React-based libraries using React components. (I’ve done this in a side project where I had a huge number homogenous DOM elements to work with, and found that managing them myself was much more performant than trying to run them through React’s model.)
  - EugeneOZ 8y ago
    All what you describe in this commentary is much more easy to implement with just jQuery. Your logic more looks like "I can do it with React so it means I should and I believe it's the best tool".
    - girvo 8y ago
      Until you’ve got some moderately complex state and infrastructure to handle it, where you end up recreating the whole State -> Render loop of React in jQuery. I recently did this. It works, well, and with less bugs than most hacky jQuery DOM modification, but by the end I was pining for any other modern view library that already solved this. Same reason I used to pine for jQuery on some projects.
- skeoh 8y ago
  Can you elaborate on this? I've integrated React into Angular and Ember projects in the past with no compatibility issues.
  - ergo14 8y ago
    Did the "foreign" elements stamp out react elements or interact with their properties?
    - skeoh 8y ago
      I tried not to have multiple frameworks controlling the same DOM elements. It would usually be a React component mounted to a DOM element controlled by a component in another framework.
      - ergo14 8y ago
        Exactly, that is my problem, if a react component state is altered by "outside world", weird things can happen. So you actually avoided interoperability between solutions.
samueldavid 8y ago
why not Vue?
- lucasmullens 8y ago
  "something like React" includes Vue.
interlocutor 8y ago
React is great for rendering (and updating after initial render), but if your app is highly interactive then jQuery makes things easier even when using React for rendering.
- thermodynthrway 8y ago
  You generally don't mix react and JQuery. The event system + JSX makes jQuery obsolete. Having worked in complex interactive React/Angular apps as well as ones using JQuery, nobody would ever offer me enough to use JQuery again for this use case. They would have to double my pay for all the pain
  - interlocutor 8y ago
    Show me a dropdown menu written in React and I'll show you how you can simplify the code significantly by using jQuery in addition to React.
    - squiggleblaz 8y ago
      Can you be more concrete? If you want some specific code to criticise, there's dozens of dropdown menu widgets available: here's one I found in Google https://github.com/react-component/menu https://github.com/react-component/menu since I've never actually had reason to use a js/html drop down menu widget.
      - interlocutor 8y ago
        Here's one that uses jQuery. See how much simpler it is? The one you found does have more functionality, but try rewriting the one I found in React without using jQuery. I guarantee it will be much more complicated. https://github.com/wisercoder/uibuilder/blob/master/SimpleDemo/Views/ReusableComponents/PopupMenu.tsx https://github.com/wisercoder/uibuilder/blob/master/SimpleDe...
        thermodynthrway 8y ago
EB66 8y ago
It sounds like you're saying using jQuery and a modern component-ized front-end framework are mutually exclusive. jQuery and modern front-end components can go together very easily -- albeit not specifically with React and Vue. Our company built an in-house front-end framework heavily inspired by React and Vue. The components built using the framework work with or without jQuery. No manual DOM manipulations, one-way data binding, sane state management, templating, etc. Many of us prefer to use jQuery because of how compact and expressive the syntax is. It really surprises me how many people think that jQuery === old school manual DOM manipulations. It definitely doesn't have to be that way.

ergo14 8y ago

Thing is react is only compatible with react ;-)

thermodynthrway 8y ago
It's extremely easy to use React in small parts of the page and spread it out over time. It's a couple lines of code to init React in a div and fully supported. You can even communicate between React bits spread across the page. React also let's you mark areas/divs within its domain as "don't touch this". So in those areas you can use things like that old map widget you love so much, without resorting to iframes Angular is a huge fail in this regard. Zero support for mixing with "non angular" pages.
- FLUX-YOU 8y ago
  Angular is a nightmare for complex UI interactions for components that are spread out. I'm sure experienced people know how to do that properly, but it's really difficult starting out.
  - thermodynthrway 8y ago
    Angular's learning curve is the worst I've ever seen. We mostly use it because "Enterprise" but I prefer React when we get permission for that reason. Too much abstraction, too much magic. It's possible to do just about anything but the docs are sparse enough that you'll be crawling through github PR's and source to figure out how to achieve it sometimes
  - EugeneOZ 8y ago
    Angular is an amazing tool for building reusable components and interoperation between them is pretty easy to implement (just use "input/output" handlers). I'm not saying it just to say something opposite, it is really my opinion and it's what I do almost every day.
- feverdream 8y ago
  Can you elaborate on this? In my limited experience with React, it takes over your whole application, or at least the whole page. How do you mark areas as "don't touch this"?
  - kroltan 8y ago
    I'm not sure on the "don't touch this" part, but in regards to "taking over the application", it certainly doesn't. React's entry point is the `ReactDOM.render` function, which takes some React elements, and a root node. that root node can be _any_ DOM node (Actually no idea if you can mount React into a inline SVG, but at least any _HTML_ node you certainly can). You can also have multiple `ReactDOM.render` calls, no problem at all. That initial React element can very well take values and callbacks from your Angular or whatever application. It can get messy if you nest `ReactDOM.render` within roots that are managed by React, but so would nesting any other UI framework, but the use cases for that are... Exuberantly exotic, to say the least.
  - thermodynthrway 8y ago
    I haven't had to do so much myself, but the docs have decent info on how to obtain it. https://reactjs.org/docs/integrating-with-other-libraries.html https://reactjs.org/docs/integrating-with-other-libraries.ht...
  - testvox 8y ago
    React components mount to any element you want. And everything they do will happen within that element if you are using react conventionally. There is no issue mounting components alongside/inside legacy apps.
  - mhink 8y ago
    So, the way to look at it is that you “mount” a React application at a specific part of the DOM. Anything under that point is managed by React components. Usually, people have a single “mount point” very close to the <body> element, and a single script file whose primary purpose is to call ReactDOM.render to “mount” a React component representing their application at that point. However, that doesn’t prevent you from having DOM outside that mount point, and it doesn’t prevent you from having code which does other things that don’t have anything to do with the React-managed part of the page. This is a great way to migrate a legacy application to React: you choose one small section of your page to replace with React, and then have the remainder of your page interact with it by 1.) choosing when to call ReactDOM.render again to ask it to update, and 2.) passing in callbacks so the React ”mini-app” can notify the rest of your application when something happens. You can go the other way, too, although it’s a little less safe. If you have a React component which renders, say, a <div> with no children, you can get a handle to the DOM element itself and interact with it just like you would in a non-React application. The only constraint here is that you have to make sure to clean up e.g. event handlers and release references to those elements if something causes the “owner” React component to unmount. This is how people make wrapper libraries which let you use non-React-based libraries using React components. (I’ve done this in a side project where I had a huge number homogenous DOM elements to work with, and found that managing them myself was much more performant than trying to run them through React’s model.)
- EugeneOZ 8y ago
  All what you describe in this commentary is much more easy to implement with just jQuery. Your logic more looks like "I can do it with React so it means I should and I believe it's the best tool".
  - girvo 8y ago
    Until you’ve got some moderately complex state and infrastructure to handle it, where you end up recreating the whole State -> Render loop of React in jQuery. I recently did this. It works, well, and with less bugs than most hacky jQuery DOM modification, but by the end I was pining for any other modern view library that already solved this. Same reason I used to pine for jQuery on some projects.
skeoh 8y ago
Can you elaborate on this? I've integrated React into Angular and Ember projects in the past with no compatibility issues.
- ergo14 8y ago
  Did the "foreign" elements stamp out react elements or interact with their properties?
  - skeoh 8y ago
    I tried not to have multiple frameworks controlling the same DOM elements. It would usually be a React component mounted to a DOM element controlled by a component in another framework.
    - ergo14 8y ago
      Exactly, that is my problem, if a react component state is altered by "outside world", weird things can happen. So you actually avoided interoperability between solutions.

samueldavid 8y ago

why not Vue?

lucasmullens 8y ago
"something like React" includes Vue.

interlocutor 8y ago

React is great for rendering (and updating after initial render), but if your app is highly interactive then jQuery makes things easier even when using React for rendering.

thermodynthrway 8y ago
You generally don't mix react and JQuery. The event system + JSX makes jQuery obsolete. Having worked in complex interactive React/Angular apps as well as ones using JQuery, nobody would ever offer me enough to use JQuery again for this use case. They would have to double my pay for all the pain
- interlocutor 8y ago
  Show me a dropdown menu written in React and I'll show you how you can simplify the code significantly by using jQuery in addition to React.
  - squiggleblaz 8y ago
    Can you be more concrete? If you want some specific code to criticise, there's dozens of dropdown menu widgets available: here's one I found in Google https://github.com/react-component/menu https://github.com/react-component/menu since I've never actually had reason to use a js/html drop down menu widget.
    - interlocutor 8y ago
      Here's one that uses jQuery. See how much simpler it is? The one you found does have more functionality, but try rewriting the one I found in React without using jQuery. I guarantee it will be much more complicated. https://github.com/wisercoder/uibuilder/blob/master/SimpleDemo/Views/ReusableComponents/PopupMenu.tsx https://github.com/wisercoder/uibuilder/blob/master/SimpleDe...
      - thermodynthrway 8y ago

EB66 8y ago

It sounds like you're saying using jQuery and a modern component-ized front-end framework are mutually exclusive. jQuery and modern front-end components can go together very easily -- albeit not specifically with React and Vue. Our company built an in-house front-end framework heavily inspired by React and Vue. The components built using the framework work with or without jQuery. No manual DOM manipulations, one-way data binding, sane state management, templating, etc. Many of us prefer to use jQuery because of how compact and expressive the syntax is. It really surprises me how many people think that jQuery === old school manual DOM manipulations. It definitely doesn't have to be that way.