4 ms·

And people thought PHP was bloated/ full of 'magic'! The backend I have been working on for over a year, with DB, lots of random libraries for functionality li

by sk0g 7y ago

And people thought PHP was bloated/ full of 'magic'! The backend I have been working on for over a year, with DB, lots of random libraries for functionality like image processing, crypto, error capturing, SFTP etc has fewer liens of code than the very basic project structure to get started with React.

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 ago
  That'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 ago
    How 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 ago
      Not 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 ago
        I 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 ago
        That'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 ago
        I 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 ago
  C++ 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 ago
    one 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 ago
      Yeah 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
ehnto 7y ago
It has been really interesting watching the evolution of the web. At some point during the frontend JS revolution, there was a flip from a focus on backward compatibility, progressive enhancement and low impact javascript to "Fuck it, let's make the whole thing out of javascript!" Not 10 years ago I would have been debating if my dom actions for a touch slider were too much computation. Now? Why send HTML at all? We can make it out of javascript! CSS animations were a boon because we didn't have to do any of that JS calculation, mmm precious pragmatism. What's that? You want the background to be a real time generated animation in canvas? I know just the tool! I am glad we seem to be at a point where we can do it all performantly enough. But I do have to wonder how we got here so quickly.
- SlowRobotAhead 7y ago
  I work in embedded. I have a 64Mhz processor with 256k of ram... you and I are on different planes man!
  - ehnto 7y ago
    Haha to be fair, I am no advocate for the JS revolution. I wish the web had kept things simple. Maybe I am a luddite after all.
  - adrianN 7y ago
    My main computer still has a Core 2 Duo.
- dvfjsdhgfv 7y ago
  > I am glad we seem to be at a point where we can do it all performantly enough. Well, sort of. The problem is, if every web app assumes they can squueze whatever resources it can, it basically reduces your overall performance (and - if you are mobile - your battery life). It wouldn't be a problem if it was about apps actually requiring these resources (number crunching and other computationally intensive tasks). But we are talking about mundane tasks such as displaying a GUI here! It's just laziness on the part of everyone involved, and the end user suffers most.

by sk0g 7y ago

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 ago
That'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 ago
  How 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 ago
    Not 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 ago
      I 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 ago
        That'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 ago
        I 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 ago
C++ 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 ago
  one 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 ago
    Yeah 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

ehnto 7y ago

It has been really interesting watching the evolution of the web. At some point during the frontend JS revolution, there was a flip from a focus on backward compatibility, progressive enhancement and low impact javascript to "Fuck it, let's make the whole thing out of javascript!" Not 10 years ago I would have been debating if my dom actions for a touch slider were too much computation. Now? Why send HTML at all? We can make it out of javascript! CSS animations were a boon because we didn't have to do any of that JS calculation, mmm precious pragmatism. What's that? You want the background to be a real time generated animation in canvas? I know just the tool! I am glad we seem to be at a point where we can do it all performantly enough. But I do have to wonder how we got here so quickly.

SlowRobotAhead 7y ago
I work in embedded. I have a 64Mhz processor with 256k of ram... you and I are on different planes man!
- ehnto 7y ago
  Haha to be fair, I am no advocate for the JS revolution. I wish the web had kept things simple. Maybe I am a luddite after all.
- adrianN 7y ago
  My main computer still has a Core 2 Duo.
dvfjsdhgfv 7y ago
> I am glad we seem to be at a point where we can do it all performantly enough. Well, sort of. The problem is, if every web app assumes they can squueze whatever resources it can, it basically reduces your overall performance (and - if you are mobile - your battery life). It wouldn't be a problem if it was about apps actually requiring these resources (number crunching and other computationally intensive tasks). But we are talking about mundane tasks such as displaying a GUI here! It's just laziness on the part of everyone involved, and the end user suffers most.