Why I hate virtualenv and pip - <AUTHOR> http://pythonrants.wordpress.com/2013/12/06/why-i-hate-virtualenv-and-pip/ <comment><USER2> A lot of this seems to boil down to a combination of seeing others misuse tools and assuming that's what they're for (which is a communication/teaching failure, not a failure of the tool), and looking at stepping-stone solutions.

Take binary packages, for example. Sure, eggs did that. Sort of. But they also introduced a weird parallel universe where you had to stop doing normal Python things and start doing egg things. So pip eschewed eggs.

And meanwhile the community banded together to find a way to separate the build and install processes, the result of which is the wheel format:

[http://www.python.org/dev/peps/pep-0427/](http://www.python.org/dev/peps/pep-0427/)

Similarly, virtual environments are still being improved (with the improvements now being integrated direct into Python itself).

And yes, you _can_ use pip's requirements files as a duplicate way to specify dependencies. And people do that, and it's unfortunate. Because the thing requirements files are really useful for is specifying a particular environment that you want to replicate. That might be a known-good set of stuff you've tested and now want to deploy on, it might be an experimental combination of things you want others to test, etc., but that's something setup.py's dependency system isn't good at. And repeatable/replicable environments are certainly an important thing.

etc., etc.

<comment><USER3> i was pleased to see wheel mentioned. here is a wheel anecdote:

suppose you wanted to automate the installation of a python package to a windows machine, but the package has binary dependencies, is irritating to build from source, and is distributed as a pre-built .exe interactive installer (click next, next, ...). you can `wheel convert` the exe installer to get a binary wheel archive, then automate the installation of that wheel archive with pip. hopefully this isn't a common scenario, but the fact that pip + wheel make this kind of thing possible at all is very helpful.

<comment><USER4> I fail to see the attraction of wheel, and the uptake since it was invented appears to be basically non-existent.

Can someone seriously explain what the point of it is?

As far as I can tell, it's: make life easier for windows python users (which I am one of, and I don't care about it at all; you need VS to build everything anyway; one or two wheel modules makes zero difference; it'll only make a difference when _everything_ uses wheel, which will be never...).

</comment></comment></comment><comment><USER5> As a programmer who uses a lot of Java and .NET, I was surprised by how complex pip and virtualenv are. The complexity is hidden well enough if you just want to get down to business, so it's not really a practical concern, but still - copy an entire Python environment over? Why? Why can't I just have the pip'ed libraries in a subdir somewhere and tell Python to look there?

Plain old JARs get this right, Maven gets this right, NuGet gets this right, NPM gets this right. Why is it so complex on Python and Ruby? Some technological aspect of the (flexibility of) the languages that need you to basically copy over the entire world? Or just legacy of unfortunate bad design choices in earlier days?

<comment><USER6> because (and correct me if I am wrong) Jars (and certainly Wars) contain other bits than the part you wrote.

let's say you are packaging up a java and a python "program". Both print Hello world to the stdout, but use a third party spell checking package. Both the venv and the jar will contain that third party package

All python needs to go from venv to jar is a tarball process.

that is roughly were I see us going anyway - ps anyone with good understanding of jar files please jump in - I would love to map out the python parts against the jar parts (ie pip install is what part of the java setup process?)

<comment><USER7> > but use a third party spell checking package. Both the venv and the jar will > contain that third party package

Jar files do not support including third party libraries. You simply cannot put a jar in a jar. Eclipse/maven etc can explode the dependancies class files inside of the jar, but people rarely do that for anything other then distributing binaries of client apps (licensing becomes a massive pain btw).

war/ear files on the other hand does support including dependant jar files.

<comment><USER6> I may have mis-spoke (could not re-read thanks to my antiprocrast) : I am thinking of a package format, probably more similar to .deb than .jar, that will drop the code I have written, plus the third party packages, plus the system level packages, ie all the dependancies that can get compiled)

The idea is to divide the Operating system from the application. There is never a good divide point but at some point we can say the chef/puppet/salt infrastructure will give us the operating system, and the big binary blob (.deb) will give us everything else.

Throw in configuration as a seperate function and I am going to have to lie down in a dark room.

</comment></comment></comment></comment><comment><USER8> > _Provided the developer is fully conscious that this is python-level-only > isolation, then it is useful._

Of course we know it's python level only isolation. We're still running in an OS with a filesystem and such. If we wanted something more we'd use jails or something similar.

> _Full methods of isolation make virtualenv redundant_

So what? They are too heavy handed, and 99% of the time, I don't want them anyway.

> _It is very, very easy to install something as large as a Django application > into a prefix. Easier, I would argue, then indirectly driving virtualenv and > messing with python shebangs._

You'd argue, but you'd lose the argument.

> _You need to preserve this behaviour right down the line if you want to run > things in this virtualenv from the outside, like a cron job. You will need > to effectively hardcode the path of the virtualenv to run the correct > python. This is at least as fiddly as manually setting up your PATH > /PYTHONPATH._

Yes, if only they gave you OTHER BENEFITS in exchange. Oh, wait.

In general, move, nothing to see here...

<comment><AUTHOR> > You'd argue, but you'd lose the argument.

Done it already, in production. The virtualenv fanboys didn't even notice. It's simple and elegant and works perfectly.

<comment><USER8> The argument wasn't that it can't be done.

It was that it's "easier" ("Easier, I would argue, then indirectly driving virtualenv and messing with python shebangs").

Also, "virtualenv fanboys"? Please, are we 16 years old?

</comment></comment></comment><comment><USER9> Why I love virtualenv and pip.

We use virtualenv and pip extensively here, with virtualenvwrapper.

      mkvirtualenv <project>
      workon <project>
      pip install -r requirements.txt

It just works. I don't spend any time on it. Our developers don't have any problems with it. All the other considerations in the article we either handle as you're meant to, or understand the limitations.

Still, looking forward to some interesting comments on here.

<comment><USER10> Did you actually read the entire article, or did you just come here to say that?

<comment><USER11> It extends to deployment. Off top of my head, the script that you have to write to trivially deploy with virtualenv is something like:

        virtualenv --no-site-packages -p$PYTHON $workdir
        "$workdir/bin/activate"
        (cd $my-package-dir && python setup.py)
        "$workdir/bin/deactivate"
        virtualenv --relocatable "$workdir"
        fpm -s dir -t deb -n "$package" -p "$package.deb" -d <system dependencies> ...

And you have a deb that you can just scp anywhere and it'll just work.

</comment></comment></comment><comment><USER12> Sure, pip's imperfect; I have to install the mysql header files, woe is me. But the cost/benefit tradeoff is better than LXC; pip gets me _most_ of the isolation with much, much less overhead.

Is the author really claiming that it's easier to script a non-virtualenv deployment than a virtualenv one? If so, great, do that - the _only_ reason I deploy with virtualenv is because, guess what, that's easier to script.

Why default to --no-site-packages? Because it helps and it's easy. No, I'm not perfectly isolated from my host system - but then the host system could have a broken libc and then nothing, not even LXC, is going to make your isolation system work. Just because you can't isolate perfectly doesn't mean there's no point isolating as much as you can.

Yes, pip builds from source. That's a lot more reliable than the alternative. The Java guys certainly _aren 't_ mocking you if they've ever done the actually equivalent thing, i.e. deploy a library that uses JNI, which is a complete clusterfuck.

(URLs as dependencies are indeed a bad idea; don't do that. The complaint about pip freeze is purely derivative of the other complaints; it's wrong because they're wrong).

<comment><AUTHOR> Yeah, the lxc package gives you command line tools that are a close analogue to virtualenv. Combine it with a filesystem like btrfs for copy-on-write, and it's FAR quicker too.

I'm glad you mentioned JNI. In Java, native is the exception. In python, it's much closer to the rule. A hell of a lot of python libraries rely on C components which leak out of a virtualenv.

Building from source isn't reliable. It's quite hard, not to mention relatively slow. See the great success of RPM and APT based Linux distributions as proof of this.

</comment></comment><comment><USER13> Why pip?

pip uninstall psycopg2

or

pip install --upgrade psycopg2

But I guess with easy_install you can fake it by running with -m and then deleting the errant egg files in lib and bin files. That's pretty easy, I guess.

Oh but hey, you know what you can do instead? Setup a virtualenv, easy_install everything and when it gets hopelessly out of date or munged, you can just delete the virtualenv directory and start again.

Snark aside, I would agree with the OP that the "feature" of installing via arbitrary URLs is an anti-pattern and encourages lazy development. Of course, not every package we build can be posted to a public package library, so there's always that issue with easy_install too. Sigh, what a mess we have. Good thing I'm still able to get work done with these tools :)

<comment><USER14> Good luck pip installing psycopg2 on Windows :)

<comment><USER13> Haha. Win-what? In my domain I am happily able to ignore almost all attributes of the Windows operating system. Well, except for IE <shakes fist of to the air>

