Hacker News Reader

Comment by SlowRobotAhead | Hacker News Reader

> Building a new React app with create-react-app requires 4304 directories and 28678 files.

Makes my head spin.

I've never fully understood Create React App. Is it for people who just churn out generic apps at a rate that the time to set up the dev env is a meaningful cost? I'm not sure I've found setting up webpack or whatnot to be all that time consuming.

My bigger concern is that I don't want to become a passenger rather than the driver of my environment and build pipeline.

It's a great way to get started building a "modern web app" for folks who aren't comfortable rolling their own e.g. webpack / babel configs.

If you ever want to have more control, you can "eject" & customize however you like.

Honestly the defaults are really nice. I rolled my own for several projects and then just used create react app for this startup and forgot about my build pipeline.

Once I ejected it took a little hacking to get the index.html to work with handlebars cause I like to render a bunch of data and other stuff server side for speed optimizations.

Now I use the same web pack pipeline CRA ships with and just point my server to serve static files from the build folder. I’ve removed the server component and now just have the script watch and build. I don’t believe in SSR for react and prefer handlebars for most things server side so this workflow suits me well.

If many people are doing roughly the same "thing" then surely it makes sense to automate that "thing". It's much like how we don't build and develop software for every business process: we look for an existing solution that is general enough to fit our requirements (usually Excel).

It can do a lot of smart default that you don't necessarily know, especially for typescript support.

Facebook offers an opinionated, production ready, battle tested framework for bootstrapping a modern React application with tooling/batteries included (with dependencies automatically maintained if you need to version bump to latest via react-scripts as a magical dependency).

Unless you’re doing something so completely customised (and even then, ejecting from CRA is a blessed path), why WOULND’T you use CRA?

> why WOULND’T you use CRA?

It's worth noting that CRA is pretty complicated. My home-rolled webpack configs are significantly simpler than ejected CRA apps. If you're going to be making significant changes to the configs it's going to be a lot easier with a custom project.

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.

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.

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.

How is it a detriment to the user? Surely you don't think they'll be downloading all those dependencies to access your website.

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.

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

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

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.

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.

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?

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

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.

I work in embedded. I have a 64Mhz processor with 256k of ram... you and I are on different planes man!

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.

My main computer still has a Core 2 Duo.

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

I totally agree. I'm even dubious about the idea that we actually can do it performantly or if we just optimize for the wrong metrics, the web feels immensely slower than it used to.

What performance?

I can somewhat understand this.

1. React targets a rolling release platform which keeps on changing. On top of that, most people are not always on the latest version. If you are targeting something like an enterprise, you'd be stuck with IE.

2. React also has to run on 3 implementations of the web platform (Chrome/v8, Firefox/Spidermonkey, Safari/WebKit) which have no "obligation" to follow a standard. Many (Safari) can have enormous delays in deploying features to the public at large. Unlike Java, JS devs (especially front-end) don't have the ability to enforce a runtime platform or else they risk loosing users to their competitors. So you have to transpile code to run on browsers which doesn't speak the latest syntax.

3. JS also has enormous backward compatibility.

4. JS decoupled most of the quality-of-life features from the core language. What is generally part of the compiler or IDE (in case of Java/C++) are separate libraries that have to be manually installed by the user - so you see these huge npm installs for each project. No language escapes from this. In case of Java, all of this is hidden under the install size of eclipse/intellij. Though I do agree, that in some cases, JS devs have taken this modularity to the extreme (Specifically the thing that happened with left-pad)

5. Then there's the problem of how your frontend is tightly coupled with the product. How your frontend is built, performs etc determines your search ranking, your user retention, your customer experience. All of this directly defines your revenue.

Web as a platform is a wild beast. It's much more complex than we ever expected it to be and CRA does put a balm on all the pain points.

Dropbox clients have a limit of 300,000 files. I can barely put 10 React apps in a Dropbox account.

Things like package-lock.json exists just so you can reproduce exact build. Don't vendor your dependencies and you'll be fine with hundreds of React apps in your Dropbox.

Reply on news.ycombinator.com