A modern “Hello, World” program requires more than just code | Hacker News Reader

A modern “Hello, World” program requires more than just code

stackoverflow.blog

53 pointsluord58 comments

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

Finally, of course I don't consider myself the only person thinking about it but someone finally pointed the elephant in the room because it's been bugging me for a very long time, especially with anything related to NodeJS it feels like to actually get somewhere you need to pull hundreds if not thousands of tiny libraries dependencies. Once 1, 2, 50 of those tiny libraries becomes unmaintained and fall into a high risk vulnerability and there's no replacement that's it , you have to start taking care of it yourself. It could happen in any language, yes, but I feel it's more prone to happen in NodeJS given the nature of .... pulling hundreds of modules, even with Java/Maven you don't really pull that many libraries into your application unless it has some really wide scope in it.

I don't have any beef with NodeJS itself but the whole subject of having so much boilerplate code needed to get yourself started is a bit insane. I get that hardware has become more powerful and storage is cheap but... at which point is it no longer okay and becomes a burden to distribute said apps?

it happened, https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

There are some good threads (if we could call them that) on GH related to how LeftPad "broke the Internet" and the original stories about it from Kik are/were on Medium. Surfing through the related GH threads lead me to ZeroNet[1], which is fantastic P2P web alternative which works offline and updates in real-time. It also has a decentralized GitHub alternative which would mitigate situations like LeftPad.

[1]: https://zeronet.io

I couldn't help but revise the code because it failed to even use minus-equals and is severely unoptimized.

Here is my rendition. Mind you, this is mainly for IE as ES6 has a String.padStart method. I would also use Array(n).fill() but again, IE does not support it, so manual string appending is the sacrifice to make..

  module.exports = function(str, len, ch) {
    if (ch === undefined || ch === '') ch = ' ';

    str += "";
    len -= str.length;
    len /= ch.length;

    var pre = "";
    while (--len >= 0) pre += ch;

    return pre + str;
  }

I'm starting to see advertising and begging for work in the output of these builds. I'm scanning the console for errors and these things accidentally get my attention falsely.

And that Hello World probably isn't isomorphic, which limits the ability of crawlers other than the most sophisticated to actually see the data. Want to make it crawlable? Add another 70,000+ dependencies.

Nobody in the world is arguing against the fact that CRA is overkill for a Hello World application.

Luckily, that’s not it’s target space.

If you engineer frontend applications of even moderate complexity, you will eventually start to pull in tooling + dependencies + configuration to handle real world use cases. Eventually? You end up with a once-off, home-grown variant of... what CRA emits anyway.

How big is the JDK? How big is Spring? Would you include both when calculating the size of a simple Java app that prints "Hello World"? Probably not.

Remember that node_modules contains the entire world: it contains your compilers, transpilers, development server, development toolchain, and runtime libraries. All software is built on the shoulders of giants and Node's only mistake was making it plainly visible.

Maybe I misunderstood it but why would you create a react app for writing Hello world. In Javascript you can do that in one line 'document.writeln("Hello world")'

That's equivalent of installing Laravel first just to write Hello world in PHP and saying look how big my vendor folder is.

The goal never was to print "Hello, world!" on the screen. It was to quickly check that your build and runtime environment works.

But nowadays projects are generally expected to drag-in a lot more tools/dependencies than a C compiler and its runtime.

Because it makes for a great strawman. “Look, JS tooling is so bloated, just to emit a Hello world!”

I‘ve since stopped expecting any level of reason when it comes to HN bashing of modern JS/React/frontend.

The bashing never seems to come from people using the tooling, either.

It's my belief that Hello, World is the hardest program I ever write. I have to track down the compiler, install all the dependencies specific to my system, figure out where the various files go, and puzzle out how to make them start. The error messages are usually incomprehensible -- when they exist at all. Often, errors are simply "nothing happened".

Once the program is running, I have a tool set for debugging it. I can start from there and add things. But for a new framework/language, the actual program is often less total work than the initial Hello, World.

In snes Zelda, the dungeons were designed such if only you had an item, it would be so much easier. Like a rope to clear ledges vs having to go all the way around.

It is said that this teaches without words.. makes players long for an item before they have it and when they get it, they already know why it exists and how it is used.

One advantage of going slower with students and helping them with things like (oh that didn't work because Microsoft Word changed your quotes), is they build an understanding of the tools.

Git is a good example. I have so many CS student friends who talk about how annoying their teacher is for making them use git, and how they don't see any point in it. From their perspective I totally understand. As soon as they realize like (oh I needed code I deleted, or oh I need to merge two people's code) will git start to actually make sense.

