10 ms·
Javascript is a buffet, not the enemy [video]
- Safety1stClyde 9y agoJavaScript is a huge turd, the scourge of the internet.
- jasonkostempski 9y agoJavaScript is fine as a language. However, if it had never been allowed to run without user consent, it wouldn't be such a scourge as there would be minimal ads, minimal cross-site tracking and most sites wouldn't be able to justify a user prompt just to enable a useless animation.
- Safety1stClyde 9y agoThe top post on hacker news today is about "The Boring Company" and literally nothing on this page functions without enabling the JavaTurds.
- Pharylon 9y agoJavaScript is a deeply flawed language. It has both undefined and null. You almost never use the == operator... except as a workaround to easily check if something is either null or undefined. That being said, modern JavaScript is actually pretty nice, once you know where the pitfalls are. But if JavaScript wasn't allowed to run by default, it would have never reached it's current level. It'd still be a deeply flawed toy scripting language.
- jasonkostempski 9y ago"But if JavaScript wasn't allowed to run by default, it would have never reached it's current level." I was thinking about that too but I'm not sure it's true. There are some real universally useful applications (e.g. maps; office suites; email; heck, even social media) that require some code to function and I think just about everyone would have been OK with having to grant permissions one time to use them. And all the companies currently making those types of applications helped make JS what it is. Although the most prominent one is the one that has made all it's money on ads and tracking so maybe that's not such a good argument. Anyway, now that we have JS in its current state, maybe we could think about starting to prompt by default, starting with JS from external domains :) (I know, fat chance).
- jack9 9y agoI think you aren't quite understanding the point. It's not that some language wouldn't have dominated (in the interest of interoperability and functionality needs), but that it probably would have been a product by MS or some other homebrew language. Javascript being codified with the hackneyed ecmascript standard, was the death nell for efficiency in web apps for the last few decades. Without the standard, we probably would have seen a shift to other technologies (some of which would have failed like Silverlight) on emerging browsers, in hindsight.
- virmundi 9y agoI agree with you fully. I even started to write a book on it [1]. Unfortunately there is nothing else. When I was a young man, I had IE as the primary target. I could chose between screwy looking Javascript that wasn't fully supported across the fledgling NS/IE browsers, or VBScript, which wasn't supported at all on NS, but did just fine on IE. Since IE was huge, I learned VBScript because it took my BASIC skills, which were basic, to the next level. VBScript quickly fell away even though I was able to do neat demos that were cutting edge such as adding fog lamps to a car to get a quote when buying a new car (or changing the color). It fell because MS didn't make VBScript available as a common standard so Mozilla didn't implement it. By the time Chrome came along, it was a dead language like Phoenician. All that said to bring home the point: there is nothing else. Shit is shit, but at least like shit you can generate energy with JS. You can make the page move. You can seamlessly update sections with new data. It is the only thing than brings a spirit to a page. This is what either the users or the developers want (within reason, which is different for both of those markets). Even with WebAssembly we will probably stay on JS for years to come. Each browser has to implement support for a new language as well as stay standardize compliant with JS. I doubt will see multiple languages equally supported. It's a huge turd. It's a huge turd that gets things done. It's essentially both the ball and the beetle. Simply screaming into the void won't help anything [2]. 1 - https://github.com/virmundi/JSIsGarbage https://github.com/virmundi/JSIsGarbage 2 - http://screamintothevoid.com http://screamintothevoid.com
- sctb 9y agoPlease post civilly and substantively on Hacker News: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- sidlls 9y agoWhen I look at what the front-end developers at the company I work for have had to go through with respect to package and dependency management to get an Angular application going, I cringe. 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.
- monkmartinez 9y agoYes and I would add that the ecosystem practically begs devs to do this. The language lends itself nicely to these ends as well. I wish there were more options for the web...
- Rapzid 9y agoI have similar feelings about Python.
- cshenton 9y agoWhat problems do you run into? I've had good luck with a pretty vanilla virtualenv + requirements.txt files, and docker for packaging (great for c libs that my python packages call down to).
- Rapzid 9y agoI've worked through most of my packaging and pyenv/virtualenv issues but I must say I found it much more convoluted and painful than any other language I've worked with in the past 6 years. The need for all the virtualenv's makes me sad, and I'm not a huge fan of the shim system. Working on multiple projects that need different versions of a dependency, particularly when your also working on that dependency, can be a pain still. This is very subjective but pipenv was just released THIS YEAR and has over 3k stars on github; clearly there is some general angst out there. 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 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 https://news.ycombinator.com/item?id=13459740 . sjellis and sametmax touch on most of the stuff I've run into.
- cies 9y agoJS is compilation target for most modern x-platform UIs. Every big JS project is compiling some how: ES6/7/etc, TypeScript, Flow (ok, not exactly compiling), CoffeeScript, Elm, PureScript, Reason, GHCJS, ClojureScript, JSX, etc. etc. And that is ok. Until WebAssembly matures, then those compilers will all just add it as a compiler backend.
- rs86 9y agoThat will be interesting to watch
- Sanddancer 9y agoTo the detriment of the end desktop. You end up with an angry fruit salad that completely ignores the user's color, font, size, etc choices, and tends to have accessibility problems as well. Cross-platform javascript is just plain bad.
- cies 9y agoI'd say that at some point the accessibility options are better for website and webapps then for traditional desktop apps. 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).
- Sanddancer 9y agoThere are reasons I try to avoid such "modern" desktop apps. Those choices make them much less usable and much less discoverable. Native widgets aren't some plague, they allow consistency and ease of use.
- pmoriarty 9y agoThe thing I hate most about Javascript is that if I allow it in my browser, I expose myself to Javascript vulnerabilities. The other things I hate are ads delivered by Javascript and tracking enabled by Javascript. If it weren't for this triumvirate of evil, as a user I wouldn't have a problem with Javascript at all.
- colordrops 9y agoWhat types of JS vulnerabilities are you encountering?
- pmoriarty 9y agoSome examples: [1], [2], [3], [4] 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 https://news.ycombinator.com/item?id=13831906 [2] - https://news.ycombinator.com/item?id=13649178 https://news.ycombinator.com/item?id=13649178 [3] - https://news.ycombinator.com/item?id=13066825 https://news.ycombinator.com/item?id=13066825 [4] - https://news.ycombinator.com/item?id=10021376 https://news.ycombinator.com/item?id=10021376
- colordrops 9y ago1 - those are libraries with vulnerabilities, not JS itself. I.e. could be any language. 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.
- rs86 9y agoPuxa saco do krlho
- niftich 9y agoI haven't watched the 55-minute talk yet, but the 82 slides can be clicked through (ironically, the embed in the article didn't work for me on /any/ browser, but here's a direct link: [1]). 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/ILjHOTLRvArC2q https://www.slideshare.net/slideshow/embed_code/key/ILjHOTLR...
- ivanbakel 9y agoI take issue with the last point: JS has matured like bread, not cheese. No matter the age or ingrained status of a language, we have to be able to admit its flaws, rather than go on with some learned helplessness over the whole ordeal. 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.
- jstewartmobile 9y agoWhen the author of the best book on JavaScript programming says we need to "think of the children" and come up with something better, we probably need to come up with something better.
- ZenPsycho 9y agometa: it would be good if not every thread on HN about javascript devolved into unproductive complaining about how bad you think it is. It's really not interesting or enlightening to read, and javascript's various flaws are already thoroughly covered elsewhere.
- dboreham 9y agoDon't forget the threads on HN about Git that descend quickly into a celebration of how much Git sucks. 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.
- ZenPsycho 9y agoI see it more as a worrying symptom that software as an industry is full of people who complain about things they don't understand and don't want to learn about. the complaining about javascript is very HN culture specific. there are certainly places where people do complain about it, but only here is it indulged again and again and again ad nauseum. 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.
- deleted 9y ago[deleted]
- Animats 9y agoHere's a question. The latest versions of Javascript supposedly aren't so bad, but some legacy features of the language give problems. There's already "strict mode", which at least requires that variables be declared. Consider a "strict 2" mode, with more restrictions, intended for new, cleaner code. What features should "strict 2" disable?