Browsers and JavaScript are what we have, we can't magically replace every browser and JS implementation in the world. We have to figure out where we want to go and slowly get there. That is exactly what is happening in the frontend world and that is why there is so much churn.
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.
> And the other great thing about these tools is you can add/remove them as needed.
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.
> 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.
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.
> We all switched from coffescript to ES6 and Babel because ES6, being standards-based, will eventually be supported in browsers, right?
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.
Or, you know, allow multiple implementations without someone having to reverse-engineer what's meant to happen in edge cases from the reference implementation...
In PL context standard usually implies a committee design, whereas language specification is used to mean an engineered formal definition to define semantics. I agree having a spec without the committee design is a mostly good thing.
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.
Browsers catching up won't be the end of transpilers. If you want to write modern JS and have it support old Android phones or safari, you're stuck transpiling. And, browsers well never catch up, there will always be new features to be trying. It's really beautiful: we get to try different possible future versions of JS and make an informed decision on what and what not to bring into the language.
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.
> which is the standards-based approach that ES6 actually provides for embedded DSLs and templating.
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.
JSX is not JavaScript, it's a non-standard bastardization that will never be supported natively in browsers. Its reliance on JavaScript for flow control is so problematic[1] that people have started working around its many glaring inadequacies by adding new language primitives to JavaScript itself via Babel plugins[2].
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.
It was never intended to be supported natively by browsers -- it's syntactic sugar for the React.createElement API. That's what I mean when I say JSX is Javascript.
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.
> That issue you linked to is 4 years old and is clearly a reflection of the poster being unfamiliar with React/JSX
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.
Ah, sorry I misunderstood the plugin. But to the point -- people do all kinds of crazy things in all kinds of languages with all kinds of tools. That doesn't mean there's anything fundamentally broken about them. Now that I know about the existence of the Do plugin I can also definitively say I have no use for it. It's a band-aid for bad code, not a bad framework.
> 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.
To be honest, the lack of it existing in javascript aside, statements-as-expressions is a useful thing - no need to remember the semantics of `if {} else {}` vs `? :`, ability to have very complex (multi-line) expressions, and in languages with RAII, blocks being expressions means it's easy and clear to be able to acquire a resource in order to calculate a single value.
Flow control using js is very simple. For the example you linked it should have used smaller components. Jsx is all about components. I cannot go back to string literals.
The place for templating in the web stack should be the markup language, not JavaScript IMO, and in SGML (on which HTML is based) there has existed a standard for it since 1986.
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.