6 ms·

One of the reasons why I love webcomponents. It’s a simple api and plays well with the dom. Wanna innerHTML some string? Boom it works. document.createElement(

by nojvek 7y ago

One of the reasons why I love webcomponents. It’s a simple api and plays well with the dom. Wanna innerHTML some string? Boom it works. document.createElement(‘my-foo’). Works. addEventListener. Works. Dom explorer shows the elements. document.querySelector finds your tags. Css just works. Nothing new to learn. Custom elements let you be just another html tag and do your magic. Not fully sold on shadow dom but web components api is simple and I love it.

chrisco255 7y ago
All of these things work with React, too. React appropriately names the prop to "dangerouslySetInnerHtml" because it's vulnerable to XSS attacts and a lot of beginner web developers don't realize that. CSS has of course always worked just fine with React (as does LESS and SASS). Styled-components is totally optional. There's tradeoffs at scale with trying to use an imperative style of coding with document.querySelector or JQuery. Fine for simple websites. Absolutely awful for complex web apps with large teams. Dom explorer is still a tab in Chrome for react devs. I readily switch between the React devtools and Dom explorer all the time. The reason in my mind, for React, is that it's a higher level, functional abstraction above the DOM that makes complex web development manageable.
mosselman 7y ago
One of the downsides, depending on implementation mostly of course, that you still need JS to render your component. I prefer server-side rendered HTML over both React and web components because of the compatibility. After showing the HTML you can still make elements more interactive with things like jQuery, Stimulus or Freudjs (disclaimer: my own)
- danabramov 7y ago
  It’s worth nothing you can do server rendering to HTML with React, too.
  - mosselman 7y ago
    It is, but I meant more in a 'traditional' way, so rendering with some templating engine whose abstractions aren't so far detached from HTML as they are with React. Mostly by mixing some dynamic parts into HTML rather than the other way around.
    - danabramov 7y ago
      What kind of detachment are you referring to? React JSX has a few quirks but it maps pretty straightforwardly to DOM elements and HTML.
      - mosselman 7y ago
        A React application gets applied to a certain DOM element. Inside of that application are multiple layers of containing elements that handle things like routing or processing different events on existing DOM elements or triggered remote calls. If you add redux and something like redux-form you end up with sending each keyup event to the redux store and re-rendering your input fields from that store. So yes the JSX at the very bottom of your software tree is pretty much like HTML, but it takes a whole lot of engineering to get there and variables get pushed through many layers before they reach the final JSX in which they are rendered. Some of this has to do with how you implement your application, but in general getting from input to output takes more steps than it does with a server side rendering framework. This is fine when building something like a mobile application or an off-line-ready application like devdocs.io, but if you use a React application in front of some back-end you are just getting HTML in return for all your engineering efforts. If HTML with a few interactions is all you are after there is too much code and too many layers between the page that has your `<div id='myapp' />` and what you get after React is done rendering.
        danabramov 7y ago
        Sure, I get that. What I'm saying is -- if you prefer to keep things simple and use server rendering, using server rendering alone with React (no routing, Redux, etc) is pretty much identical to using templates. You can treat React itself as a single-pass server template engine with component support. You don't have to bring all of this single-page app stuff into it. Hope that explains my point. You don't even have to run React on the client at all. I'm specifically talking about ReactDOMServer.renderToString() on the server and serving that HTML. Not "mounting into a <div>" client use case.
- ivanhoe 7y ago
  It's great to a point, but when front grows complex enough you sooner or later realize you're repeating a lot of backend logic on the front, and doing a lot of manual labour keeping track of all states, events, etc. What div is visible, which one to hide, which buttons to disable, adding new rows into forms dynamically with pre-populated values... that kind of stuff is way (and I mean waaaay) easier when coded in a declarative reactive way.
  - mosselman 7y ago
    > later realize you're repeating a lot of backend logic on the front So you mean something like keeping state of forms in something like redux and sending out an event every time you press a button so that state gets update and the change is pushed down the tree of elements so that the letter you just pressed gets rendered in the form? Or did you mean client side validations of forms that you also have in your back-end? Obviously you didn't and I am being a bit of an ass, but this is what is the somewhat recommended way of going around this and it is so convoluted. > doing a lot of manual labour keeping track of all states, events, etc. The state of most web applications can be kept inside of DOM elements and the url just fine. > What div is visible, which one to hide, which buttons to disable This is where CSS-classes and the aforementioned JS libraries come in and they do this job just fine. > adding new rows into forms dynamically with pre-populated values... that kind of stuff is way (and I mean waaaay) easier when coded in a declarative reactive way. I don't believe you are right. It is not easier at all to add some DOM elements with React than it is when you use small bits of JS. Let's say you use jQuery, then it is 1 dependency you add with a small wrapper script for your dynamic form, with React you add thousands of dependencies and you have to build your complete application in React just to dynamically add a row in one of the forms. How is that easier? I don't think I'd build Slack mostly using HTML rendering from the back-end, but most of the things that we build are CRUD applications that can easily be built using things like Ruby on Rails. Let's say the Trello's, Githubs and Amazons of our world.
    - ivanhoe 7y ago
      > with React you add thousands of dependencies and you have to build your complete application in React just to dynamically add a row in one of the forms. How is that easier? Because with sufficiently complicated UI you will simply at some point have to start writing abstractions and libraries to help you handle all that mess, and then you'll basically end up building a good part of those "thousands of dependencies" yourself - reinventing the wheel. For smaller projects it's an overkill obviously, no one says you have to use it everywhere. But for bigger projects it's a way more optimal to sacrifice some performance in order to be able to build faster and maintain the project easier, and even if you try to make your own solution chances are that with time it will evolve into something very close to how big players solve it. At least that's what happened to all my custom frameworks (front and backend), 10+ years ago when I myself still believed in not needing extra bloat of frameworks... you one day realize that someone already solved your problem, and solved it way better than you ever would...
- chrisweekly 7y ago
  Are you sure your users require the "compatibility" extreme of disabled JS? SSR and "PRPL"-style hydration are totally compatible with React. See Gatsby's intro docs for a great example.
chrisweekly 7y ago
> "Nothing new to learn." That's an understandable but dangerous attitude for a web developer to take.

by nojvek 7y ago

chrisco255 7y ago

All of these things work with React, too. React appropriately names the prop to "dangerouslySetInnerHtml" because it's vulnerable to XSS attacts and a lot of beginner web developers don't realize that. CSS has of course always worked just fine with React (as does LESS and SASS). Styled-components is totally optional. There's tradeoffs at scale with trying to use an imperative style of coding with document.querySelector or JQuery. Fine for simple websites. Absolutely awful for complex web apps with large teams. Dom explorer is still a tab in Chrome for react devs. I readily switch between the React devtools and Dom explorer all the time. The reason in my mind, for React, is that it's a higher level, functional abstraction above the DOM that makes complex web development manageable.

mosselman 7y ago

One of the downsides, depending on implementation mostly of course, that you still need JS to render your component. I prefer server-side rendered HTML over both React and web components because of the compatibility. After showing the HTML you can still make elements more interactive with things like jQuery, Stimulus or Freudjs (disclaimer: my own)

danabramov 7y ago
It’s worth nothing you can do server rendering to HTML with React, too.
- mosselman 7y ago
  It is, but I meant more in a 'traditional' way, so rendering with some templating engine whose abstractions aren't so far detached from HTML as they are with React. Mostly by mixing some dynamic parts into HTML rather than the other way around.
  - danabramov 7y ago
    What kind of detachment are you referring to? React JSX has a few quirks but it maps pretty straightforwardly to DOM elements and HTML.
    - mosselman 7y ago
      A React application gets applied to a certain DOM element. Inside of that application are multiple layers of containing elements that handle things like routing or processing different events on existing DOM elements or triggered remote calls. If you add redux and something like redux-form you end up with sending each keyup event to the redux store and re-rendering your input fields from that store. So yes the JSX at the very bottom of your software tree is pretty much like HTML, but it takes a whole lot of engineering to get there and variables get pushed through many layers before they reach the final JSX in which they are rendered. Some of this has to do with how you implement your application, but in general getting from input to output takes more steps than it does with a server side rendering framework. This is fine when building something like a mobile application or an off-line-ready application like devdocs.io, but if you use a React application in front of some back-end you are just getting HTML in return for all your engineering efforts. If HTML with a few interactions is all you are after there is too much code and too many layers between the page that has your `<div id='myapp' />` and what you get after React is done rendering.
      - danabramov 7y ago
        Sure, I get that. What I'm saying is -- if you prefer to keep things simple and use server rendering, using server rendering alone with React (no routing, Redux, etc) is pretty much identical to using templates. You can treat React itself as a single-pass server template engine with component support. You don't have to bring all of this single-page app stuff into it. Hope that explains my point. You don't even have to run React on the client at all. I'm specifically talking about ReactDOMServer.renderToString() on the server and serving that HTML. Not "mounting into a <div>" client use case.
ivanhoe 7y ago
It's great to a point, but when front grows complex enough you sooner or later realize you're repeating a lot of backend logic on the front, and doing a lot of manual labour keeping track of all states, events, etc. What div is visible, which one to hide, which buttons to disable, adding new rows into forms dynamically with pre-populated values... that kind of stuff is way (and I mean waaaay) easier when coded in a declarative reactive way.
- mosselman 7y ago
  > later realize you're repeating a lot of backend logic on the front So you mean something like keeping state of forms in something like redux and sending out an event every time you press a button so that state gets update and the change is pushed down the tree of elements so that the letter you just pressed gets rendered in the form? Or did you mean client side validations of forms that you also have in your back-end? Obviously you didn't and I am being a bit of an ass, but this is what is the somewhat recommended way of going around this and it is so convoluted. > doing a lot of manual labour keeping track of all states, events, etc. The state of most web applications can be kept inside of DOM elements and the url just fine. > What div is visible, which one to hide, which buttons to disable This is where CSS-classes and the aforementioned JS libraries come in and they do this job just fine. > adding new rows into forms dynamically with pre-populated values... that kind of stuff is way (and I mean waaaay) easier when coded in a declarative reactive way. I don't believe you are right. It is not easier at all to add some DOM elements with React than it is when you use small bits of JS. Let's say you use jQuery, then it is 1 dependency you add with a small wrapper script for your dynamic form, with React you add thousands of dependencies and you have to build your complete application in React just to dynamically add a row in one of the forms. How is that easier? I don't think I'd build Slack mostly using HTML rendering from the back-end, but most of the things that we build are CRUD applications that can easily be built using things like Ruby on Rails. Let's say the Trello's, Githubs and Amazons of our world.
  - ivanhoe 7y ago
    > with React you add thousands of dependencies and you have to build your complete application in React just to dynamically add a row in one of the forms. How is that easier? Because with sufficiently complicated UI you will simply at some point have to start writing abstractions and libraries to help you handle all that mess, and then you'll basically end up building a good part of those "thousands of dependencies" yourself - reinventing the wheel. For smaller projects it's an overkill obviously, no one says you have to use it everywhere. But for bigger projects it's a way more optimal to sacrifice some performance in order to be able to build faster and maintain the project easier, and even if you try to make your own solution chances are that with time it will evolve into something very close to how big players solve it. At least that's what happened to all my custom frameworks (front and backend), 10+ years ago when I myself still believed in not needing extra bloat of frameworks... you one day realize that someone already solved your problem, and solved it way better than you ever would...
chrisweekly 7y ago
Are you sure your users require the "compatibility" extreme of disabled JS? SSR and "PRPL"-style hydration are totally compatible with React. See Gatsby's intro docs for a great example.

chrisweekly 7y ago

> "Nothing new to learn." That's an understandable but dangerous attitude for a web developer to take.