4 ms·

Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is bec

Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in separate files, or making use of a DSL, that treats HTML as structured data, say for example SXML. Also there are issues with that custom HTML-look-alike preprocessor, because you cannot write class="...", because then somehow it gets syntactically confused, because "class" is now a keyword in JS. This all feels rather half-baked. Why can't the parser/prprocessor distinguish between that "class" and "class" in JS source code? We can have reusable HTML snippets (some may call components) with normal templating engines easily. Look at something like Jinja2 and how to reuse blocks and macros. Yes, some React component can encapsulate its own interactive behavior. That is only because we are already writing JS though, so we can already write frontend logic. But do we actually want that? Coupling state and behavior? I think we might not. Writing a script that gets served only on those rendered templates, where it is needed is not so hard either, when using a normal templating engine.

wayfinder 3y ago
Your criticism was the biggest one of React when it came out -- mixing view code with your controller code. Big no no. Everyone loved the MVC pattern (model-viewer-controller where you separate these things in different places) and what React did was a big no no. But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. In other languages, you can just put your template in a separate file and load it from your package/.jar/assembly. Super easy and most importantly, 100% standard and provided by the environment. So people just settled with React because it worked and no successfully invented a standard bundle format for the web. F' it we said.
- nostrademons 3y ago
  > But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. It's not actually, with HTTP/2. The separate requests are all multiplexed over the same connection, often with prefetching, and compressed together so that there's little to no overhead vs. putting them in the same file. This illustrates a common failure point for web frameworks though. They encode a lot of folk knowledge about how the web works, but that folk knowledge becomes obsolete as browsers change. Another prominent React example fits into this category: the virtual DOM. React assumed that DOM manipulations were slow and Javascript manipulations were fast, and so they built up an internal representation of the DOM in Javascript so they could manipulate that one and diff the change to apply it to the real DOM. This was true from approximately 2008 (when V8 introduced JS JITting) to 2013 (when Blink/Webkit/Firefox all moved to a dirty-bit system for DOM manipulations), which not coincidentally is when React was designed. But since then, DOM manipulation has been just pointer swaps and a dirty bit flip, and if you're careful not to invoke any operation that triggers a reflow and repaint you can make your modifications directly in the DOM for roughly the same cost as making them in JS. Since React is declarative it could easily have enforced the no-reflow rules without the virtual DOM, but because DOM manipulations were expensive when its designers learned web programming, it introduces an unnecessary concept.
  - wayfinder 3y ago
    Oh I'm aware, but I'm talking historically. But HTTP/2 is not the right example. You're missing some things on the web timeline. Long before HTTP/2 (time in web terms), and after React (and Angular, etc.) came about, people created actually-popular bundler toolchains that can bundle arbitrary files together and then incrementally load them as needed. This effectively fixed the multiple HTTP request problem long before HTTP/2 existed. Efficient template files have been possible for years. (Granted, not anything standard though.) The issue right now is that someone has to make a full toolchain with strong developer support to make this a de-facto and popular way to distribute apps. Just because you have a bundler or HTTP/2 doesn't mean you have a nice way to make use of it. You need a nice library. Your usage examples need to look pretty. It needs to work with other toolchains. It needs to look like your library will be supported for a long time, just like how React was supported by Facebook. You can't just write a blog post about how it's possible because you're basically asking your readers to invent and maintain a library or worse, roll their own internal library that will confound people at their company.
- throwaway_1987 3y ago
  >But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. Most projects that I have been involved with have some kind of build system that does all sort of magic. It should be possible to include the template in the JS file during the build process
  - nicoburns 3y ago
    Yep, and that's what was being done before React existed. JSX took over because people (including me) prefer to have the full power of JavaScript for their templates rather than a half-based templating language.
  - deleted 3y ago
    [deleted]
nightski 3y ago
Except it's not half baked. Because guess what - now you need a new template language that supports constructs like conditionals, loops, etc... You basically end up implementing a half-baked version of javascript with an unfamiliar syntax. Even worse they need to interact with state. Many template engines introduce some sort of "data binding" abomination which is a complex way of saying how you want the state to interact with the view. React is simple. Here is your data, and here is a function that transforms that data into a view. Templates are terrible, and that is a hill I am willing to die on.
- zelphirkalt 3y ago
  > React is simple. Here is your data, and here is a function that transforms that data into a view. Is that aspect so much different from templating engines? In templating engines the rendering step is simply abstracted one step further: You get a generalized render function, that you pass data to and a template to render with that data. That is also a function to turn your data into a view. I don't see how React is better in that aspect.
