Javascript is a buffet, not the enemy [video]
scriptconf.org
scriptconf.org
The slides channel an uplifting attitude; it's okay to try tools and solutions you end up not liking in the end; it's okay to experiment; we're all in this together, and the like. One thing that stood out is the inevitable reference to how JS is a multi-implementation environment and monoculture is bad, but sadly this is much less true now than it was five years ago.
Like it or not, this multi-implementation environment has coalesced (for various, sometimes bitingly valid reasons) around a very limited number of implementations, and that's just at the runtime layer; in the wider sense of environments that expose a JS engine and some APIs like Browsers or server-side runtimes, there's also not much choice left.
To play on the buffet metaphor, a bewilderingly diverse selection of frameworks, tooling, and quickly-spoiling userland shenanigans exist at the topmost layer, which is fantastic for user choice, but the Web APIs underneath are growing every year, surfacing previously nonexistent functionality in the browser that every website must then decide to ignore or implement. All the while, the language itself has exited the awkward 10-year stalemate, and is receiving yearly revisions with major features.
The meme that JS is an awful language needs to subside; the truth is JS is a now-mature language that is used in a rapidly evolving platform, whose APIs are hardly a bastion of stability. These days, that platform is largely driven by the whims of a single vendor, with dominant marketshare on the client, and a significant presence on the other end.
(edit: before it comes up, I'm aware JS is used in various, very different environments e.g. the GNOME desktop environment -- some of these criticisms don't apply to those, but then again, neither do most of the tooling and libraries. JS in terms of this talk does seem to mean 'The Browser', and not even Node)
[1] https://www.slideshare.net/slideshow/embed_code/key/ILjHOTLR...
We can be dismissive about "memes", but sometimes groupthink is also a thing people think in a group, because it's justified by common experience. JS has been developed and provided for out of extreme necessity, and I don't think it's fair to try and prop it up using the infrastructure that arose out of that necessity - in some sense, it is the ecosystem around a sewer pipe: important, but nothing worth building a national park over.
The day we stop asking "why aren't you using something other than Javascript?" is the day we collectively take a step back in terms of design thinking.
Considering that the language made huge strides forward with ES2015, ES2016, and ES2017, what does that mean?
> The day we stop asking "why aren't you using something other than Javascript?" is the day we collectively take a step back in terms of design thinking.
Spirited debates about JS vs. OCaml are implementation thinking.
Except at the end of the day, you're not actually using those languages to do anything besides generating javascript. So you're still using javascript, which means it remains just as essential as it ever was.
You could just as well write the javascript being "compiled to" after learning whatever idioms make it "safe" versus vanilla js, and cut out the middleman. Javascript-as-bytecode is an antipattern.
>How you would have an HM type systems?
Let me ask you this - how do languages which compile to javascript manage to implement these features in javascript?
The answer is they don't. The javascript they generate may behave as if it were safe, but it's no more safe than any other javascript anywhere else, and no different.
Which means that it could just as well have been written that way to begin with because what's being enforced by the stricter language is idiom and style, not anything inherent to javascript itself.
>How you would not kill yourself in a simple app less than 100k LOC working alone?
I don't see how this is relevant to my point, and I don't think 100 KLOC apps represent the common use case for compile-to-js languages. I never argued that compiling to javascript wasn't useful in some way, only that it's still an abstract way to write plain old every day javascript. It's simply incorrect that compile to js language have rendered javascript less relevant because they compile to javascript.
>"And just to show how absurd is your way of thinking I can just say the following: "Except at the end of the day, you're not actually using those languages to do anything besides generating machine code Except at the end of the day, you're not actually using those languages to do anything besides generating machine code (...)
Well, no, and obviously not.
Because javascript isn't machine code. It's not bytecode. It's not assembly. It's a high level, loosely typed programming language.
However, if we were to accept your facile equivalence as true for the sake of argument, that javascript is no different than machine language, and that, therefore, compiling to javascript is no different than compiling to machine language, then it must also follow that writing javascript by hand is no different than compiling to machine language, and further that translating from any high level language to any other is the same as compiling to machine language.
If I were to transpile from any high-level language a to any other high level language b, would it make sense to then declare b equivalent to machine code? Of course not. If you took javascript and translated it to Python, is Python then equivalent to machine language? Of course not.
It's the model of treating javascript as a compile target that's absurd.
If you're going to try to construct a strawman out of my reasoning and knock it down, at least try a sturdier one.
At the end everything you write on a machine is translated to machine code and executed. Or do you really believe that the CPU executes directly JavaScript? Powerful type systems, HM inferences and all the other abstractions obviously don't exist at machine code level. It's the resulting machine code that behave producing the behaviour of these abstractions. Borrowing again your words: Which means that it could just as well have been written that way to begin with because what's being enforced by the stricter language is idiom and style, not anything inherent to machine code itself.
I would say that it is obvious that you can write them directly in machine code and have the same effects. Now how many people in the world do you think that believe it is a sane approach to manually write a complex application that uses powerful type systems directly in machine code? I don't think you can find anyone outside a mental institution.
Merely replacing "javascript" with "machine code" and pasting my comment back doesn't constitute a rational argument or an effective refutation of anything i've actually stated, it's the intellectual equivalent of a small bird mimicking human speech.
>Now how many people in the world do you think that believe it is a sane approach to manually write a complex application that uses powerful type systems directly in machine code?
Except... writing machine code does not describe writing javascript in any meaningful way. Machine code is low level, concrete, and not easily human readable. Javascript is high level and abstract.
How sane is it to manually write a complex application that uses powerful type systems directly in machine code using C++? Why would you bother writing Java bytecode directly in Java source code? The metaphor of javascript as machine language breaks down so readily that, yes, I will question its utility, and whether fixating on it is pathological.
If you don't like javascript as a language, fair enough - plenty of people don't, for valid reasons. I understand perfectly well why developers generate javascript from other languages and why they might find it useful to do so. But to hearken back to my original point, doing so doesn't affect javascript's relevance or discredit its quality as a language. You're still developing in javascript by proxy.
The problem isn't that JavaScript is a bad language (that's purely subjective), it's that it has a terrible ecosystem and a community that, apparently, is willing to accept very low standards in library and package management.
But I more meant the ecosystem in general:
A "batteries included" language makes me create my own UTC tzinfo implementation so I can get a datetime in UTC... Python's time situation is maddening and by far the worst I've worked with. I'm sure others feel this way because there are a bakers dozen of time libraries trying to fill the gaps.
I almost rage quit the industry trying to save and retrieve a UTC datetime from the database with sqlalchemy. Luckily I found Arrow and ArrowType and that's been working well enough for now.
On the subject of time this has been open for close to five years? https://bugs.python.org/issue15873 . I get the impression that lots of proposed improvements are languishing like this.
sqlalchemy and alembic feel like JUST ONE GUY is working on them. Massive achievement, but the gaps are visible.
The module system feels stale; a holdout of a system from different workflow times. Splitting stuff off into separate files for maintainability(including improving multi-dev workflows trying to reduce conflicts) creates some gross imports.
It feels like there is a reluctance to evolve the language itself; a lot of enhancements appear to be made via more magic metaprogramming and function usage. super(Cls, self).__init__() comes off as an artifact of this. Not really my cup of tea these days, but I can see how this is very subjective.
The propper way to handle generated members with pylint is supposedly a plugin; which almost no projects provide.
Type annotations are supposed to go a long way in 3.x, but the prevalence of metaprogramming and lack of tooling awareness has probably defeated more jedi than Darth Vader.
boto3 has no official async support even though lambda just released support for Python 3.6. Meanwhile the javascript sdk is shipping with TypeScript definitions and a new promise interface.
A lot of this is very subjective(other than perhaps the languishing of certain library areas) of course. To me though, after having worked with a lot of other languages, it just feels like Python is a bit of a ghetto these days. It's like the language world has built north and Python is.. Not living to the north.
EDIT: The pipenv announcement thread has some comments that go into more detail on package/project management situation: https://news.ycombinator.com/item?id=13459740 . sjellis and sametmax touch on most of the stuff I've run into.
So, I learned Angular 1 for a project. Some concept there really are everywhere (promises, DI), but you might as well not even call Anuglar 2 Angular. It is totally different and even getting started in it took so much effort I gave up. I have almost never done that as a hacker. But the sheer amount of stuff to install and learn just to implement Hello World was more than I was willing to deal with at the time.
But after all that, I can see why some people would be frustrated.
Being on the inside and doing js for the past 3 years it's more exciting than looking in. We keep getting new awesome language additions as of late!
Web dev has a fast cycle time, mainly (imo) because products are created and used and discarded quickly - lots of websites are short-lived one offs. So, naturally, there's churn.
And as to what my sibling commenter said, I agree. I'm starting to move from angular 1 to 2, and 2 is better. It has some downright amazing features, and the tooling is quite excellent. That's why, personally, I'm learning the new thing.
Angular 4, you mean (or just "Angular").
We need some sort of js beginner walk through that has a section for each step in the process and explains the solutions and differences between projects.
ex: step 1 is language fundamentals, step 2 dom manipulation step 3 bundlers and why you need them. Step 4 frameworks and libraries to build your frontend. Something like this would be useful but I don't know if anyone is building something like this for beginners :/
Of course - it also helps I understand that tech stack enough to efficiently explain it to younger engineers. That said - these three technologies have a LOT of material on the web and consensus on that tech has helped my folks build things "more right" more often, without having to do all the nuanced consideration themselves.
When it comes to X resources, Y time, and Z goals, it's all about the right tool.
I think many people give JS shit because it isn't always the right tool - but people choose it anyway due to hotness/hype/vague advantages.
So I'd agree its a mix of skill, resources, and goal. Arguably another manager with amazing React skillsets could do the same thing with a different stack. I'd love to see that guy in action, especially if he can have a more productive team for the choices.
But for us - most UI Frontends are fancy buttons on backend service APIS, or stupid CRUD. Rails does this with confidence.
In terms of what? Can you please do a npm vs pip and a nvm vs virtualenv?
Thanks
I've had the complete opposite experience. Crates, composer, and npm are my go-to examples of good package mangers. Python is my go-to example for lack of a good package manager.
I must be getting old and grumpy, but I really am tired of learning 'new' frameworks and ideas unless they actually provide some sort of benefit.
For example, I started using Docker here and there. There's a bit of a learning curve and I initially thought 'how is this all that much different than running a VM or two?' Only later, when a single docker compose file set me up with a full CMS, DB, NGINX, etc. stack did I understand just how cool it was.
To compare, I've spent a few years now on various projects where the front-end guys have added all sorts of bloat - bower, then grunt, gulp, Angular, React, Browserify, JSPM, onto Webpack. Hell, it looks like npm is now being replaced by Yarn - WTF?
And the vast majority of this crap is absolutely no better for the user than the old school MVC server side template apps+JQuery that worked for years.
Recurring amnesia.
It's because the industry (number of programmers) is grower faster than the rate of diffusion of knowledge (experience).
Also, easier communication mediums has greatly increased the noise to signal ratio. So maintaining our BS filters requires that much more effort.
Two follow-ups if you don't mind: (1) "terrible" in what kinds of ways, and (2) compared to what, specifically? (Genuinely curious.)
Compare to maven in java. Yes, you need to write XML, but it is not that hard, you mostly add <dependency>. And then it just works.
And with npm, I get - this doesn't work with that version of npm (which BTW has a funny versioning that is almost exponential, there are 0.x and x.x versions), but it doesn't say that the version is wrong, it just does not work and you are to figure out why.
More over, npm package locations, you can have three places, in project directory, in home directory and system wide. And to make matters worse you switch between those by using a command line switch. And it breaks, because once you downloaded a package into home dir (accident) and then your packages in current dir don't work, just because - build breaks and you are out of luck. I don't even count how many times I had to remove all npm directories to get rid of some package that was downloaded.
With maven you have simple system, that is constraint and because of that you have much fewer places where it will shoot you in the foot.
With npm (+gulp) you get wild west of package management, just like it was with ant days of java.
And don't get me started on the AngularJS - I thought that I won't see anything that complicated since the days of EJB < 3.
I don't disagree with you though; just saying.
[0]https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
My experience has been the complete opposite. Angular has been best for simple, straightforward apps. The larger the app got, the more convoluted the code grew, and the more I found myself fighting with the "angular way".
Maybe 2.0+ is different. I wouldn't know, and have no interest in finding out.
And that is ok. Until WebAssembly matures, then those compilers will all just add it as a compiler backend.
Color choices are the last of my worries, and we see that this is also greatly neglected in modern desktop apps (e.g.: Spotify and Chrome taking over the window title bar on most OSes).
If it weren't for this triumvirate of evil, as a user I wouldn't have a problem with Javascript at all.
Bottom line: I just don't want to have to worry about this shit, so try to avoid Javascript like the plague.
[1] - https://news.ycombinator.com/item?id=13831906
[2] - https://news.ycombinator.com/item?id=13649178
2 - this is a hardware vulnerability that you could take advantage of in multiple languages.
3 - this is a Tor + windows exploit that just happens to use JS.
4 - this is a Firefox vulnerability, not a JS vulnerability
There is nothing inherently wrong with JS from a security perspective and in many ways it is a much more secure system than most, since it is constantly exposed to the internet.
But like any large ecosystem with multiple implementations and lots of inexperienced devs, there will be vulnerabilities out there.
I do respect your decision to turn of JS, but I don't agree that JS is somehow special in how insecure it is. You should also avoid running any apps written in any language at all with that logic. I'd posit that JavaScript apps are more secure than c++ apps, since the runtime itself is hardened.
2 - See 1 above.
3 - See 1 above.
4 - It's a vulnerability in a part of Firefox that's written in Javascript.
"I don't agree that JS is somehow special in how insecure it is"
I never claimed that JS was any more insecure than any other language (though fans of "safe" languages and ones whose programs and compilers can be proven correct might in fact make that argument).
Javascript has the special distinction of being the only programming language in the web browser (if you exclude HTML). If it wasn't, then the argument of whether JS was or was more insecure than the other language(s) in the web browser would relevant. But that's not the case.
"I'd posit that JavaScript apps are more secure than c++ apps"
Completely irrelevant since I don't have the choice to run C++ in my web browser.
I encourage folks to try it even for a little while, because it's shocking how much more quickly many sites will load and how much more responsive they are to things like scrolling or text searches. News articles and arbitrary google-results especially.
Even worse, the difference seems to be getting worse and worse. It's a pretty regular experience for me these days to end up on a website that barely works on iOS: ridiculously slow, stuttering scroll behavior, inability to scroll because there's an ad in the way, inability to close popups, fixed position elements taking at least a third of the screen, and so on. You know the drill.
There's one website that, if I don't use the 'add to instapaper' button within the first few seconds of loading, completely blocks safari.
Now I can understand how a website becomes bloated and shitty while still being somewhat usable; users either might put up with it, or it might be difficult to measure the negative impact of these 'thousand cuts'.
But it baffles me how websites can exist that don't work at all on mobile/iOS when it's relatively easy to fix (enough to make it shitty usable). Does nobody look at bounce rates?
They do so because of the economics of the web. No-one pays for content, but basic advertising is low revenue. So user experience is squeezed instead, with video ads and popups.
There are other factors too, of course. Businesses have strange priorities and can be quite myopic when they compare the value of a new feature with the value of leaving the site uncluttered. But the main reason scripting is slow is advertising.
i) the people who push features don't actually use them;
ii) people overestimate the pain users will go through to reach their services;
iii) in a lot of businesses it's actually really _hard_ to advocate doing nothing - no new features, no further investment, no changes. So something is done because something seems better than nothing, and thuse the product slowly accumulates cruft.
So how do you pay for your content, if not for ads?
Do you expect people to give it to you for free? Do you do work for free?
But contrary to your thinking, I see these consistent regular events as a deeply worrying symptom that somehow as an industry we have managed to wind back progress over the past decade and end up using a pile of sucky stuff.
there certainly is room in the world for recognising the flaws in javascript or git and working to fix them, or building something better. but just whining about how bad it is achieves nothing and it is irritating to read.