5 ms·

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

by dntrkv 10y ago

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.

segphault 10y ago
> 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.
- ng12 10y ago
  > 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.
  - segphault 10y ago
    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. [1] https://github.com/facebook/react/issues/690 https://github.com/facebook/react/issues/690 [2] https://www.npmjs.com/package/babel-plugin-syntax-do-expressions https://www.npmjs.com/package/babel-plugin-syntax-do-express...
    - ng12 10y ago
      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.
      - segphault 10y ago
        > 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. 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-template-strings-with-tagged-templates/ 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 https://github.com/trueadm/t7

by dntrkv 10y ago

segphault 10y ago

> 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.

ng12 10y ago
> 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.
- segphault 10y ago
  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. [1] https://github.com/facebook/react/issues/690 https://github.com/facebook/react/issues/690 [2] https://www.npmjs.com/package/babel-plugin-syntax-do-expressions https://www.npmjs.com/package/babel-plugin-syntax-do-express...
  - ng12 10y ago
    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.
    - segphault 10y ago
      > 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. 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-template-strings-with-tagged-templates/ 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 https://github.com/trueadm/t7