Git's porcelain is absolutely terrible, and I don't fault anyone for thinking that it's pointless trying to mess around with it, especially because teachers aren't usually the best at explaining it anyways.

   #include <stdio.h>
  
  int main() {
      printf("Hello, world!\n");
      return 0;
  }

Unrelated, but I will note that the standard signature is "int main(void)" ;)

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

Makes my head spin.

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

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.

I can still remember being extremely confused the first time I came across a 'hello world' tutorial as a child.

The thoughts running through my head were something like: What is 'hello world' and why am I writing it? Is it a command that does something? Does every language have a 'hello world' command, or just this one? Let's see... if I copy and paste the code and run it, it doesn't seem to do anything except repeat 'hello world' back to me. I must be missing something...

https://www.artsy.net/artwork/brian-kernighan-hello-world

Real talk: is the comma in “hello, world!” necessary?

Yeah! And while we're on the subject, is the ", World" even necessary?

Traditions are traditions, and an industry as young as ours needs to hold on to the very few we have!

Moving goalposts around on the Hello World code golfing world has some 'consequences' - there's languages with built in hello world that try and get it printing with minimal code, and removing the comma, for example, would invalidate that hack.

One tradition I'm happy got lost in the way is using FOO, BAR, BAT in examples. It made the simplest examples hard to understand and those words never made any sense to me.

It's always better to use contextual words in most examples.

edit: for more clarity this article (1) explains it quite well

https://dev.to/kiarathedev/why-i-don-t-use-foo-bar-baz-1kf7

I'd honestly rather have a,b,c than that! Nobody writes code with such placeholder variable names, so why demonstrate it that way?

Placeholder variables like i and j don't count! Foo, Baz, etc are annoying to read too, IMO.

I use foo, bar, baz, etc. all the time when I’m writing tests. But I agree generally it is better when examples use meaningful name `cd /path/to/file` as oppose to `cd /foo/bar/baz`

What's wrong with FOO? It's fun to say and can use it almost anywhere when you need a random word. Has saved me seconds here and there when I didn't need to think of a word because I have FOO :)

It's cute. "Hello" is just greeting the programmer, as if it were one person to another. "Hello, world" is like a new baby introducing itself to a planet. It's both tiny and momentous; the contrast is humorous. That feels friendly.

Especially viewed in its original context, introducing a new programming language (C) to a planet that wasn't quite as crowded with programming languages as it is today.

Since then it's just tradition. Feel free to leave it out. But it's iconic for a reason.

Hello, sbilstein! ;-) It's considered grammatically correct.

> When the salutation in your letter or email starts with Hello or Hi, then you should put a comma before the name of the person you're addressing. It is also standard practice to put a comma after the name of the person you're addressing. ... You could also use an exclamation mark if you wanted to emphasize an emotion (like surprise). [1]

[1] https://www.grammar-monster.com/lessons/comma_with_dear_hell...

I'm not an expert but I've always seen it written this way and plenty of other sources suggest this practice. e.g. https://www.grammarly.com/blog/comma/

Modern English usage does not pay much attention to the traditional ideas of being grammatically correct.

The trend today is to omit needless punctuation. In the case of "Hello, world!" vs. "Hello world!", there is no one who would be confused by either version. The comma does not change the meaning at all, so you can include it or omit it as you prefer.

But take a look at one example of modern usage. If your name is Mike (like mine), which would you be more likely to see at the beginning of an email:

Hi, Mike,

or:

Hi Mike,

Pretty sure it will be the latter. In fact I can't remember the last time I saw this salutation with a comma.

(Edit: after writing that, I noticed that my last sentence is an example of what I'm talking about. I think the "grammatically correct" version would be "In fact, I can't remember..." - but many writers today would leave out that unnecessary comma.)

Edit 2: Hello, downvoter! ;-)

Gosh, does anyone write like that any more? It seems so archaic.

See, the thing about the comma is that it isn't a question of being "grammatically correct" or not. The purpose of the comma in modern English is to show where you would pause when speaking.

Which way would you pronounce it? "Hello world" just like any other two words in a row? Or "Hello <pause> world"?

The way you pronounce it is what should inform you about whether you write the comma or not.

Depends on your intent. If you are referencing a world when everyone can only say "Hello", the comma may be removed

Reply on news.ycombinator.com