tubthumper8 3y ago
> Also there are issues with that custom HTML-look-alike preprocessor, because you cannot write class="...", because then somehow it gets syntactically confused, because "class" is now a keyword in JS. > This all feels rather half-baked. Why can't the parser/prprocessor distinguish between that "class" and "class" in JS source code? Remember that React is "just JavaScript", JSX is a syntax transformation of JavaScript. When you use `className` in your JSX, you're using the standard DOM Attribute [1]. You wouldn't use `class` either in vanilla JS to set the CSS class, you'd use `className`. https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
- zelphirkalt 3y ago
  However, that means, that now one has something, that is neither looking like HTML, nor is it looking like JS, even if it may be JS through some pre-processing (but then actually it is not really JS?). The result is, that one has to learn some different syntax that is specific to React. If there is already a preprocessing step, why not preprocess `class` instead of `className`, to get closer to normal HTML syntax? In a usual templating engine valid HTML is also valid template. One does not have to use templating engine specific things. A HTML snippet can simply be HTML. No harm done. But in JSX one cannot use normal HTML, as shown by the `class` case.
  - tubthumper8 3y ago
    I think you're hung up on JSX being HTML - it isn't HTML and doesn't try to be. The "JS" stands for "JavaScript" and the "X" stands for XML, not HTML. > However, that means, that now one has something, that is neither looking like HTML, nor is it looking like JS, even if it may be JS through some pre-processing (but then actually it is not really JS?). Yes, it's not HTML or JS, it is JSX. It's an XML-based syntax to declaratively write JavaScript. It's optional too - one can write the function calls directly in JS, and indeed that's what people did before JSX existed. `React.createElement("div", React.creatElement("span"),...)`. It could be worth using a REPL [1] to gain an intuition of the JavaScript that is produced from transforming different JSX examples. > The result is, that one has to learn some different syntax that is specific to React. JSX was originally created for React, but now is not specific to React, other libraries and frameworks use it as well. It's a general purpose XML-based syntax for writing JavaScript declaratively. And yeah, if you want to use JSX you have to learn it. It's easy to learn if you know JavaScript and XML and shouldn't take very long. It's XML and then anything inside curly braces is a JavaScript expression. If you're using TypeScript replace everything "JS" I'm saying with "TS", it's the same result. And obviously type checking works without issue because it's a syntactic transformation to TS, not a semantic transformation. > In a usual templating engine valid HTML is also valid template. One does not have to use templating engine specific things. JSX is not an HTML templating engine [2]. JSX is a way to write JavaScript declaratively using an XML-based syntax. > But in JSX one cannot use normal HTML, as shown by the `class` case. Yes, as expected. JSX is not an HTML templating engine, it's a way to write JavaScript declaratively using an XML-based syntax. In JavaScript, you use the DOM APIs [3], not HTML attributes [4]. [1]: https://babeljs.io/repl https://babeljs.io/repl [2]: https://legacy.reactjs.org/docs/introducing-jsx.html https://legacy.reactjs.org/docs/introducing-jsx.html [3]: https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob... [4]: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes

wayfinder 3y ago

Your criticism was the biggest one of React when it came out -- mixing view code with your controller code. Big no no. Everyone loved the MVC pattern (model-viewer-controller where you separate these things in different places) and what React did was a big no no. But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. In other languages, you can just put your template in a separate file and load it from your package/.jar/assembly. Super easy and most importantly, 100% standard and provided by the environment. So people just settled with React because it worked and no successfully invented a standard bundle format for the web. F' it we said.

nostrademons 3y ago
> But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. It's not actually, with HTTP/2. The separate requests are all multiplexed over the same connection, often with prefetching, and compressed together so that there's little to no overhead vs. putting them in the same file. This illustrates a common failure point for web frameworks though. They encode a lot of folk knowledge about how the web works, but that folk knowledge becomes obsolete as browsers change. Another prominent React example fits into this category: the virtual DOM. React assumed that DOM manipulations were slow and Javascript manipulations were fast, and so they built up an internal representation of the DOM in Javascript so they could manipulate that one and diff the change to apply it to the real DOM. This was true from approximately 2008 (when V8 introduced JS JITting) to 2013 (when Blink/Webkit/Firefox all moved to a dirty-bit system for DOM manipulations), which not coincidentally is when React was designed. But since then, DOM manipulation has been just pointer swaps and a dirty bit flip, and if you're careful not to invoke any operation that triggers a reflow and repaint you can make your modifications directly in the DOM for roughly the same cost as making them in JS. Since React is declarative it could easily have enforced the no-reflow rules without the virtual DOM, but because DOM manipulations were expensive when its designers learned web programming, it introduces an unnecessary concept.
- wayfinder 3y ago
  Oh I'm aware, but I'm talking historically. But HTTP/2 is not the right example. You're missing some things on the web timeline. Long before HTTP/2 (time in web terms), and after React (and Angular, etc.) came about, people created actually-popular bundler toolchains that can bundle arbitrary files together and then incrementally load them as needed. This effectively fixed the multiple HTTP request problem long before HTTP/2 existed. Efficient template files have been possible for years. (Granted, not anything standard though.) The issue right now is that someone has to make a full toolchain with strong developer support to make this a de-facto and popular way to distribute apps. Just because you have a bundler or HTTP/2 doesn't mean you have a nice way to make use of it. You need a nice library. Your usage examples need to look pretty. It needs to work with other toolchains. It needs to look like your library will be supported for a long time, just like how React was supported by Facebook. You can't just write a blog post about how it's possible because you're basically asking your readers to invent and maintain a library or worse, roll their own internal library that will confound people at their company.