</comment></comment></comment><comment><USER6> I think we should look back to the rant of Python Core Committer Hynek Schlawack. ([https://hynek.me/articles/python-app-deployment-with- native-...](https://hynek.me/articles/python-app-deployment-with-native- packages/))

In short build your system and it's dependencies once and once only then pass them around through test into live.

We have three competing needs: a reliable deployment process that can move a binary-like blob across multiple test environments

A need for exactly reproducible environments but without dd/ghosting

A desire to keep things simple

Isolation is good - whether through the mostly isolated approach of venv, the almost total isolation of jails/LXC or the vagrant approach. But they focus almost entirely on binary builds - how does one pass around a python environment without rebuilding it and it's dependencies each time ala pip?

Well by taking the running built python environments and passing them into a package manager like apt and calling that a binary. That might mean tar balling a venv or tar balling /use/local/python but in the end it matters that we pass around the same basic bits.

I am working this out in pyholodeck.mikadosoftware.com and in my head - when I have a good answer I will shout

</comment><comment><USER15> While I see where he's coming from, I really can't agree with many things he's saying:

 _" For python packages that depend on system libraries, only the python-level part of those packages are isolated."_

And there's nothing really bad about it. Well-written python libraries will work with any previous version of the library they're wrapping. They will also report incompatibilities. It's ok to use system libraries - especially if you're advocating getting rid of virtualenv as author does.

 _" Full methods of isolation make virtualenv redundant"_

Well... no. There are times when installing a local version of some library is required and it cannot be installed system-wide, or it will break system's yum for example. You're not only isolating your app from the system, but also the system tools from the app.

 _" virtualenv's value lies only in conveniently allowing a user to _interactively_ create a python sandbox"_

There's nothing interactive about what `tox` does for example and it's a perfect example of why virtualenv is useful. You can have not only a virtualenv for testing your app, but also multiple configurations for different selected extras - all living side by side.

 _" Clearly virtualenv advocates don't want any hidden dependencies or incorrect versions leaking into their environment. However their virtualenv will always be on the path first, so there's little real danger"_

Until you want the same package that's available in the system, but your app's version constraint is not looked at when the system's package is upgraded. Or you want different extras selected. Or your deps are incompatible with some- system-application deps, but you're calling it via subprocess (this is also where changing the python path in shbang comes useful).

Venvs are definitely not perfect, but for testing and installation of apps, they're amazingly useful. Binary libs issue is definitely annoying, but there's a different solution for it and I'm happy to see it used more often - don't compile extensions, but use cffi/ctypes.

</comment><comment><USER16> Companion read, "Python Packaging: Hate, hate, hate everywhere" by Armin Ronacher (June 2012): [http://lucumr.pocoo.org/2012/6/22/hate-hate-hate- everywhere/](http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/)

</comment><comment><USER17> Has anybody here used conda[1] for anything significant/serious yet? I've been using it in passing for my side and small projects but I'm still not convinced I want to go whole hog yet.

Regardless, my experience with it so far has been... ideal. It really makes building environments and linking/unlinking packages a breeze. I haven't needed it for building my own packages yet, so we'll see how that goes.

[1] [http://docs.continuum.io/conda/](http://docs.continuum.io/conda/)

<comment><USER18> If anyone needs more color, Travis, the CEO of continuum and the author of NumPy just wrote a great post explaining why conda exists, and why virtualenv and pip aren't sufficient for the scientific python community.

[http://technicaldiscovery.blogspot.com/2013/12/why-i- promote...](http://technicaldiscovery.blogspot.com/2013/12/why-i-promote- conda.html)

</comment></comment><comment><USER19> To both commenters so far I would like to say PEP-370, a new way since 2.7 to create virtual environments.

I started using it recently and I see no need for virtualenv anymore.

I have nothing to say about the pip issue though, never had an issue with pip myself.

<comment><USER20> Back in 2009, Jesse Noller wrote about his experiences with PEP-370 and seems to have felt that it is an improvement on the status-quo and a complement to virtualenv but not a replacement:

[http://jessenoller.com/blog/2009/07/19/pep-370-per-user- site...](http://jessenoller.com/blog/2009/07/19/pep-370-per-user-site- packages-and-environment-stew)

</comment></comment><comment><USER21> What has the author built to replace pip?

<comment><USER22> Amen.

Generic algorithm of making things better:

0\. Give it a go to fix it oneself first. Really.

1\. Failing the previous, raise the perceived deficiency with a specific and workable proposed solution.

2\. Failing the previous, indicate what's undesirable and how, and what behavior would be desirable.

3\. Failing the previous, put a monetary bounty on the feature, fork the project or live with it. Rewriting from scratch has a 99.99% probability of being several times more work than it seems.

<comment><USER23> Replied to wrong parent?

<comment><USER22> Nope. The claim calls out that the author complained without also offering a constructive, alternative solution.

<comment><USER24> While I don't agree with the author's views, I have to say that he _did_ offer the alternative solution of lxc or vagrant to more fully isolate his python environments.

</comment></comment></comment></comment></comment><comment><USER25> The lightweight part is pretty useful. LXC is definitely overkill. I don't want to have to bridge my graphics and networking over so that I can run programs against different versions of libraries. Going more lightweight, if I'm doing PYTHONPATH and PYTHONHOME, I would start scripting them, script the installation of libraries into my virtual environment that I just recreated badly...

\--no-site-packages has been default for a while. [http://www.virtualenv.org/en/latest/virtualenv.html#the- syst...](http://www.virtualenv.org/en/latest/virtualenv.html#the-system-site- packages-option)

I don't really see the argument about compiling against system headers and libs. Generally I do want to isolate my Python modules that are calling into other binary libs but don't care about isolating those binary libs themselves because their interface isn't changing when the Python wrapper for them changes. This is unless they are part of what I'm wanting to develop/deploy with, in which case the source will be in the virtualenv and install into the virtualenv using the config script at worst. A frequent example ends up being how Pygame will compile against some system libvideo.so, the behavior of which I never change, but may Pygames might have their own API's etc, and so the many compiled versions do have their own use.

Virtualenv is actually pretty noob friendly because one of the mistakes I see far more frequently than the others is that users will install things using pip system-wide that conflict with the system package manager. This can become pretty difficult to unscrew for inexperienced Linux users.

I've been meaning to actually add some virtualenv docs because of the frequency with which inexperienced Python and Linux users in general will waltz in and not be able to compile something because only the old version of Cython etc are on Ubuntu 11.blah and thus we start bringing in distribution- specific package managers into the realm Python package management was intended for and people try to figure out what version of Ubuntu they need instead of figuring out that they can install everything in one place in many instances and maintain an entire slew of projects without conflicts and without calling on IRC when synaptics clobbers things.

<comment><AUTHOR> There's a level between virtualenv and LXC, and that's schroot. Combine it with a CoW filesystem and that will cover everything you mention. Although personally, I find LXC very lightweight. Note that in my article, I did point out that I _do_ still use virtualenv sometimes :)

</comment></comment><comment><USER26> Interesting take on this. I think everyone just accepts pip + virtualenv as the only way to be without questioning it. You have definitely convinced me to reexamine that on my next project.

</comment><comment><USER27> Well, I really don't agree with any of the arguments in the article. I'll use the experience card and just say that I've been using virtualenv/pip for years and it always served me very well. Made development, testing, and deployment easier. Even if it's hackish and that there are more robust solutions, this one strikes a perfect good enough of quality versus time versus complexity.

</comment><comment><USER28> Here's an idea, if you want to convince me there's a better way of doing something, don't belittle me for the way I'm currently doing it.

I know pip isn't perfect. I know venv isn't perfect. They do work pretty well though. And when you find something that works well for you in your process, use it.

Some valid points (many of which have been on articles featured on HN before). Shame about the tone.

</comment><comment><USER29> Please take a look at using and building real packages for your system. RPM and APT. These are battle tested, they handle dependencies, transitive dependencies, multiple repo sources, {pre/post}{install/uninstall/upgrade} scrips. They provide a transactional way to add software to your systems.

You can use pip and virtualenv as well perhaps by creating a parallel Python install in /opt or something like that if needed. And then install that in an RPM if needed.

But if you are installing hundreds of binary files, dlls and using requirements.txt as the main way to specify dependencies you are probably going to end up with a mess.

It is much harder if you have multiple OS systems to support. Installing on Windows, RHEL/CentOS, Ubuntu and Mac OS X is hard in an easy and clean way. But if you target a specific server platform like say CentOS 6, take a look at RPMs.

<comment><USER30> This is pretty much what I often discuss with a friend of mine. Like you he always tells me to use RPM/APT instead of the Python stuff. But my goal is not that the stuff runs as clean as possible on one specific system, but that it runs on as many OS's as possible in relatively clean manner. If virtualenv doesn't tell my Ubuntu's APT that it installed some Python packages in ~/.virtualenv/project_one then an Ubuntu sysadmin will cry and try to kill me, I really don't care. On the other hand with virtualenv I can make sure, that my team leader can run the same command lines as myself and get my Python project running on his Suse box and the QA department can run my code on their Fedora as well. This is why I use Python and this is why I use virtualenv. I'm not happy with how things are in Python, but if I compare the problems between both solution paths currently I still think I'm better off with virtualenv and co.

<comment><USER29> You seem to have good reasons -- multiple OS-es.

I was just saying it is good to be aware of RPMs and APT packages. Even old and crusty setuptool has RPM support.

        $ python setup.py bdist_rpm

(add deps setup.cfg and make sure to have a MANIFEST.in file to add extra data besides python packages to the RPM package).

You seem to need multiple OS-es. That is hard and I haven't found a clean universal solution.

It also depends on the software. We have lots of mixed, C/C++/Node.js/Java/Python/big data files. Using virtinst/pip, then unpacking tar.gz, make ; make install , then java's (whatever it has) then npm all to setup a repeatable dev and test environment would be a horrible mess. That is what RPMs packages provide for us.

<comment><USER6> This is pretty much what hynek was on about (see my comment below) and what the guys at Parcel are doing (Iam a johnny come lately with pyholodeck) but we are trying to do the same thing - build once, package into apt/deb and deploy many times.

I think the argument above (boss runs different OS) is a fallacy - you want to deploy to the same target OS, probably in the cloud, so optimise for that first then fiddle with different OS. I guarantee people will prefer deploying a cloud server and logging in "just to see" and be happy with manually bringing things up with `setup.py develop` locally.

<comment><USER30> The code I write is a framework for testers and developers, though. So it won't run on many similar machines but on many very individual machines. But I guess it might even be possible to transform APT/RPM packages in each other and my guess would be that even yum can read one or the other, even if it's not its main package format (don't know Fedora very well).

You guys really got me excited about this. If I can get any air soon, I'll try to learn more about it!

</comment></comment></comment></comment></comment><comment><USER31> Isolating an entire environment is a better idea than isolating a python environment, but isolating a language's environment is an easier problem to solve, so the tools for it are currently better. I doubt we'll all be doing it this way in 2020, but it works pretty well right now.

</comment><comment><USER32> My friend who is a python guru uses buildout for all his apps.

Some of the recipes I have seen go more into configuration-management-like stuff but it is cool to see a single buildout script deploy nginx, DB, deps, and app in one go, on any linux box.

<comment><USER33> _it is cool to see a single buildout script deploy nginx, DB, deps, and app in one go, on any linux box._

Would anyone please link to a practical, working example of this? I want to use buildouts, but I learn from example, and there seem to be very few examples of how to deploy a production configuration. How do the pros do it? What are the gotchas? Is there a book I can buy? Will someone please put together a PDF explaining all this, so that I can throw money at you?

EDIT: Arg, that's exactly what I mean... [https://github.com/elbart/nginx- buildout](https://github.com/elbart/nginx-buildout) is an ok example just to learn the basics of buildout, but making it "production ready" (i.e. extending it to build postgres, etc) is left as an exercise for the reader. I was really hoping to find a production buildout example... (But thank you, rithi! I appreciate you took the time to dig that one up for me.)

<comment><USER34> I'm not sure I'd advocate using buildout for this, but as (you've probably seen) there are a few recipes for stuff like haproxy[ha], varnish[va], postgres[pg] and nginx[nx] available.

An example of how to combine many of these, for deploying a complex stack, could be:

[http://www.martinaspeli.net/articles/an-uber-buildout- for-a-...](http://www.martinaspeli.net/articles/an-uber-buildout-for-a- production-plone-server)

Another somewhat complex example:

[https://github.com/kybi/buildout-openerp- postgres](https://github.com/kybi/buildout-openerp-postgres)

You might also find this enlightening: [http://glicksoftware.com/blog/using- haproxy-with-zope-via-bu...](http://glicksoftware.com/blog/using-haproxy-with- zope-via-buildout)

[pg] [https://github.com/securactive/sact.recipe.postgresql](https://github.com/securactive/sact.recipe.postgresql)

[va] [https://github.com/collective/plone.recipe.varnish](https://github.com/collective/plone.recipe.varnish)

[ha] [https://github.com/plone/plone.recipe.haproxy](https://github.com/plone/plone.recipe.haproxy)

[nx] [https://github.com/collective/plone.recipe.varnish](https://github.com/collective/plone.recipe.varnish)

</comment></comment></comment><comment><USER35> I agree that developers using virtualenv should be aware that it does not provude isolation for system dependancies. On two different projects, I've had to track down a PIL bug on another developer's machine only to find that the wrong version of libjpg or libpng was installed. Solution? Install the right version. I've never experienced needing different versions of a system library, but if I did, LXC with btrfs sounds like an option worth trying to avoid the overhead of vagrant.

</comment><comment><USER36> I think the author is just misunderstanding what virtualenv is for. I use it to run different python package versions on the same system. With Pythonbrew ([https://github.com/utahta/pythonbrew](https://github.com/utahta/pythonbrew)) I can even run different versions of Python alongside each other. It's not meant for easier deployment, it's meant for easier development.

</comment><comment><USER37> It depends on what you want. Ultimately, the holy grail is being able to build, today, a bit-for-bit identical binary to whatever you are running in production that you built a day, a week, or a month ago. That way, if you need to debug something obscure, you're not adding extra variables to the equation.

But most people just want to be able to write two apps that use different libraries, and for that, virtualenv is fine.

</comment><comment><USER38> Whenever I set up a new Django project, it was always a bunch of boilerplate work to get virtualenv setup. Then if you forgot a step you would have to look into what is wrong.

After spending some time with Node.js, I have become spoiled by how well npm works for everything. Albeit, if you want to mess with node versions you need something like nvm, but it is easy to get the hang of.

Seeing something as simple as npm for python would be awesome.

<comment><USER39> There's nothing in node that can replace Django. Django does so much.

NPM is a wasteland of abandoned projects and nested npm_modules with broken symlinks to or from a bin that'll never work on your vm's shared directory (unless it's VMWare I guess, some kind of secret sauce they use).

Having said that, they're all ok tools that people use to build pretty cool things. I just think there's got to be a better way, and I think it's somewhere in between an extern and npm/pip thing where you store your dependencies somewhere where you don't have to worry about a site being down during deploy and versioning issues.

It's like you freeze and shrinkwrap, but by actually capturing everything you need once your shit works and putting it somewhere where you control not someone else.

<comment><USER40> If you're deploying an application (really, if you're working on anything _other_ than a library intended to be used by many other projects) check in your dependencies. This solves a lot of problems regardless of what language/platform you're developing on.

</comment></comment></comment><comment><USER41> Well one reason to use pip over easy_install is that pip uses https by default and easy_install doesn't

</comment><comment><USER42> Who is dissent? Who is this 'Adam' guy?

No other posts on this 'python rants' blog, nothing else on HN?

IMO this is _astroturfing_ ( [http://en.wikipedia.org/wiki/Astroturfing](http://en.wikipedia.org/wiki/Astroturfing) )

<comment><USER43> Astroturfing generally requires a company backing the movement. Why would a company care enough about pip and virtualenvs and then want to hide that? I didn't see an alternative offered besides using existing open source tools.

<comment><USER42> docker.io comes to mind.

<comment><USER44> I actually did not know about this thread until you mentioned Docker in it.

And after reading it, I've realized I've been plain wrong in how I've been constructing my python related Docker containers.

Full disclosure: I love pip. I love virtualenv. I use them religiously.

I also work for the Docker team.

</comment></comment></comment></comment><comment><USER45> I like pip.

I don't like virtual env quite as much, but maybe I haven't juggled enough python versions at the same time (I don't often work on such disparate codebases that virtualenv becomes a real need, and it's a little obtuse to set up for me)...

</comment><comment><USER46> virtualenv isn't made redundant by Vagrant at all; I use them together all the time. The remote server I deploy to is completely different from my development machine, so I use Vagrant to simulate the remote environment. Since I'm on shared hosting, though, I use virtualenv to make sure that my app isn't depending on shared modules that are out of my control. It's also a LOT more reliable than trying to deal with a userdir python build or pip --user, where you'll probably end up fiddling with envvars anyway, except worse because you'll be doing it by hand instead of through a script.

</comment><comment><USER47> Binary python packages are useless IMHO. If I want binary packages, I make a binary package for my package management system. Running pip/easy_install on a production system is an anti-pattern.

<comment><USER30> You summarize one point I learned from this article and the comments: deployment and development is not the same. On the development machines it might make sense to easy_install complete package trees, but in a deployment environment the most important concern is a clean system wide package management and for that I need binary packages in a format that the system's package manager understands.

Thanks.

</comment></comment><comment><USER48> To each his own, I guess. They, together, are two of my favorite tools. Never had a problem with either of them.

</comment><comment><USER49> Oh dear. What's the right way then?

<comment><USER50> LXC + eggs + setuptools + something, I guess?

As a current member of the `pip freeze > reqs.txt' brigade, I'd be interested in seeing a more detailed look at how to do it "right"/better.

<comment><USER47> Just create a setup.py and put your deps in there.

<comment><USER51> Ideally, setup.py is for generic minimum-version-known-to-work dependencies of a package. Pip requirements files are for very specific known-good combinations of dependencies of an application. [https://caremad.io/blog/setup-vs-requirement/](https://caremad.io/blog/setup- vs-requirement/)

<comment><USER47> It's an anti-pattern to not pin versions in libs. setup.py is a contract. Every version listed as a dependency should have been tested, otherwise the package will bitrot. It should be safe to pin major versions, if you can trust upstream packages to follow best practices with version numbers and you aren't using any "undocumented" features of the lib. Ideally, your packages are tested and built into binary packages before they are deployed to production systems. If you are following that best practice, then your risk of a patch breaking your system are minimized.

</comment></comment></comment></comment></comment><comment><USER52> one should hate something when that thing is something he dislikes but most importantly it is forced on him or her. I am criticizing only the title, he might be right about these tools, but using agitative words does not make an argument better.

<comment><AUTHOR> I admit I'm stirring things up a bit here. You're quite right that I'm venting.

</comment></comment><comment><USER53> :+1: And the same holds for rbenv and rvm for Ruby.

</comment><comment><USER51> I'd put it a bit more broadly: The state of working with Python packages has been painful for many years, and despite recent improvements and ongoing heroic efforts to fix things (thanks Tarek in particular), it's still not much fun. Piling on hate doesn't help anybody though.

There's some history worth considering. LXC requires Linux >= 2.6.24, released 24 January 2008. Virtualenv was released in October 2007. So LXC was hardly an option at the time.

Virtualenv was, I think, a pretty good attempt at a pragmatic solution for purely python-related dependency management issues at that time. I found it a hell of a lot easier and quicker than chrooting or building a whole new python installation (I used to do that) or using (shudder) zc.buildout. System-level virtualization was pretty heavyweight in 2007.

I think maybe virtualenv is showing its age a bit; I agree with that the system library isolation issue is a huge hole in the virtualenv approach. But often, it's enough to get work done.

As for pip vs. easy_install, anybody who was around at the time (sorry I can't tell from the pythonrants blog if that includes "Adam" or not) remembers that life with easy_install was horrifically painful. It was buggy, often failed with completely unhelpful messages, and issues with it (and setuptools more generally) were simply not getting fixed at all. For _years_. (That is finally changing more recently, thankfully.) Pip was intended to route around all that (while still using setuptools internally) by doing less and by having less painful failure modes. As one example: if you tried to easy_install a bunch of packages, or one package with a bunch of dependencies, and one somewhere in the middle failed because it couldn't find a dependency, you'd end up with a fucked environment that had half of the packages installed and half not. And since there was no easy_uninstall, you had no easy way to clean up the mess. And you wouldn't even have any easy way to know what actually depended on the dependency that failed to install. Pip took the much nicer approach of downloading everything, resolving all dependencies, trying to tell you what depended on something that couldn't be found, and building everything before installing any packages at all. So if there was a failure prior to the installation phase, it had no effect on installed libraries at all. It's hard to overstate how much pain relief this provided.

For another example: setuptools and easy_install allow installing different versions of the same package into the same python environment at the same time. I'm not sure why that was ever considered desirable, because every time it actually happens, it's been a source of nothing but pain for me and didn't even seem to work as advertised. Pip took the opinionated approach that only one version should be installed and if you want different versions for some other application, just go build a separate environment for it (virtualenv or no).

I agree that the –no-site-packages vs. –system-site-packages options to virtualenv are problematic, but for me that's largely because it amounts to a binary choice between having to build all C extensions from scratch vs. having to depend on whatever happens to be installed system-wide, which is a pretty poor choice to have to make.

As for the statement that "there's little real danger" because "their virtualenv will always be on the path first", he's forgetting (or possibly doesn't know) that the easy_install.pth file messes with sys.path as well. I had several hair-tearing sessions trying to figure out why on earth the wrong version of some package was getting imported before I realized that. At one point I found that import behavior changed depending on which version of setuptools or distribute I had installed. That was fun.

It's also true that people often misuse requirements files. I don't think that's the fault of the tool. Depending on the current commit of some master or other branch is idiotic regardless of what mechanism you use. Depending on a specific tarball URL is no more or less reliable than depending on a specific package version being available via pypi (hasn't everybody had the experience of somebody yanking away a package version you depended on?). The right thing to do is probably neither, but to host all your dependencies somewhere that you control (whether that's your own python package index or .deb or .rpm server or whatever).

<comment><AUTHOR> > he's forgetting (or possibly doesn't know) that the easy_install.pth file > messes

The .pth files don't do anything until their own paths are added to sys.path. It's safe to consider directories with .pth files as if they contain python modules.

</comment></comment><comment><USER54> ridiculous.</comment>


Ask HN: Someone is using my email to register to a bunch of services - <AUTHOR> Hey all,
In the last 20 minutes, I got probably around 200 emails congratulating me on registering to the website/newsletter.
This is my personal email
In addition, my credit card has been used to purchase 850$ worth of goods (called Amex, canceled the card).
I changed my email password obviously, canceled the card.
What else can I do? Did this ever happen to you? Have any advice? <comment><AUTHOR> I am posting some information here in case someone encounters this.

This seems like a type of DDOS attack to hide an email from a financial service.

All of these emails are essentially meant to hide the order of 850$ in the flurry of other emails.

Some information from a Google thread: [https://support.google.com/mail/forum/AAAAK7un8RUCTPjR3thcdQ...](https://support.google.com/mail/forum/AAAAK7un8RUCTPjR3thcdQ/?hl=en- GB)

</comment><comment><USER2> You can check something like [https://haveibeenpwned.com/](https://haveibeenpwned.com/) to see if you can locate where the breach came from. Other than that you just have to assume the worst and start rotating all your passwords and keys. Turn on 2FA for everything.

</comment><comment><USER3> I knew a guy who had a very common email address (like jsmith at popular provider), and it was pretty common for people to sign up to services using that address.

For well designed sites that require verification before the account is setup, just trash the message.

For other stuff, you may have to unsubscribe.

Worst case scenario for something like a dating sites or whatever, you can just reset the password, then login and delete/deactivate the account.

<comment><AUTHOR> This seems scripted. My email is not common.

I am getting ~300 of these from different websites, newsletters, etc.

[https://assets.avi.io/Contact_form_-_avikensodev.com_- _Kenso...](https://assets.avi.io/Contact_form_-_avikensodev.com_- _KensoDev_Mail_2020-04-23_11-58-48.png)

<comment><USER4> I wouldn't open the email, click links, or open attachments. Can you think of any place you may have submitted your email or made it public?

</comment></comment></comment><comment><USER5> A credit freeze might be in order:

[https://www.consumer.ftc.gov/articles/0497-credit-freeze- faq...](https://www.consumer.ftc.gov/articles/0497-credit-freeze-faqs)</comment>


Top 5 tools every serious Linux user should have - <AUTHOR> http://blog.atlanticmetro.net/2013/07/02/top-5-tools-every-linux-server-should-have/

<comment><USER2> Article title is _"Top 5 tools every Linux server should have"_.

Why has it been posted here as _"Top 5 tools every serious Linux user should have"_?</comment>


Uber CEO calls for new ebenfits system for gig economy workers - <AUTHOR> http://thehill.com/policy/technology/370506-uber-ceo-signs-letter-calling-for-portable-benefits-to-help-gig-workers <comment><USER2> Not necessary. Let Uber and Lyft run out of venture capital and start running their businesses in a P&L world and they'll soon have to adapt to markrt realities, including establishing a benefits system to keep the people who work for them today working for them in the future.

<comment><USER3> Considering they don't plan to keep any human drivers past the point self driving cars come out, this feels disingenuous

<comment><USER4> Neither rideshare company will last long enough to see self driving vehicles come to fruition.

</comment></comment></comment><comment><USER5> I don't see how the government is going to continue letting companies get away without paying employment taxes on all these workers.

Guess by the time they realize they are losing that revenue the self driving cards will be here.

</comment><comment><USER6> Hard to imagine this won't end up looking like a private exchange without subsidy. Except in this case, the union is involved and would act as the arbiter of a "dues to benefits" model. I think this perhaps the only way this could work.

</comment><comment><USER7> How did you misspell "benefits" offsetting both non consecutive "e"s backwards?

<comment><USER8> I would write this with one hand on E and the other one on B and N. All it takes is to get out of sync (and it happens to me fairly often when I sit at the computer after a longer period, e.g. an hour).

</comment></comment><comment><USER9> New leadership is proving to be adept at messaging all the right things. Looking forward to see if they're able to go beyond that.</comment>


Show HN: An "ethical" YouTube auto ad skipper chrome extension - <AUTHOR> https://chrome.google.com/webstore/detail/youtube-auto-ad-skipper/ibpnocgpjfpblfhciempjbmahomooiah <comment><AUTHOR> Hi HN. This is my first published chrome extension :). I always skip ads in such a way that content creators get paid. But doing that manually especially with playlists can be a little tiring. So I made this extension to do it for me. It's open source as well

[https://github.com/spartakode/Youtube-Ethical-Ad- Skipper](https://github.com/spartakode/Youtube-Ethical-Ad-Skipper)

</comment><comment><USER2> You wanna read my YouTube data, eh? No no!

<comment><AUTHOR> Sadly I'm not in charge of the wording that Chrome puts out. Else it would read "wants permission to see if your URL is a YouTube URL and then insert some JS to control the mute and skip ad button" :D

If it helps, the source code is open so you can check out that no funny business is going on :) [https://github.com/spartakode/Youtube-Ethical-Ad- Skipper](https://github.com/spartakode/Youtube-Ethical-Ad-Skipper)

</comment></comment><comment><USER3> How is this legal?

<comment><AUTHOR> Clicking on ads themselves wouldn't be legal. Since this doesn't circumvent normal behaviour and actually waits 31 seconds before skipping an ad, it def isn't illegal. There's no trickery involved either. It's just doing what the user would ideally do under normal circumstances but doing it automatically.

</comment></comment><comment><USER4> It's not entirely ethical because the advertiser gets ripped off. It increases their cost and reduces what they are prepared to pay for ads. If everyone else used it, content creators wouldn't get paid eventually. If YouTube was independent from Google it would die.

<comment><AUTHOR> Thanks for the comment here. I spent some time thinking about this topic. I've done a write up here if you are interested - [http://blog.spartakode.com/an- ad-skipper-for-youtube-that-pa...](http://blog.spartakode.com/an-ad-skipper- for-youtube-that-pays-the-content-maker/#isitreallyethical)

The argument can be summarized as:

1\. Skipping ads quickly on every chance you get means you are watching the video for "free". Which isn't fair to the creator

2\. Not skipping ads in order to support the creator isn't great for advertisers either.

3\. That said, Google is moving towards deprecating 30 second unskippable ads (unskippable ads will have to be 15-20 seconds or less). This means that users in general view ads longer than 20 seconds to be intrusive which means that the majority of people are likely skipping ads unless they are really compelling.

4\. It's an unfortunate situation to be in but I choose to side with the content creators since ultimately they drive the whole site. YouTube ads should in the future normalise towards the better format of 15 seconds or less and most of them will become unskippable. This will happen regardless of this extension especially given that the majority of their traffic will come from mobile anyway.

5\. Thus in the practical view of things, this chrome extension is likely to be used by a maximum of 1000 users (being extremely generous here). The market says that people just want to skip 5 seconds in. Not be ethical. And so I resolve the ethics conundrum within myself by accepting that this isn't likely to affect the YouTube eco system as a whole negatively, but it will at the very least, play a tiny part in contributing to the creators well being over time.

Last note: I really love YouTube Red. I broke borders using my VPN to get it but the hassle of having to keep the VPN going to use it especially on the mobile is a problem. Also I'm scared that YouTube will ban my entire Google account for breaking ToS so I stopped. The day they make it available globally, I'll be a happy person with a credit card at the ready :).</comment></comment>


Realtime GLSL Pathtracing (WebGL) - <AUTHOR> https://geometrian.com/programming/webgl-pt/ <comment><USER2> Nice work; I remember creating a raytracer of a similar scene for my uni graphics class begin 90s on a Sparc Station. I thought it was fast then, but ofcourse it was bizar slow compared and the result looked horrible.

On Chrome 70.0.3538.77 64bit on Windows 10 supersampling 16x16 crashes OpenGL for me; when reloading the page after that it says it cannot get a rendering context.</comment>


The cost of transpiling ES2015 in 2016 - <AUTHOR> https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016 <comment><USER2> Personally I find the advantage of using ES2015 over ES5 marginal for most use cases, so I actually went back to writing "traditional" ES5 JS with require.js imports and only use a JSX->JS transpiler for the React part of my code. This helps me a lot to stay "closer" to my code and reduce the complexity of my build chain.

Many things that ES2015 provides are nice of course and the code looks a bit cleaner, but apart from a few real innovations most changes seem to be syntactic sugar.

Also, I found that each step in my build chain made it more complicated to build and maintain my code, especially for other developers. I eventually even abandoned Gulp (which in my opinion tries to reinvent Unix pipes but does it all wrong) in favor of a simple Makefile that chains a few build commands and uses inotifywait to watch the filesystem for changes in order to automatically rebuild the code during development.

Another thing I do which may shock many JS people is to actually check in the build directory of my setup into version control, because this makes deployment much easier and ensures that I will always have a working version of the code in the repository, even if some external dependencies should change in the future. This also eliminates installing extensive tooling on my production servers, which itself is a large burden and creates many security issues (for a simple setup consisting of rabel, react, require.js and a few support libraries, node.js downloads about 350 MB of source files onto the machine).

<comment><USER3> I agree, and I think ES5 even has a benefit as a language: it's extremely simple. The trajectory of ES2015 seems to be, basically: add as much cool stuff as possible. Thus increasing the syntactic surface area, and the amount of stuff to learn.

With a slightly more clever and more concise definition of `createElement`, I also have no need for JSX.

        tag("div.widget.fancy", {}, [
          tag("h1#title", {}, "Hello, world!")
        ])

I'm fine with that. My editor understands the indentation.

And... such an enormous benefit... there is no compilation step.

Right now at work, our code base takes 20 seconds to compile with Babel. Enough said.

The feeling, after being used to all this transpilation business, of writing code that's just already ready to serve, is very nice. I can even work on it with nothing but a text editor and a web browser.

Unfortunately everyone thinks I am crazy for preferring this.

<comment><USER4> That looks a lot like the element builder function that Fastmail put together back in 2012.

[https://blog.fastmail.com/2012/02/20/building-the-new- ajax-m...](https://blog.fastmail.com/2012/02/20/building-the-new-ajax-mail-ui- part-2-better-than-templates-building-highly-dynamic-web-pages/)

I too am fond of that approach.

<comment><USER3> Yeah, same idea.

The dream that designers, being comfortable with HTML, would be able to mess around with JSX is, as far as I can tell, unrealistic anyway, because it's always full of React-specific weird stuff that the designer doesn't understand and doesn't want to mess with.

<comment><USER5> You should separate your Presentational and Container components [0]. Presentational components can be pure and stateless, containing no/minimal _React-specific weird stuff_ \- that should go into the Containers.

[0] [https://medium.com/@dan_abramov/smart-and-dumb- components-7c...](https://medium.com/@dan_abramov/smart-and-dumb- components-7ca2f9a7c7d0)

</comment></comment></comment></comment></comment><comment><USER6> The cost of transpiling es2015 isn't very visible here, because the "vanilla es6 TodoMVC" example used [1] doesn't rely heavily on ES6 only features, such as generator functions etc., that aren't just sugar on top of ES5. Such features are expected to decrease the performance of the generated code significantly and should be taken into account when a transpilation step is involved.

[1] [https://github.com/tastejs/todomvc/tree/master/examples/vani...](https://github.com/tastejs/todomvc/tree/master/examples/vanilla- es6)

</comment><comment><USER7> Not sure why this is linking to a fork of the original repo.

It was discussed recently here: [https://news.ycombinator.com/item?id=11021271](https://news.ycombinator.com/item?id=11021271)

<comment><USER8> Yah... I'm confused as well. :/

But I did work with Sam on this project and I think it's quite worthwhile!

<comment><USER9> what happened to tambourines lol

</comment></comment></comment><comment><USER10> We've been using Closure to minify our code for years. It's extremely slow (I think it takes a minute or so on our codebase), so we only do it for deploys.

It produces smaller code than minifiers such as Uglify, even though we're not using its coding conventions (Closure is designed to optimize code written in a certain way that allows it to eliminate dead code paths).

<comment> rafael-rinaldi If I was you I would give Rollup a try: [http://rollupjs.org](http://rollupjs.org)

I used to minify with Closure as well (through r.js) and it would take forever.

<comment><USER10> We're using Browserify — can you use Rollup with it? Closure's slowness isn't really a problem for us since we only use it for deploys, not while deveoping.

Edit: I see, Rollup is a competitor to Browserify. Looks nice, if somewhat immature. Maybe we'll be able to use it.

</comment></comment></comment><comment><USER11> Transpiling is temporary. Soon browsers will catch up and many of these tools will no longer be needed. Unless, of course, everyone wants to start using ES7 when browsers actually support ES6. JavaScript is maturing, this is good news. We are lucky so many tools have become available.

<comment><USER12> Browsers will always lag behind specifications.

<comment><USER13> Yes, I'm not sure why transpiling will ever go away. Not sure either why it would be limited to specifications.

<comment><USER14> Transpiling will go away when people stop trying to push their own web- breaking language.

It wasn't cool for Microsoft to push JScript in the 90s, why is it cool now for it to push TypeScript? And allied with Google, no less!

<comment><USER15> Because:

1\. JScript added conditional compilation directly in the browser which was IE-only (extend, extinguish). TypeScript compiles to cross-browser JavaScript (which does none of the above)

2\. TC39 is supposed to be working in a "pave the cowpaths" (1) mode. Before new features get integrated into EcmaScript, TC39 looks into what the community is already doing (existing cowpaths), then integrates that into the language. Not only that but TC39 can learn from the mistakes of TS and Flowtype when they add type system support in EcmaScript. We are in dire need of one - and thanks to Microsoft's and Facebook's explorations, we now know what kind of type system would work for JS.

(1) For example, we got arrow functions in ES2015 thanks to CoffeeScript.

</comment></comment></comment></comment></comment><comment><USER16> It's worth mentioning that I spoke to Guy Bedford (author of JSPM) after Sam put out this article. He thinks he can get JSPM's times down pretty easily and he's putting some effort into it this week.

I wouldn't let anyone interested in trying out JSPM be jaded by these numbers just yet. JSPM v0.17beta-6 hasn't reached fully stable yet and that's what's being used to generate these #s

<comment><USER17> JSPM is slow to build but I don't see much utility in building during development when on-the-fly transpilation can be used instead.

In terms of using JSPM to create builds for production, it seems significantly easier to setup than the equivalent using gulp, browserify, webpack.

<comment><USER18> Easier than Webpack? I dunno about that. I have major gripes about webpack, but being difficult to set up is not one of them.

<comment> rafael-rinaldi The problem with Webpack IMO is that it kinda feels like Grunt sometimes where you find yourself editing a giant nested config. But it is by far the most flexible tool for the job and setting it up without all the fancy stuff is pretty straightforward.

</comment></comment></comment></comment><comment><USER19> Related: Performance of ES6 features relative to the ES5 baseline operations per second. - [http://kpdecker.github.io/six- speed/](http://kpdecker.github.io/six-speed/)

</comment><comment><USER20> I think one could transpile to javascript compatible with the Google Closure compiler which does dead code elimination. Someone's probably already on it.

<comment><USER21> Google Closure compiler seems to already support this out of the box: [https://github.com/google/closure- compiler/wiki/ECMAScript6](https://github.com/google/closure- compiler/wiki/ECMAScript6)

Edit: s/good/support/

<comment><USER20> Have they figured out a solution to the string/property access problem preventing us from passing all js through Closure compiler? (To those who aren't aware, Closure compiler is already an excellent compiler stack, but it requires you write a specific subset of javascript[1], so real-world js written without specifically targetting Closure are generally not compatible. Closure compiler is not currently useful to a javascript developer who depends on the npm ecosystem)

[1] e.g. write foo.bar instead of foo['bar'], so Closure compiler can do name mangling and dead code elimination.

edit since i currently sit at zero points: my point being that you can't dead- code eliminate your dependencies, which is the whole point of using closure compiler instead of whatever other toolchain.

<comment><USER10> Can you explain by what you mean by "requires"? We're using Closure to minify our code, and it works fine. We know that it's not able to do all the optimizations it can (it was made to follow Google's specific conventions, after all), but it still produces smaller code than minifiers such as Uglify, so it is useful.

<comment><USER22> The Closure compiler is definitely at it's best when you have all optimizations and are JSDoccing like they intend. While you get some out of the box, it's not the full power of it.

</comment></comment></comment></comment></comment><comment><USER23> wait.

Browserify is for package-management. For people who want to do node.js style requires in their browser.

Closure Compiler is for optimization, it is to get rid of dead code.

Browserify is not optimized for performance. Why is this post surprising ?

<comment><USER24> This confused me as well. The point of browserify is that it groks npm versions and wrangles your dependencies. Whether you want to transpile or uglify etc. is orthogonal to whether you need browserify/webpack, isn't it?

<comment><USER25> There wouldn't be a bundle for Babel to transpile if the code wasn't Browserified first. I don't know much about Closure compiler but apparently it handles both the transpilation step and the bundling step.

<comment><USER24> I think that closure and other transpilers do "bundle", but only in the sense that they resolve explicit ES6 imports. They don't attempt to grok versions or dependencies the way browserify/webpack do.

</comment></comment></comment></comment><comment><USER26> Wait what?? I thought ES2015 was just another name for ES6?? This is too much...

<comment><USER27> Yes, what used to be called ES6 has been renamed ES2015.

What's the problem?

<comment><USER26> Knee-jerk reaction comment when I read "There are a lot of tools to compile es2015 to es5", I had to take a second to realize what was being said.

Getting all the Lego pieces of JS webdev scattered on the floor straight in one's head is sometimes a pain when one's job only has one venturing into the front end every couple months, thus having to relearn all the acronyms and such.

<comment><USER28> > when one's job only has one venturing into the front end every couple > months, thus having to relearn all the acronyms and such.

To be fair, in my experience that holds true for any technology you only touch once every couple months (especially when you then quickly move on to other things again).

</comment></comment></comment></comment><comment> vladimir-y Nowadays any a bit complex JS application needs to transcompile. If so then why not do that with TypeScript since it supports ES6 stuff, but in along with that provides unique features such as optional typing which might be very helpful for a large projects and large/distributed teams (due to static typing) and generally for building a maintainable code structure.

</comment><comment><USER29> Javascript is kinda messy. So many things needed to get stuff working right. Uglyfy, browserify, babel.

Will there ever be an alternative language that can allow me to just: write, compile, run in browser?

<comment><USER30> I assume your comment is sarcastic, because Javascript is obviously the only language which you can just write and immediately run.

<comment><USER31> ...if you don't work in any company with a convoluted build process that includes transpiling (which is nearly all of them).

</comment></comment></comment><comment><USER32> I would love to see Elm added to the list.

<comment><USER33> Just try using the Elm compiler to translate an ES2015 program to ES5 and you'll quickly figure out why it's not on the list.

</comment></comment><comment><USER34> I just wanted to the point out that the actual overhead of transpiling the module in Closure is zero.

Here's a link where you can see the module boilerplate "compile away" [http://goo.gl/fR3BjQ](http://goo.gl/fR3BjQ) (Choose Advanced Mode)

</comment><comment><USER25> It's interesting how these tools pretty much ignore the issue of source maps. If you want your code minified and tree-shaken no problem, but if you want to the source maps split into an external map and still have your debugger actually work, well, good luck.

<comment> rafael-rinaldi Not sure what you mean. Can you elaborate?

</comment></comment><comment><USER35> What is holding up the major browsers from implementing es6 natively?

<comment><USER36> Nothing really, but a lot of users may be stuck on older browsers. With government agencies or banks or the like, they tend to not upgrade until the last day that their current setup is supported. The cost of upgrading infrastructure is far too great to be justified by non-tech savvy higher ups who fail to understand security risks of not regularly upgrading systems.

So, developers are stuck programming for some ancient godawful version of Internet Explorer that barely even supports ES5.

<comment><USER35> But that's them. I want to develop ES6 in my browser natively and offer my app to people with modern browsers. I don't care about those stuck in the past. Why don't the browsers support it? Browsers support WebGL today where i can run advanced 3D graphics in my browsers. Government workers on Netscape 4.7 won't be able to run but still the browsers have that. Why not ES6? Surely webgl is more complex to implement...

<comment><USER37> Browsers are adding support now: [https://kangax.github.io/compat- table/es6/](https://kangax.github.io/compat-table/es6/). Upcoming Chrome releases will have 90%+ compatibility if you only care about bleeding edge browsers.

<comment><USER36> Yes, and as a corollary to my comment above I do have my own apps that I write that are entirely in ES2015 (aka ES6) and haven't found any features that I really want to use that aren't implemented by the big browsers (Chrome, Firefox, Safari, Edge). No transpiling needed; it seems like transpiling is only _really_ needed if you want to support legacy versions of Internet Explorer.

Only Internet Explorer lags behind, but I'm not opposed to putting a warning when somebody visits with Internet Explorer when its my own little app.

<comment><USER35> Actually, I firmly believe that this applies to big apps as well. From my experience, if there is an app a user needs and it requires the user to upgrade their browser? They will upgrade their browser. Most don't upgrade because nobody asks them to. If a need arises in a corp environment to use an app with the simple requirement of a modern browser - they will upgrade it. If the apps always "allow" sub par browser support and bend over backwards for it - there will never be a reason for people to upgrade.

</comment></comment></comment></comment></comment></comment><comment><USER38> Maybe this should link to the upstream? [https://github.com/samccone/The-cost- of-transpiling-es2015-i...](https://github.com/samccone/The-cost-of- transpiling-es2015-in-2016)

<comment><USER39> Good catch. Url changed from [https://github.com/paulirish/The-cost-of- transpiling-es2015-...](https://github.com/paulirish/The-cost-of-transpiling- es2015-in-2016).

</comment></comment><comment><USER11> The name "closure" is confusing since it's actually Google's Closure Compiler here and not the Clojure language [https://developers.google.com/closure/compiler/](https://developers.google.com/closure/compiler/)

<comment><USER40> The language is spelled "Clojure" if I'm remembering correctly

<comment><USER11> yep correct, my mistake!

</comment></comment></comment><comment><USER41> samccone works hard at this stuff, link to the original repo.

<comment><USER39> Done, but in the future please include a URL the way [https://news.ycombinator.com/item?id=11059143](https://news.ycombinator.com/item?id=11059143) did, and then we can act on your suggestion.

</comment></comment><comment><USER42> I hate when people avoid clarity in titles and such.

For mere mortals, ES2015 (or ES6) is the latest version of [https://en.wikipedia.org/wiki/ECMAScript](https://en.wikipedia.org/wiki/ECMAScript), a Javascript specification.

(now I am expecting a lot of down flags, just because of my tone. Perhaps deserved. You judge).</comment>


Submissions of the Twitter Account Verification Story - <AUTHOR> Clearly a popular story - links in the comments here ... <comment><AUTHOR> [https://news.ycombinator.com/item?id=12125386](https://news.ycombinator.com/item?id=12125386) (verification.twitter.com)

[https://news.ycombinator.com/item?id=12124662](https://news.ycombinator.com/item?id=12124662) (theverge.com)

[https://news.ycombinator.com/item?id=12124575](https://news.ycombinator.com/item?id=12124575) (support.twitter.com)

[https://news.ycombinator.com/item?id=12124294](https://news.ycombinator.com/item?id=12124294) (thenextweb.com)

[https://news.ycombinator.com/item?id=12124048](https://news.ycombinator.com/item?id=12124048) (support.twitter.com)

[https://news.ycombinator.com/item?id=12123371](https://news.ycombinator.com/item?id=12123371) (prnewswire.com)

[https://news.ycombinator.com/item?id=12123361](https://news.ycombinator.com/item?id=12123361) (verification.twitter.com)

So far a couple of comments, and very few upvotes.</comment>


Show HN: Review site about Verbs aka Death of Specs - <AUTHOR> http://www.mutvak.com/

<comment><AUTHOR> Hardware specs for the computer and electronics products are now so advanced that we can say that all those manufacturers are on a very similar level. Intel&AMD has stopped Gigahertz race, Canon (and all) has stopped Megapixel race. These examples can be extended. However, as dramatic as these and other changes are occuring, product reviews (sites) are largely stayed same. Still comparing which one has fastest CPU or scored more than 329874 on xyzMark. I know there are some vertical (niche) review sites but those are for technically inclined and user must comprehend many pages techie-word filled reviews. Plus he has to do this on a number of other sites for cross-checking!

Our new venture, Mutvak, is aiming to change this. Concept is "Reviews about verbs not specs!". It's just getting started (so don't beat up much :). We layed down the base level and improving the site every day. It's open now. Comment/Suggestions/Reviews-on-site are appreciated.</comment>


MF Global and the great Wall St re-hypothecation scandal - <AUTHOR> http://newsandinsight.thomsonreuters.com/Securities/Insight/2011/12_-_December/MF_Global_and_the_great_Wall_St_re-hypothecation_scandal/

<comment><AUTHOR> "By way of background, hypothecation is when a borrower pledges collateral to secure a debt. The borrower retains ownership of the collateral but is "hypothetically" controlled by the creditor, who has a right to seize possession if the borrower defaults."

OK, sounds logical

"In the U.S., this legal right takes the form of a lien and in the UK generally in the form of a legal charge. A simple example of a hypothecation is a mortgage, in which a borrower legally owns the home, but the bank holds a right to take possession of the property if the borrower should default."

Right, I'm with you...

"In investment banking, assets deposited with a broker will be hypothecated such that a broker may sell securities if an investor fails to keep up credit payments or if the securities drop in value and the investor fails to respond to a margin call (a request for more capital)."

analogy is holding, makes perfect sense...

"Re-hypothecation occurs when a bank or broker re-uses collateral posted by clients, such as hedge funds, to back the broker's own trades and borrowings. The practice of re-hypothecation runs into the trillions of dollars and is perfectly legal. It is justified by brokers on the basis that it is a capital efficient way of financing their operations much to the chagrin of hedge funds."

WTF. So you can use MY collateral, something I own, as collateral for YOUR leveraged borrowing to make YOUR trade. AND this happens over and over again, building up a tower of debt teetering on a scrap of actual assets underpinning them? And if someone in that chain of leverage above me loses, my money is just gone? And this is the part of Wall St. that is legal?

It makes me sad that we are so afraid of this complex finance bomb strapped to our head that we choose to stand paralyzed in fear and wait, for years, for it to finally and conclusively explode on its own rather than at least attempting to disarm it.</comment>


Safely Creating Temporary Files in Shell Scripts (2005) - <AUTHOR> http://www.linuxsecurity.com/content/view/115462/151/

<comment><USER2> Section 3.5 doesn't seem very safe to me, because I think it allows the user running the script to dictate where the directory will be created via an environment variable.

I don't know what specifically would be gained with that control. Maybe an attacker could specify a TMPDIR that resolves to a path on a FUSE mount and start doing nefarious things with the data in the tmp file?

<comment><USER3> Controlling the location of the temporary directory does not cause a security problem as long as the attacker cannot predict the name of the directory.

Also, regarding FUSE: that's one of many reasons that FUSE mounts by default don't allow other users (including root) to access them.

<comment><USER2> Can I also override $RANDOM to be a static value? PID seems very guessable/brute-forcible.

<comment><USER3> $RANDOM isn't actually in POSIX, and /bin/sh might not implement it at all:

        /tmp$ cat test.sh
        #!/bin/sh
        echo $RANDOM $RANDOM $RANDOM
        /tmp$ ./test.sh

        /tmp$

In a shell that implements it, though, such as bash, you can't override it via the environment. However, it's quite difficult to write privileged shell code if you don't trust the environment, notably $PATH. Too many shell features depend on variables, and shells don't automatically sanitize those.

</comment></comment></comment></comment><comment><USER4> These kinds of articles should not be considered guides, but bug reports instead.</comment>


Putting a Face (Mine) to the Risks Posed by GOP Games on Mueller Investigation - <AUTHOR> https://www.emptywheel.net/2018/07/03/putting-a-face-mine-to-the-risks-posed-by-gop-games-on-mueller-investigation/ <comment><USER2> What risks, sounds like a conspiracy theory.</comment>


Facebook Back of the Envelope Calculation I - <AUTHOR> http://www.gabrielweinberg.com/blog/2008/04/facebook-back-of-the-envelope-calculations.html

<comment><USER2> Did the calculation account for the fact that there are only about 6 minutes of ádvertising every hour? (Off by a factor of 10)

The calculations then would more accurately be:

$0.750M/30sec * 60sec/min * 6 min/hr = $9M/hr

At 30M viewers, that is around $0.30/hr per viewer.

If we put that together we get:

$.30/hr * 33hr/year ~ $10/year per user.

And then with $30M users, we get our answer: $300M/year.

<comment><AUTHOR> On FB the advertising runs all the time, which is why you expand it to the full hour. The brand awareness banner ads can just sit on the side all the time.

<comment><USER3> Isn't that apples to oranges then?

If we used the full time then we'd be comparing a modal form of advertising, the commercial break ad (which takes control of the channel) to a passive concurrent advertising akin to a translucent logo in the corner of a TV show.

I'd wager both those things are worth different quantities.

Now if Facebook used click-through modal advertising, that'd be a different kitten.

<comment><AUTHOR> I agree they aren't clearly equivalent things. But where they come down in value is also unclear. That is, I wouldn't say out of hand they were orders of magnitude different.

One example. Suppose it turns out that if you are exposed to a certain type of ad for 20 min, it really has an effect. (A bigger and possibly more interactive ad than a translucent logo.) You could get that on FB, but it would be harder to get that on the TV.

Also, there are things like people often get up during the TV, talk during TV commercials, etc. And FB ads could be more interesting than the translucent logo because of programming abilities and more screen resolution. I think a more equivalent comparison might be some form of yet-to-come interactive TV. Hey, maybe we'll get that on FB.

</comment></comment></comment></comment><comment><AUTHOR> FYI (as promised in the post), the second back of the envelope calculation thread is here: <http://news.ycombinator.com/item?id=161810>

</comment><comment><USER4> If I wanted to advertise something online, there's no way in hell I'll pay for views. I'd only pay if someone clicked through to my site/service.

<comment><AUTHOR> Understood. Me too. But we're not Ford, or <insert huge consumer company here>. Those companies are often paying for brand awareness on TV. They might be satisfied with (and might actually have the goal of) trying to get the average FB college student to buy a Ford five years from now when they buy their first car. And in that case, they don't really care about clicks now.

</comment></comment><comment><USER5> American Idol mainstream tv advertising != Facebook

<comment><AUTHOR> Why not?</comment></comment>


Neural Network on a Commodore 64 (1987) - <AUTHOR> http://www.fourmilab.ch/documents/commodore/BrainSim/ <comment><USER3> COMPUTE!'s Gazette published a three part series on an assembly language neural network in 1990 for the C64, which is infinitely faster than this, but much more opaque. The article was pretty thorough as I recall, though.

<comment> cbm-vic-20 Part 1: [https://archive.org/details/1990-01-computegazette/page/n24](https://archive.org/details/1990-01-computegazette/page/n24)

Part 2: [https://archive.org/details/1990-02-computegazette/page/n35](https://archive.org/details/1990-02-computegazette/page/n35)

Part 3: [https://archive.org/details/1990-03-computegazette/page/n43](https://archive.org/details/1990-03-computegazette/page/n43)

</comment></comment><comment><USER4> John Walker said (in 1987):

> _If you walk up to a computer and ask it "what is the name of the famous > bridge in the same state as Disneyland" you won 't have much success, but > most people will immediately answer, "The Golden Gate Bridge"._

I prompted GPT-2 on talktotransformer.com with that question. The first two times it gave me nothing coherent (a made-up URL about Minnesota, and something about Georgetown), but the third time, it said:

 _What is the name of the famous bridge in the same state as Disneyland?

This is a double fact: it is a California Heritage Bridge, a nickname invented by the California Turnpike Authority and Santa Clara County Transportation Authority (whose name is, coincidentally, the original name of the Carson City Parking Authority).

How did the first hippie, Kesey, travel across the Golden Gate Bridge?

In Kesey's famous classic "One Flew Over the Cuckoo's Nest" he ruminates the great flight across a river, and then some._

This is almost entirely false — there is, for example, no such thing as a "California Heritage Bridge", and I can almost guarantee you that the Carson City Parking Authority, if it exists, was never called the "Santa Clara County Transportation Authority". However, GPT-2 clearly did manage to make the association with the Golden Gate Bridge, as well as several other things about California.

My attempts to rephrase the question in a more GPT-2-friendly way, such as "There is a famous bridge in the same state as Disneyland, named", were not successful, although they did confabulate an entertainingly large variety of bridge names.

<comment><USER5> I tried a similar experiment on GPT-2 a few days ago, giving prompts like "if I drop a stone, it will" or "wood floats in water while a stone". Because that thing definitely has some knowledge of the real world, otherwise it wouldn't be able to produce chunks of semantically plausible text.

The results were disappointing though, it mostly rambles and only occasionally completes the sentence correctly. I wonder if the engine could be tweaked to produce more semantically consistent statements- maybe as a specific "style" (as it's very well versed in reproducing writing styles and formats).

<comment><USER4> Yeah, it seems like the question format led it to imitate the "style" Q&A web pages which are mostly infotainment, but mostly don't bother to mention facts that are so well known as the existence of the Golden Gate Bridge. Imitating IRC "style" produces people ignoring the question:

> _< bob> wut is the name of the famous bridge n the same state as disneyland

> <DocDrew> small

> <DeathTrip> lmao, you "drew" this up

> <DeathTrip> 'sup DocDrew

> <drewk> Wasn't James Cameron the guy to make the first ever 3D movie?

> <drewk> :p

> <drewk> Also the guy who claimed to invent digital video in the first > place._

While adding timestamps and a space for @ leads it to imitate specifically #bitcoin:

> _19:33 < bob> wut is the name of the famous bridge n the same state as > disneyland if you wanna know 17:19:37 <nalixor> this is actually actually > helpful. 17:19:47 <nalixor> what?! 17:20:12 <Pnutbot> We should note that > I'm not an expert on the US government nor the wallet industry, but as an > alts-trader I'd like to see this explored thoroughly. 17:20:21 <Pnutbot> > there might be people with other knowledge like_

Alternatively:

> _19:33 < bob> wut is the name of the famous bridge n the same state as > disneyland?

> 19:34 < warren> Old Alaska?

> 19:34 < warren> or Nome?

> 19:35 < warren> I'm not familiar with that town

> 19:36 < warren> > [http://en.wikipedia.org/wiki/Alaska_state_homepage#Social_ex...](http://en.wikipedia.org/wiki/Alaska_state_homepage#Social_exercise)

> 19:36 < warren> sometimes is chosen by the change the spelling of homeport_

Imitating the "style" of a play results in a back-and-forth dialogue, but an unhelpful, dramatic one:

> _John: What is the name of the famous bridge in the same state as > Disneyland?

> Johnathan: Uh, no. No, that's not what this is.

> John: Okay.

> Jonathan: That is not a bridge. What is this? A super bridge?

> John: Uh, yeah, it's a bridge.

> Jonathan: And now we got them in our fire truck… the bridge.

> John: With their fire trucks.

> Jonathan: And we got them in our fire truck, and we got the roof lifted up_

Imitating the style of a screenplay results in another dramatic but unhelpful conversation about bridges and murder:

> _JIM looks thoughtful.

> JIM

> (finally)

> What is the name of the famous bridge in the same state as Disneyland?

> TRACY

> No biggie. Like the bridge for Opus--

> INT. ANDY'S CAR - <USER2>

> JIM and TRACY arrive at a quiet house.

> TRACY (cont'd)

> ... it's this house in a country where you won't get pulled over.

> JIM

> Or shot.

> TRACY

> And where you are a reasonably happy_

Formatting it explicitly as a Q&A leads to especially unhelpful results:

> _Q: What is the name of the famous bridge in the same state as Disneyland?

> A: ???????

> Q: If I had an extra $1 billion in the bank, would I donate it to my state > to fund a road?

> A: ???????

> Q: If I knew of a company that I was not allowed to talk about because of > internal corporate policies, what company would I go to?

> A: ???????

> Q: What do most big brands have in common?

> A: ???????_

Imitating a numbered Q&A format is only slightly more effective:

> _5\. What is the name of the famous bridge in the same state as Disneyland?

> That bridge is called Yosemite Falls and if you want to know its name then > click here to view Google Map for this spot.

> 6\. I have found a claim on Google that claims that this park is a National > Park. Is this true?

> No, it is not true as this park is listed as a County Park. Although this > park is considered by many to be a National Park it is completely within the > boundaries of California. The park has plenty of hiking trails that could > actually qualify it_

Using the beginning of the Wikipedia article about Disneyland, plus a slight prompt, was effective:

> _Disneyland Park, originally Disneyland, is the first of two theme parks > built at the Disneyland Resort in the same state as various famous bridges, > such as_

After a few tries, GPT-2 completed this with:

> _the Golden Gate Bridge, and the San Francisco-Oakland Bay Bridge. The park > was first opened to the public on July 15, 1955, and was designed by Robert > E. Iger. In 2005, an expansion expansion was completed, adding thirteen new > roller coasters and 13 new_

Even still, it often generates human-sounding nonsense:

> _the Hollywood Bowl and Golden Ledge. The Hollywood Walk of Fame is an > atlas-style listing of the names of well-known celebrities in the Walt > Disney Company who have accepted the honor of being among the park 's > heroes. The current structure was built in 1939-1940 and_

And of course even when it gets it right it gets it wrong:

> _the Golden Gate Bridge and the San Francisco, USA bridges.

> Worlds Fair of America and World's Fair of Texas [ edit ]

> In 1969, Disney established the World's Fair of America, a giant mechanical > thing and show meant to feature large scale attractions like a Big_

</comment></comment></comment><comment><USER6> A thread from 2017: [https://news.ycombinator.com/item?id=15882683](https://news.ycombinator.com/item?id=15882683)

</comment><comment><USER7> Wow, a blast from the past. I ported this program to 6502 assembly and added more features, and used it for a school project.

Then I read all of the articles on neural networks claiming they were a dead end and went off to other things :)

</comment><comment><USER8> I love historic pieces like this and it's wonderful to see these early experiments.

It's really easy to get this to run! Download VICE Disc Image of this Program, unzip it (to get the .d64 file), then go here: [https://virtualconsoles.com/online- emulators/c64/](https://virtualconsoles.com/online-emulators/c64/) and drag in the .d64 file to see it run.

Another note, for those not familiar with the brilliant author: "This site is developed and maintained by John Walker, founder of Autodesk, Inc. and co- author of AutoCAD. "

</comment><comment><USER9> Has anyone rewritten this in something modern? Probably less than 100 lines of Python, for example. Can skip load/save, .... I think he uses the C64 ROMs to get the bitmaps. All those pokes around 1024 are writes to the screen RAM.

        # READ Bitmap for selected character from C64 ROM
        310 k=asc(a$)
        320 if a$>="0" and a$<="9" then k=k+64:goto340 # process numbers 0..9
        330 if a$ < "a" or a$ > "z" then 500 # Maybe a function key
        340 gosub 970:print "fetch ";a$
        350 l%=0
        360 k=(k-64)*8+53248
        370 poke56333,127:poke 1,peek(1)and251
        380 fori=0to6:poke49408+i,peek(k+i):next # Copy character's image from character ROM (53248) to RAM
        390 poke 1,peek(1) or 4:poke 56333,129
        #
        # Look up bits that make character 6x7 = 42 values
        # Lighted dots are stored as 1 and background dots as −1
        400 for i = 0 to 6
        410    j% = peek(49408+i)/2 # byte value - divide by 2 is shift right.  Removes first bit
        420    for k=1 to 6 # 6 wide
        430      l%=l%+1 # counter 1..42
        440      f1%(l%) = -1 + (2 * (j% and 1)) # 2 * (1 or 0) => field[counter] = 1 or -1
        450      j%=j%/2 # Shifting right again to get the next bit in first position for the AND operator. xxxx xxx1
        460    next k
        470 next i

        # Function keys
        510 if j%=1 then gosub 1000:goto 280 # train()
        520 if j%=5 then gosub 1080:goto 90  # print_matrix()
        530 if j%=2 then gosub 1210:goto 280 # randomize_ten_percent()
        540 if j%=6 then gosub 1680:goto 280 # clear_memory()
        550 if j%=3 then gosub 1290:goto 280 # recall_pattern()
        560 if j%=7 then print chr$(147);:close15:end
        570 if j%=4 then gosub 1800:goto 90  # save_to_disk()
        580 if j%=8 then gosub 1990:goto 90  # restore_from_disk()

     1000 rem train on pattern in f1% def train()
     1010 gosub 970:print "training"
     1020 for i = 1 to 42
     1030   for j = 1 to 42
     1040     m%(i,j)=m%(i,j)+f1%(i)*f1%(j) # matrix[i][j] = matrix[i][j] + field1[i] * field1[j]
     1050   next j
     1060 next i
     1070 return

     1210 rem randomise 10 percent of f1% def randomize_ten_percent()
     1220 gosub 970:print "random"
     1230 for i=1 to 42
     1240   if rnd(0) > 0.1 then 1260 # Skip > 10%
     1250   f1%(i)=-f1%(i) # negate
     1260 next i
     1270 gosub 750 # update field f2 on screen
     1280 return

<comment><USER10> The "poke56333,127" is disabling the background keyboard reading IRQ by disabling the "IRQ on timer out" function of the CIA 1 used to trigger it.

This is needed because the "poke 1" that follows maps in the 4K character ROM over the I/O devices at D000-DFFF; if you don't do this the system would freeze.

</comment></comment><comment><USER11> I got my Master's Degree in CS in 1988. For one project, I did a Neural Network on an IBM-PC, in Turbo Pascal, which is barely a 16-bit computer, back in this year. We were training it for various logic functions, and very simple "simulated retina" problems with patterns on 16x16 grids.

<comment><USER4> _Barely_ a 16-bit computer? The IBM PC's CPU could address a mebibyte of RAM — that's 20 bits! In a single process! You could actually put 640 KiB of RAM in it, I'm pretty sure. A computer that was _barely_ 16 bits would at most have a 16-bit address space, maybe less, though I don't know of any that took that option.

<comment><USER11> The 8088 had an 8-bit data bus, 16-bit registers, with a segmented scheme that would allow 20-bit memory addressing.

The 8086 had a 16-bit data bus. See [https://en.wikipedia.org/wiki/Intel_8088](https://en.wikipedia.org/wiki/Intel_8088)

Usually the "bitness" of the computer is the width of the general registers. Most 8-bit computers had a 16-bit address counter (for 64K of memory), with 8-bit general regisgters.

<comment><USER4> Yes, all of that is correct, although I think you have conflated "address bus" with "program counter".</comment></comment></comment></comment>


Ask HN: How much JavaScript do you know as a back end dev? - <AUTHOR> Does it make any sense being a real full-stack engineer? Client-side JS is getting more and more complex with all that AngularJS/React etc stuff, it really pushes the limits of the one-man show approach for web development. How many JS do you know as a web/backend developer? <comment><USER2> Can you debug JS easily? Is it worth the time to play around with JS? Is JS even a programming language? Can you get earn more respect (moola) by learning JS?

The answer is NO! JS is a dead end. JS is the shit of the shit. Sooner or later people will realize that JS is just an abomination, something that shouldn't even exist in this world.

<comment><USER3> @jozi9 sure! Not all projects will be complex in a way that you can't handle both sides.

@omegaEpsilon I with I could downvote you.

Best regards.

<comment><USER4> JS has some kludges. They aren't disappearing in ES6. They might be marked for deprecation in ES7. They might be gone if Javascript makes it to JS8.

Most of the really truly shitty parts of js development are caused by the lack of cross-browser standards.

</comment></comment></comment><comment><USER5> As a real full-stack engineer, I see more job postings for front-end than full-stack. And most of the full stack postings I see are for Ruby, which I don't have a lot of experience with, and Java, which I'd rather not do.

And JavaScript, of course. Usually these are titled "JavaScript Developer" but they really mean "CoffeeScript Developer" and no thanks.

All of the opinionating is really to say it only makes sense if it's what you want to do. I happen to like programming (including JavaScript) so I do back and front end. If you don't like JavaScript don't do front end because it can and will get complex, and JavaScript doesn't help you manage complexity.

That said, if your plan is to work on web applications, the more JavaScript you know, the more valuable you'll be (in theory) to your employer/client.

tl;dr maybe

</comment><comment><USER6> Add snazz in layers...Angular or React or whatever gets a lot of air time, but I'd say most day-to-day web development doesn't use it yet.

At the very least, learn some basic VanillaJS, jQuery, and lo-dash. You can get fancier later.

<comment><AUTHOR> Yeah, to be honest, clientside could easily get more complex than the backend in some cases.. happened a lot of time to me in Django with Angular.

</comment></comment><comment><USER7> Check out Firebase, its a ready to use backend that targets making backend development easier.

</comment><comment><USER8> You should look at node, its back end javascript and its popularity is booming.

<comment><USER4> Legit question, no snark intended:

How well does node scale? It's running in one thread, and from my use (a very small amount of experimentation and reading), it doesn't look like it could handle more than a few hundred concurrent users without stringing together some more robust queuing outside of the node code.

<comment><USER9> Node.js scales horizontally just as well as Ruby and Python (if not better).

Some of the services I've built in Node.js handle 1000 req/s fine without the need for multiple instances or threads.

</comment></comment></comment><comment><USER10> As a backend dev I must state: "fuck javascript"

<comment><USER4> I used to say the same thing. I had the opportunity to work with some decently talented frontend developers and a tech lead with a strong preference for engineering over creative development.

I spend a lot more time improving my javascript skills now.</comment></comment>