3 ms·
People used to say the same thing about C++ vs. assembler. I'm not saying React couldn't be better but it is super popular and enables a lot of applications by
by outside1234 7y ago
People used to say the same thing about C++ vs. assembler.
I'm not saying React couldn't be better but it is super popular and enables a lot of applications by a wider range of developers even if it is a more bloated.
Just like C++ vs. assembler.
- BubRoss 7y agoThat's all for the benefit of the developer to the detriment of the user. Also modern compilers condense C++ down pretty well. You can write something on godbolt.org and see how much waste there really is. You might be surprised.
- Kaze404 7y agoHow is it a detriment to the user? Surely you don't think they'll be downloading all those dependencies to access your website.
- sk0g 7y agoNot literally all of them, but users still have to download a lot more for each website, however basic, when it's built in a heavy framework with lots and lots of little (client facing) utilities. Gets a lot better when you're visiting lots of such pages, then you have a million versions of each library in your cache.
- Kaze404 7y agoI just created a project with create-react-app and served it with npm's "serve" package. My client downloaded a whopping 10KBs, half of which are React's logo which is a PNG file. It's really not as big of an issue as you think. Edit: For full transparency, this is the breakdown: index.html = 1.37KB main.hash.chunk.css + 2.hash.chunk.js + main.hash.chunk.js = 887B logo.hash.svg = 3.2KB logo192.png = 5.47KB
- sk0g 7y agoThat's pretty neat! I'd imagine it's that small because of minification too, but my experience with the React front end codebase at my work has left me rather scarred. So. Much. Bloat. My biggest issue is with people pulling in dumb libraries on npm that seem to live on someone's self hosted server though, so some branches will CD just fine, while others don't, and then I have to troubleshoot why something completely out of my control isn't working. Ugh
- Kaze404 7y agoI can empathize with that. In my experience front end does tend to pull in a significant amount of dependencies, and while I think we can do better I also think it's understandable to a certain extent. Web applications with the complexity we have now are relatively new and we're still trying to figure out how to do it properly. Sure, we had massive applications built with ASPX and jQuery before, but now the web does a lot more than display text and buttons to submit forms.
- sk0g 7y agoC++ vs assembler produced results within one or two orders of magnitude difference, in terms of LoC. It's gotten fairly close now too, at least if both are well optimised. React vs HTML/CSS/JS is a stupendous difference, and the barrier to entry, IMO, has gone up rather than down. At the start you basically have to be told what to do, and eventually you have some control over the output, if the tools you are trusting continue doing their job. Most people will never learn how the tools they are using actually work, and the massive surface area required to cover for this understanding is a big deterrent.
- stickfigure 7y agoone or two orders of magnitude difference, in terms of LoC LoC is the wrong benchmark. In C++ you link against a large set of libraries that have already been compiled to binary, hiding the LoC. glibc source alone is 10k files. Javascript libraries are source instead of binary. What's the problem?
- sk0g 7y agoYeah but lower lines of code from being able to rely on things just being there/ callable speeds things up so much! The React CD takes a minute and a half longer than the backend one, and the back end one has testing and libraries of its own to pull as well. Some of this comes down to SCSS, Babel etc, but most of it is built into CRA anyway