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

This is not a criticism, I totally get why you feel that way and it's not your fault.

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 '//r ./templates/header.html' {} \;

Of course, this doesn't scale particularly well. But why the heck are you worried about scaling right now? You can add a build step later. You can download Mocha later. Nothing you're doing at this stage will prevent you from making that decision in the future when you're more informed. So why are you worrying about things that aren't problems yet?

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

Totally true. I didn't write this as a knock against node at all. I think there is a lot that is great there. I was just describing my experience trying to get a project from an experienced, but opinionated in the sense that they had a set of tools they felt would work best for our project, freelancer up and running so that I could make a few changes to integrate it into our development process. I was just trying to give a counterpoint to the idea that node is somehow easier to get up and running than python.

In fact, I would have a lot of the same opinions about getting a python project started as has been voiced in many of the comments here regarding node. I would say "Don't worry about things like conda, virtualenvwrapper, etc. You just need to create a new venv for each project, activate it, and use pip to install any packages you need"

But I'll acknowledge that sometimes you need to do something a little outside the norm and it starts to make sense to rope in some other tools.

They learn how to learn and get their feet wet with reading documentation. First docs to read, follow, and do: The python docs on installing pip and virtualenv

I think that when people like me say, "Node is easy to get up and running", we're coming at it from the perspective of, "well, you don't need to do any of this crazy stuff with Babel or Webpack." It's easy to forget that for the average newcomer just getting started with JS, there is an enormous pressure to start out with something like React+Redux with a special transpilation step that runs through some kind of Grunt config with a niche linter that the tutorial writer decided they were going to promote one day.

So when I talk about Javascript being accessible, I'm talking about this perfect world where you don't have all these people constantly telling you that you're doing it wrong, and where you're coming at it from the perspective of, "a tool should just automate something that I already roughly know how to do and don't want to repeat over and over." I'm thinking about this almost fictional world of Javascript where you can clone a Github project and the ratio of config files to source code is relatively small.

Again, it's not a criticism of anyone who feels overwhelmed or wants to acknowledge that it's a problem, because it is a problem. I just want to take every opportunity I can to point at it and say, "you don't have to do this, the insane setup is a cultural thing, not a tech thing". And that's not to put anyone down who uses those libraries or to make them feel like they're doing it wrong -- it's just to push in the opposite direction of that cultural pressure.

I'm sorry to hear you have had problems with Thonny. Which libraries you had problems with?