throwaway_1987 3y ago
>But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. Most projects that I have been involved with have some kind of build system that does all sort of magic. It should be possible to include the template in the JS file during the build process
- nicoburns 3y ago
  Yep, and that's what was being done before React existed. JSX took over because people (including me) prefer to have the full power of JavaScript for their templates rather than a half-based templating language.
- deleted 3y ago
  [deleted]

nightski 3y ago

Except it's not half baked. Because guess what - now you need a new template language that supports constructs like conditionals, loops, etc... You basically end up implementing a half-baked version of javascript with an unfamiliar syntax. Even worse they need to interact with state. Many template engines introduce some sort of "data binding" abomination which is a complex way of saying how you want the state to interact with the view. React is simple. Here is your data, and here is a function that transforms that data into a view. Templates are terrible, and that is a hill I am willing to die on.

zelphirkalt 3y ago
> React is simple. Here is your data, and here is a function that transforms that data into a view. Is that aspect so much different from templating engines? In templating engines the rendering step is simply abstracted one step further: You get a generalized render function, that you pass data to and a template to render with that data. That is also a function to turn your data into a view. I don't see how React is better in that aspect.

tubthumper8 3y ago

> Also there are issues with that custom HTML-look-alike preprocessor, because you cannot write class="...", because then somehow it gets syntactically confused, because "class" is now a keyword in JS. > This all feels rather half-baked. Why can't the parser/prprocessor distinguish between that "class" and "class" in JS source code? Remember that React is "just JavaScript", JSX is a syntax transformation of JavaScript. When you use `className` in your JSX, you're using the standard DOM Attribute [1]. You wouldn't use `class` either in vanilla JS to set the CSS class, you'd use `className`. https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

zelphirkalt 3y ago
However, that means, that now one has something, that is neither looking like HTML, nor is it looking like JS, even if it may be JS through some pre-processing (but then actually it is not really JS?). The result is, that one has to learn some different syntax that is specific to React. If there is already a preprocessing step, why not preprocess `class` instead of `className`, to get closer to normal HTML syntax? In a usual templating engine valid HTML is also valid template. One does not have to use templating engine specific things. A HTML snippet can simply be HTML. No harm done. But in JSX one cannot use normal HTML, as shown by the `class` case.
- tubthumper8 3y ago
  I think you're hung up on JSX being HTML - it isn't HTML and doesn't try to be. The "JS" stands for "JavaScript" and the "X" stands for XML, not HTML. > However, that means, that now one has something, that is neither looking like HTML, nor is it looking like JS, even if it may be JS through some pre-processing (but then actually it is not really JS?). Yes, it's not HTML or JS, it is JSX. It's an XML-based syntax to declaratively write JavaScript. It's optional too - one can write the function calls directly in JS, and indeed that's what people did before JSX existed. `React.createElement("div", React.creatElement("span"),...)`. It could be worth using a REPL [1] to gain an intuition of the JavaScript that is produced from transforming different JSX examples. > The result is, that one has to learn some different syntax that is specific to React. JSX was originally created for React, but now is not specific to React, other libraries and frameworks use it as well. It's a general purpose XML-based syntax for writing JavaScript declaratively. And yeah, if you want to use JSX you have to learn it. It's easy to learn if you know JavaScript and XML and shouldn't take very long. It's XML and then anything inside curly braces is a JavaScript expression. If you're using TypeScript replace everything "JS" I'm saying with "TS", it's the same result. And obviously type checking works without issue because it's a syntactic transformation to TS, not a semantic transformation. > In a usual templating engine valid HTML is also valid template. One does not have to use templating engine specific things. JSX is not an HTML templating engine [2]. JSX is a way to write JavaScript declaratively using an XML-based syntax. > But in JSX one cannot use normal HTML, as shown by the `class` case. Yes, as expected. JSX is not an HTML templating engine, it's a way to write JavaScript declaratively using an XML-based syntax. In JavaScript, you use the DOM APIs [3], not HTML attributes [4]. [1]: https://babeljs.io/repl https://babeljs.io/repl [2]: https://legacy.reactjs.org/docs/introducing-jsx.html https://legacy.reactjs.org/docs/introducing-jsx.html [3]: https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob... [4]: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes