Repl.it raises $4.5M from A16Z, Paul Graham, and others

That shit is discouraging and the annoying thing--coming from some who first wrote a Tetris clone a decade ago--is that it's recent. A decade ago you just downloaded a library and put it in the folder you were writing in. Now while that still probably works library how-tos have all either gotten complicated or assume you've already complicated that shit.

I was more trying to make a point that if you're writing a guide or tutorial, actually start from the beginning.

1. Install docker using Apt or Yum 1a. So for CentOS i had to download and run a script on my machine to add the repository and install. 1b. Setup autostart of the service 1c. Configure my user so i can manage docker without sudo.

Then once its installed: 2a. Lookup the correct flags to use 2b. Find the correct image to run 2c. Learn how to map a local folder for persistence 2d. Learn how to open ports for the program to be accessible.

As a system administrator with 15+ years of experience, this is easy for me. But if I where to ask someone without any system experience to do this, I can for-see a lot of frustrating moments where they would give up.

NPM land is the only place I really have to be wary about package versions, because otherwise, even when following 6-months old tutorials you'll end up with nothing working due to breaking changes between library versions. And there are just so many dependencies to keep track of...

I still remember my first attempt, years ago. I shopped around for front-end frameworks, and picked Ember, which was in vogue then. I proceeded to create a default "hello world" with ember-cli, only to discover the newly generated project had ~70k files in 150k folders. I bailed out immediately and went back to jQuery.

The situation in Node-land is much improved now, but I'm still uncomfortable with so many moving parts you have there, all constantly changing, which can - and do frequently - break at any moment. And just when I think I finally have things under control, my professional front-end developer friend comes out and says, "no no no, you're doing it wrong; throw out library X and use Y instead, add webpack, and while you're at it, use Yarn, and here you have this config which adds a newest linter...".

And npm is always installed alongside Node.js which I suggest installing by nvm. I guess this depends a lot on the level of assistance you can get with the installation process. Using sudo is almost always a dumb idea for installing anything.

I admit frontend development with JS/TS is tricky business that I myself also abhor at times. When everything works it's fine but when it doesn't well. I'll be pulling my hair for a while, then trying to Google the issue which often works btw. The one of the biggest perks of a big ecosystem (with many beginner programmers) is that there is plenty of help for almost any problem.

Once you get past your guttural "Node.js/JS sucks because of this and this" I find it to be (with TypeScript) a productive and fairly simple ecosystem. I haven't noticed big of a problem with newbie programmers starting to learn Node.js once you give them good enough tutoring. Webpack is not something you want to introduce them to for a long time (unless necessary) and yeah, it's a pain in the ass.

Like, I realize that these "you need so many things!!1!" narratives are popular ways to complain about JS, but if you're adding random junk to your project without a clear reason for it, that's really your responsibility and yours alone.

However, if you or someone else is reading this and thinking, "well, that's just what I'll have to deal with to get started in JS", heck with that crap. There is a huge portion of the community that pushes people in this direction, and you don't need to go in that direction. You should ignore them.

If you're running your code within the browser, then first take a step back and ask yourself if you even need npm or node. Remember, all Node does is give you the ability to run JS code with access to your filesystem/native processes. I hand-code sites all the time, because it's fast. You don't have a build step, you use the built in browser dev tools to debug, and you just hit F5 and see your changes instantly.

You can do TDD from a browser without installing Node. It's pretty easy actually, you don't even need a testing framework. Make a separate page that includes one script with all of your tests. The only big concern is importing headers into multiple files, but remember that you can always just fall back on the Linux commands that you already know:

  rm -r ./public && mkdir ./public && cp -a ./site/. ./public
  find ./public -type f -name '*.html' -exec sed -i '/<!--importheader-->/r ./templates/header.html' {} \;

Okay, so say you really want to do a build step. You're want to write SASS instead of CSS or something. First, there are command line compilers for SASS that don't require you to install Node or npm. Remember, all that Node does is it gives you the ability to run JS in your native environment. But let's say that really want to use Node for this, or let's say you're explicitly trying to build a Node application.

Install nvm[0]. This will handle setting up node and npm and all of the linking and whatever; especially on systems like Ubuntu, it's just better than using the package manager and linking everything yourself. Do not worry about yarn, it is not appreciably better unless you're working with a massive number of packages. Don't work with a massive number of packages.

If you're here because you just want to write a Node app and not because you're building a build tool, then don't install a build system. You don't need one. Most of the modern ES6 features are available in most modern versions of Node, and you can set a lower limit for what you support if you're planning on mass-distributing what you make. Remember, if this becomes a problem later, you can add Babel then. Transpilation won't require you to rewrite your entire codebase. You don't have to care about this until after it becomes a problem.

When testing or building your code, consider using a low level tool that shows you what's happening, or writing your own. It doesn't even need to be JS. I have, in the past, done bundling by literally just concatenating files together. I have also built HTML template systems in Node that were literally just a file read, a few regex expressions, and then a file write. Ask yourself, "what does this tool actually need to do?" Some of the biggest tools in JS are built on concepts that are actually not all that complicated to understand or replicate.

This seems like a very extreme perspective, but the modern JS ecosystem is based around, "We're going to build a bunch of high-level tools so that nobody has to think about the underlying mechanics of any of this." The problem with that mentality is that the high level tools change all the time, and when they do change, all of the experience you have with the old API is useless. So you end up with a bunch of opinion pieces being written about how everybody needs to switch to this tool or that tool, and new users who have no context to figure out which ones are important.

Tools are important, I like them. I use them. But I only add them when I have need. When I start a new node project, I don't install anything. At most, if I'm doing TDD, I install a very small, minimal testing framework that doesn't come with any special config files or anything. Then later on, I start looking at tools when I have a specific, well-defined problem that I need solved.

What you have to understand is that JS is very flexible, and because your build tools and IDEs and whatever are all written in JS, the temptation is always there to say, "I'm going to build some type of meta-system on top of this other meta-system because I don't like this specific thing." That's not necessarily bad, but it is very hard to avoid that mentality, and it means that large swaths of the online community think that an introduction to testing means, "here's how you install Mocha", and not, "let's learn how test runners actually work." So it's completely understandable why people feel overwhelmed, but the good news is that it's possible to ignore those people and actually just write Javascript, and in the long run doing so will make you a better developer because you'll spend less time trying to figure out what the flavor of the week tool is.

I love the JS community, but I dislike this aspect of it. I wish we spent more time questioning some of the tools we use.

[0]: https://github.com/creationix/nvm

It seems there are very few real problems in the world to solve if we are going to be stringent. Also solving non-real problems can lead to solving real problems (ad industry funding bleeding edge innovation is a good example of this).

On Mr. Robot we have a few references to it on the website including this very post. See the last video on the page, zoom in on the top-left corner ;)

We don't use clis during every day life for a reason.

I get it, this is clever. It supposedly weeds out poor applicants. But speaking for myself it just strikes me as annoying.

Koding, in particular, went through pretty much exactly the same cycle as Repl.it a few years ago. They started out getting tons of users by giving cloud servers away for free, targeted mainly at children/education market. Then they started selling premium plans for beefier servers, but no one bought them. Then, they tried to become a cloud infrastructure company[1] and created a distributed filesystem product[2], which seems to be exactly your plan as well!

As it turns out, the educational users were only there because going on a free website is easier than installing Python on your computer, so when Koding started trying to charge for stuff, no one bought it.

[1]: https://blog.koding.com/koding-is-not-an-online-ide-e2693f74... [2]: https://www.koding.com/docs/kd