In order to get that freedom, you need to build the tooling in such a way that it aligns with the web standards, so that when the standards catch up you can drop what you don't actually need anymore. We all switched from coffescript to ES6 and Babel because ES6, being standards-based, will eventually be supported in browsers, right?
And yet, with JSX we have a gratuitously non-standard dialect of JavaScript that isn't on the standards track and will never be natively supported in browsers. So, even when browsers catch up and offer full support for modern ES6 syntax, we're still stuck with transpilers because Facebook thought it was a good idea to tightly couple their custom templating language to JavaScript itself instead of wrapping it in template literals, which is the standards-based approach that ES6 actually provides for embedded DSLs and templating.
Today, in Europe and North America, roughly ~85% of users run a browser version that has native ES6 support. IE marketshare fell off a cliff in 2016, and now IE11 is at less than five percent and still falling. I don't actually need to transpile during development today, and I won't need to do it in production either in a year or two, and yet everything written with JSX will need a transpiler forever.
It just gets compiled down to native javascript. JSX is also optional in React - meaning that you don't have to use it. And having an actual client-side data-structure to represent DOM is arguably better than using string based templates which is what folks have been using for decades.
Also, compilation is not a dirty word - when you consider just how primitive the standard language is. A static type-checking compilation pass also helps keep large codebases/modules manageable, and aids refactoring by being able to catch errors - without actually having to run the code to figure out what it does.
It's true that there is unnecessary fragmentation. But the broad trend reveals that front-end development is actually starting to catch up with best-practice.
No, a lot of us switched to ClojureScript, TypeScript, Elm, etc and don't look back.
As long as you have to transpile, why not transpile from a good language? (Not to say that native ES6 support would compensate for the advantages of the abovementioned languages)
Standards are not generally virtuous in programming languages. They tend to come about to mitigate language fragmentation between rival factions, something that most good and popular languages don't have a problem with.
Though there's a good argument for just blessing the most popular implementation as "the spec". Paper specs have bugs too, and they always live in a kind of shadow world vs real life.
Things that aren't theoretically specified are relied upon in real life. See eg the Java and C standards. In Java's case nobody cares what the standard is, all implementations just have to be Sun compatible realistically. In C's case it's really opened a world of hurt with all the undefined behaviour and resulting security problems etc.
Also I have a feeling we'll be seeing a lot more to-JS languages, not to mention apps written in Rust, etc that target webassembly.
Template literals could not possibly be a replacement for JSX. JSX is Javascript, template literals are strings. JSX isn't a templating language by design, it's one of the primary advantages.
I do my templating in template literals because using standards-based JavaScript means that I don't need 50MB of fragile packages from npm or a largely superfluous build step during development.
[1] https://github.com/facebook/react/issues/690
[2] https://www.npmjs.com/package/babel-plugin-syntax-do-express...
That issue you linked to is 4 years old and is clearly a reflection of the poster being unfamiliar with React/JSX. The community has since unambiguously decided to avoid inserting more control flow in JSX. Also, I'm not entirely sure what the do/while plugin has to do with JSX.
> I do my templating in template literals
I would argue if you can write your code as easily with template literals as React/JSX your application isn't complex enough to warrant using a framework.
And yet the underlying issues still remain unaddressed. There aren't better ways to handle the cases raised in that issue, which is why people resort to adding additional non-standard syntax to work around the warts.
> Also, I'm not entirely sure what the do/while plugin has to do with JSX.
The "do" keyword is not do/while, it's a non-standard language feature that you can use to turn statements into expressions by wrapping them. It's like using an IIFE with a return value so that you can use a conventional "if" or "for" statement in place in JSX.
> I would argue if you can write your code as easily with template literals as React/JSX your application isn't complex enough to warrant using a framework.
I don't think you really understand how template literals work. Tagged templates can be used for more than just basic string interpolation. You can read more on the subject here: https://appendto.com/2017/02/advanced-javascript-es2015-temp... Or have a look at t7, which uses tagged template literals for virtual DOM templating: https://github.com/trueadm/t7
> I don't think you really understand how template literals work
I absolutely do. I use them to internationalize my apps. They're a powerful tool that is not comparable to React/JSX. JSX is not just a template engine which is what you seem to be implying.
Browser apps have to work across 4 major browsers with versions going back almost 10 years, an infinite amount of screen sizes, and a near infinite amount of devices. There is no other platform with the capabilities of the browser that has this much reach.
If we had the ability to start from scratch and build the ultimate web platform, yes, it would probably be way better than what we have, but we don't have that ability nor will we ever have it, so talking about it is a waste of time. We need to look at our current capabilities, where we want to be in the future, and iterate until we get there.
All of the tooling we have serves a purpose and solves a problem, it's not like frontend devs are adding tooling for the fuck of it.
Take a common stack nowadays: React, Redux, Webpack, Babel, Eslint, Yarn, Styled Components
Every single one of those tools in the stack make my life easier. I don't have to use all of them. In fact, there was a time where I didn't, but I would never want to go back to that time because these tools allow me to build way more complex apps way faster than I used to. And the other great thing about these tools is you can add/remove them as needed. Take something like browser prefixes, as browser support for certain prefixes or features are implemented at a large enough scale, the tooling for that becomes obsolete and you drop it.
And as far as JavaScript goes, pre ES6 I would agree, it sucked. Post-ES6, I will have to disagree. I love writing JS nowadays.