4 ms·
Yet another reason to dislike JSX apparently: its parser deviates from the HTML5 spec. And at this point JSX is so well established (ossified?), fixing it would
by ttfkam 3y ago
Yet another reason to dislike JSX apparently: its parser deviates from the HTML5 spec. And at this point JSX is so well established (ossified?), fixing it would break countless sites when upgrading.
- WesolyKubeczek 3y agoIt needs to be transpiled anyway, so what could break. JSX is not HTML.
- ttfkam 3y agoThe point is that the transpiled output doesn't match the intent of the input. Did y'all not actually read the article?
- solardev 3y agoI think it's more a reason to ignore the HTML specs. They've never really meant anything and JSX is the closest thing to an actual standard that the web world has ever seen.
- jraph 3y agoI don't think so. The HTML5 parsing spec is very precise now, and browsers follow it. To my knowledge, how you parse an HTML document is now very well defined. Plus, JSX isn't even served to browsers at all. Now, I don't agree with the parent that it's wrong that JSX parses differently than HTML. They got rid of the issues caused by indentation and spacing code ending up meaning something and causing a different rendering than non spaced HTML document, which is a good thing. It could also totally be fixed if needed, you define version of your dependencies in charge of interpreting it. HTML is the "unfixable" one.
- spankalee 3y agoWhat? HTML is actually standardized by a standards body. JSX isn't close to that. There's a grammar on an old web page, that's it.
- SahAssar 3y agoWhat do you mean?! The HTML standard is very consistent across browsers these days, while JSX is not an actual standard for how to format documents, its just an alternate interface to write JS expressions.
- solardev 3y agoFirst, "standards"-compliant HTML was never that important because the browsers were all so tolerant of malformed HTML anyway, and continue to be. And these days, the standards matter even less when there's really just Webkit and Blink. Gecko is a rounding error. You can write strict HTML to your heart's delight, or just kinda half-ass it. It doesn't really matter either way, since most users will use the same renderer anyway. Then, even if you DO adhere to strict standards, they are so low level as to be useless. HTML + CSS defines a barebones, ancient layout system for simple documents -- which most of the web isn't anymore. Want to do a simple nav bar? There is no simple "nav bar" standard. You hack it by overloading a list and repositioning the components using CSS, then sprinkle in ARIA args on top of these overloaded components to tell the screen reader exactly how you decided to abuse the markup. Want to do a responsive popup modal with a scrollable table inside? You create your own recipe for tag soup, with your own media queries and wraps and scrollbar hacks and hidden elements. And every dev ends up doing this. At the level of abstraction of an actual UI, there isn't a standard, just different hacks on top of HTML. "Semantic" HTML and JSON-LD etc. all came and went. In the end you have every webpage reinventing the wheel to create the simplest of UIs, because there wasn't really a "standard", just super low level rendering primitives. There is no real system for componentization or templatization, and every server side language invented their own. Enter JSX, which primarily gives you a more useful system of abstraction: that of components, composition, and inheritance, rather than meaningless tags like "div" or "span". This system allowed the creation of an ecosystem (as opposed to snippets) where different packages from different teams (or companies, or OSS) can interact by passing parameters/properties back and forth, something that was pretty much impossible to do when you were just overlaying HTML on itself (early jQuery libs tried to do that and ran into constant problems with clashing event handlers, z-axis issues, CSS namespace conflicts, etc.). From there you can create style and component systems (like MUI or Chakra), or roll your company's own, from which downstream app and UI designers can actual compose business applications. This was all just basic functionality offered by the likes of WinForms and Visual Studio back in the 90s or before, but which HTML never really had until JSX took over. Then from there we got an extensive ecosystem of powerful typing, transpilation (including to native and Electron), linting, etc., all built on top of simple syntax and somewhat reusable components. There's a very simple reason React took over and became the real defacto standard: It was useful. JSX outside React also sees adoption from other frameworks because it is useful. Purity is meaningless and pointless. Whatever standards are set today will be reinvented and ignored and superseded by the next big company or movement. From Netscape to Microsoft to Meta, every major company overloaded HTML because it was (and remains) uselessly low level. CSS and JS themselves took years to be adopted and fought long wars against ActiveX, Flash, and even Canvas -- again because HTML was so limited. JSX frees you from the underlying rendering concerns (which users don't really care about, and frankly most devs and managers don't either) in favor of UI components and useful business logic. Even if the resulting output can still be tag soup (if you don't use a good UI framework), at least it's consistent tag soup because of component reusability and inheritance. And in the best cases, it can generate much cleaner output than HTML because you start from strictly typed and strictly linted XML-like syntax instead of overloaded HTML tags and CSS overrides, giving you a degree of intra-codebase consistency that's very difficult to achieve, and inter-package interoperability that was straight on impossible in the past. I'd argue that JSX and React are the best things to have happened to the Web since, oh, I don't know... the image map?
- bunga-bunga 3y agoI'm fine with JSX being stricter. "HTML soup" is extremely hard and slow to parse, compared to JSX. The community gave up shipping strict XHTML to the browser because the breakage could happen at runtime, whereas JSX disappears (and shows errors) at build time, so you can't ship broken JSX.
- regularfry 3y agoIn the "Helloworld" example given it's not stricter, it's a different incompatible choice.
- chromakode 3y agoI've written HTML for at least 20 years and far prefer the JSX syntax. It's simpler to learn and remember and has clearer whitespace behavior. JSX doesn't need to confirm to HTML5. Given the web's backwards compatibility requirements, something like JSX is the most successful way to create a stricter subset.
- sebazzz 3y agoJSX is not HTML, it imitates HTML. It is fine for it to deviate. You don’t use attributes, but properties, like className.
- ttfkam 3y agoHTML as rendered in browsers is the target. Aliases are one thing. Not matching up to the target after rendering is quite another.