5 ms·

My big issue with JSX is that it forces you to use a pre-processor and source maps. If you have to do that anyway, I think I could use JSX instead of "pure" JS

by gnud 6y ago

My big issue with JSX is that it forces you to use a pre-processor and source maps. If you have to do that anyway, I think I could use JSX instead of "pure" JS.

throwanem 6y ago
Setting up Webpack and Babel isn't so bad, these days, and you really only have to do it one time and then you can reuse the setup in other projects. Plus, once you've done it, Typescript is easy to slot in, and that by itself makes the effort worthwhile.
- onetom 6y ago
  I can highly recommend you watching this talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... It explains very well why is something being easy shouldn't be the main metric, when choosing some technology. In this case you are advocating to pull in webpack (28MB, 348 packages from 210 contributors), @babel/core (12MB, 54 packages from 60 contributors), typescript (53MB, 11 packages, 4 contributors), to just mention the most obvious and necessary dependencies, not even mentioning the different plugins for integrating them with each other, test frameworks, linters, IDEs (syntax highlighting and auto-formatting) and of course the mountains of type definition boiler-plate. 100MB+ of dependencies which are all a responsibility to learn, teach, configure and upgrade. Versus this ~12000 bytes: https://unpkg.com/hyperapp https://unpkg.com/hyperapp It's like 6 pages of code on a 2K iMac monitor and none of the above... I'm not saying that there are circumstances when you might want to put up with all that cost, but have you consciously considered, whether it really worth the overhead? What's missing from hyperapp, which is only present in the 100MB+ deps? Maybe `htm` (1MB, 11 packages, 4 contributors) is a better compromise between bloat and ease of development? And if you are willing to take on the extra dependencies, wouldn't ClojureScript provide a lot lot lot more benefits? It's also based on the super mature Google Closure Compiler, which supports extremely sophisticated optimization techniques and DCE... Just to mention some recent optimization surprise: https://twitter.com/roman01la/status/1277148232276234240 https://twitter.com/roman01la/status/1277148232276234240
  - throwanem 6y ago
    > [...] have you consciously considered, whether [it's] really worth the overhead? Yes, I have. The overhead of a React/TS stack is considerably less than the overhead of having to hand-build all the stuff that Hyperapp's 12 kilobytes aren't enough to provide, or that using ClojureScript means very few other engineers will want to work with me to build because I'm doing everything in a language and stack they've never heard of. > What's missing from hyperapp, which is only present in the 100MB+ deps? Eleven years! Hyperapp is written in pure ES5, which was finalized in 2009, around the same time PHP 5.3 came out. The world has moved on a great deal since then. (But hey, I haven't had to think about hoisting for like six years now, so that was a fun blast from the past!) That said, those 12 kilobytes of ES5 code are very concise, for sure. They also implement a virtual DOM and a sugar syntax over element creation and nothing else. To compare it based purely on codebase size, with a stack that provides orders of magnitude more functionality, seems at best very incompletely thought through, and at worst deliberately tendentious - although I'm sure that can't be the case. There's a lot of misinformation floating around about the modern Javascript world. A lot of that dates from years back, like the left-pad problem, or that builds aren't reproducible - both of which were true at one time, but have long since ceased to be. Or that using these tools makes it impossible to deliver compact, performant code to the frontend - which, again, hasn't been true in quite a while. It's not false to say that webpage bloat is worse than it ever has been, but it is false to blame the tools for that problem. Of course, I freely grant that it's hard to see these kinds of nuances if you don't have much or any context on what modern Javascript is actually like. What I don't grant is that that ignorance is any kind of worthwhile place from which to pass sweeping comments on the whole field of endeavor.
  - com2kid 6y ago
    If you are doing back compat for old browsers, Babel is necessary anyway. Typescript is a choice independent from anything else. There are alternatives to Webpack, none of which have gained traction, possibly because developers appreciate other features that webpack provides out of the box. But, you are complaining about the developer tools, why? The source code size of emacs/vscode/vi is just as relevant, or the size of the linter, or the complexity of whatever build environment is used to deploy code to production. All of those require upgrading and maintenance, and occasionally have bugs!
enobrev 6y ago
The _only_ reason I use webpack and friends are for JSX and Typescript. For me, those two tools are worth the compilation step. Qs soon as it's possible to stop using compilers while still enjoying the benefits of both, I'll dump them from all my codebases.

by gnud 6y ago

My big issue with JSX is that it forces you to use a pre-processor and source maps. If you have to do that anyway, I think I could use JSX instead of "pure" JS.

throwanem 6y ago

Setting up Webpack and Babel isn't so bad, these days, and you really only have to do it one time and then you can reuse the setup in other projects. Plus, once you've done it, Typescript is easy to slot in, and that by itself makes the effort worthwhile.

onetom 6y ago
I can highly recommend you watching this talk: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... It explains very well why is something being easy shouldn't be the main metric, when choosing some technology. In this case you are advocating to pull in webpack (28MB, 348 packages from 210 contributors), @babel/core (12MB, 54 packages from 60 contributors), typescript (53MB, 11 packages, 4 contributors), to just mention the most obvious and necessary dependencies, not even mentioning the different plugins for integrating them with each other, test frameworks, linters, IDEs (syntax highlighting and auto-formatting) and of course the mountains of type definition boiler-plate. 100MB+ of dependencies which are all a responsibility to learn, teach, configure and upgrade. Versus this ~12000 bytes: https://unpkg.com/hyperapp https://unpkg.com/hyperapp It's like 6 pages of code on a 2K iMac monitor and none of the above... I'm not saying that there are circumstances when you might want to put up with all that cost, but have you consciously considered, whether it really worth the overhead? What's missing from hyperapp, which is only present in the 100MB+ deps? Maybe `htm` (1MB, 11 packages, 4 contributors) is a better compromise between bloat and ease of development? And if you are willing to take on the extra dependencies, wouldn't ClojureScript provide a lot lot lot more benefits? It's also based on the super mature Google Closure Compiler, which supports extremely sophisticated optimization techniques and DCE... Just to mention some recent optimization surprise: https://twitter.com/roman01la/status/1277148232276234240 https://twitter.com/roman01la/status/1277148232276234240
- throwanem 6y ago
  > [...] have you consciously considered, whether [it's] really worth the overhead? Yes, I have. The overhead of a React/TS stack is considerably less than the overhead of having to hand-build all the stuff that Hyperapp's 12 kilobytes aren't enough to provide, or that using ClojureScript means very few other engineers will want to work with me to build because I'm doing everything in a language and stack they've never heard of. > What's missing from hyperapp, which is only present in the 100MB+ deps? Eleven years! Hyperapp is written in pure ES5, which was finalized in 2009, around the same time PHP 5.3 came out. The world has moved on a great deal since then. (But hey, I haven't had to think about hoisting for like six years now, so that was a fun blast from the past!) That said, those 12 kilobytes of ES5 code are very concise, for sure. They also implement a virtual DOM and a sugar syntax over element creation and nothing else. To compare it based purely on codebase size, with a stack that provides orders of magnitude more functionality, seems at best very incompletely thought through, and at worst deliberately tendentious - although I'm sure that can't be the case. There's a lot of misinformation floating around about the modern Javascript world. A lot of that dates from years back, like the left-pad problem, or that builds aren't reproducible - both of which were true at one time, but have long since ceased to be. Or that using these tools makes it impossible to deliver compact, performant code to the frontend - which, again, hasn't been true in quite a while. It's not false to say that webpage bloat is worse than it ever has been, but it is false to blame the tools for that problem. Of course, I freely grant that it's hard to see these kinds of nuances if you don't have much or any context on what modern Javascript is actually like. What I don't grant is that that ignorance is any kind of worthwhile place from which to pass sweeping comments on the whole field of endeavor.
- com2kid 6y ago
  If you are doing back compat for old browsers, Babel is necessary anyway. Typescript is a choice independent from anything else. There are alternatives to Webpack, none of which have gained traction, possibly because developers appreciate other features that webpack provides out of the box. But, you are complaining about the developer tools, why? The source code size of emacs/vscode/vi is just as relevant, or the size of the linter, or the complexity of whatever build environment is used to deploy code to production. All of those require upgrading and maintenance, and occasionally have bugs!

enobrev 6y ago

The _only_ reason I use webpack and friends are for JSX and Typescript. For me, those two tools are worth the compilation step. Qs soon as it's possible to stop using compilers while still enjoying the benefits of both, I'll dump them from all my codebases.