Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Today’s JavaScript, from an outsider’s perspective (2020)

lea.verou.me

Post reply on HN
Print view View original

91–100 of 391 posts

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#91

Post by IshKebab »

jiggawatts wrote: post #56
gernb wrote: post #31

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…

Meanwhile I've been trying to warn the Rust project team, or more specifically, the Cargo/Crates teams that they're cheerfully skipping down the easy/happy path towards the same mess. It's inevitable that the conclusion will be the same if the same steps are taken in the same direction. The counter-arguments fail to recognise the special case of "most of us are from Mozilla and we all get along[1]", "no-one has attac…

I don't think the Rust team are unaware of supply chain attacks, so you don't need to warn them. It's just that there's no easy solution. Or do you have some easy solution they aren't doing. Just to pre-empt you, namespacing doesn't solve the issue and manually vetting authors/crates is not something the Rust community wants.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#92

Post by mojuba »

astrange wrote: post #59
mojuba wrote: post #57

Earlier quoted context omitted.

I think static languages are generally more disciplined and manageable in this regard. The only times I struggled with 3rd party Swift code was when a package included some C or C++ code alongside with Swift. Specifically, I think Apple's philosophy of "everything comes with its own dependencies embedded" saved us a lot of trouble. Sure, it's more disk space and potentially lots of duplicates (just count the number o…

MachO has some features that make this easier than ELF, namely matching libraries by full path and two-level namespaces (external symbols know which library they're found in). Though it's still not great if everyone uses their own SSL library, because then you can't update it if there's a bug.

Yes it's a problem, but because you (as a library maintainer) are responsible for what you are embedding, you should keep an eye on the dependencies and test them with each update. This creates a hierarchy of responsibilities, as opposed to a flat mess that is Linux .so or Windows .dll approach.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#93

Post by lelanthran »

hyperpallium2 wrote: post #82
gernb wrote: post #31

sounds like the same experience I have with pretty much every language I'm not used to. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error. repeat the same with xcode and any project in c, c++, objc, swift okay how about ruby? oh I have old…

It is unique to old languages. Young languages are easy to get started in. Ruby used to be. Though ruby has a separate problem of breaking changes . The back-compatibility crowd can run old code (e.g. java), but at the cost of their soul.

> It is unique to old languages.

Rust is a new language, and it has the same complaints above.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#94

Post by tosh »

alexb_ wrote: post #72
alexb_ wrote: post #63

This thread is also a good read: https://twitter.com/Aella_Girl/status/1522633160483385345 Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is…

Was going to edit this in but it quickly turned into a related rant about the state of things: if you don't want that, scroll past. The real problem is that there's no more room for the technological "middle class". We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself, or make something small to share with the world. You either have to have no interest…

In a sense no-code tools are today’s Visual Basic.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#95

Post by mattlondon »

qwertox wrote: post #89

This is exactly my issue with all this modern JavaScript / Node-stuff. The boilerplate just to get the simplest thing started is brutal. Now I'm dealing with some Vue3/Quasar/TipTap stuff, and I still don't know what exactly I have there, but just that it is working somehow. Python is such a pleasure to work with that I wish that all this modern web stuff were more like it.

If you try simple vanilla javascript, then you may be surprised at how pythonic it is in cerain ways - e.g. just open a browser (any browser!) and you have a javascript REPL read to go in the developer tools.

Node severely complicates and confuses things, but node alone is not javascript. Vanilla JS is IMHO a very nice and expressive language, and you do not need any of the Node/Webpack/React/Vue/jquery/whatever to do effective things in Javascript these days as it is very capable on its own.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#96

Post by IshKebab »

Gigachad wrote: post #85
IshKebab wrote: post #77

Earlier quoted context omitted.

I disagree. I've never had issues of the magnitude of JS's mess with random free code written in Go or Rust. I think the reasons for it in JS's case are kind of reasonable though. Just annoying that it's taking so long to sort out.

I have had plenty of issues trying to get packages from Rust working. Half of them depend on external libraries and its up to you to work out what package for your distro satisfies the compile. And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult. I don't blame any of this on Rust. You can be expected to be proficient in the tools as t…

> Half of them depend on external libraries

Bit of an exaggeration. Some do. I would say more than with Go, but waaaay less than half. Maybe like 1/10th. OpenSSL is the most annoying.

> And then if its not a binary tool, you have to work out how to use it in your code, which if you are a Rust outsider, is very difficult.

I don't understand this. Of course you have to work out how to use a third party library in your code. Do libraries in other languages magically integrate themselves?

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#97

Post by lelanthran »

whostolemyhat wrote: post #66
mattlondon wrote: post #62

Earlier quoted context omitted.

I guess the first thought that springs to my mind is why should ECMAscript care about what node does? Standard vanilla modules just seem to work totally fine without any issues (in standard vanilla javascript environments) while being totally intuitive, and is basically identical to how typescript does it too... and it is even very similar to how Deno does things. It seems to me that nopde + npm here is - as usual -…

> why should ECMAscript care about what node does? Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?

> Yes, why should EcmaScript pay any attention to one of the most popular uses of the language with millions of people using it every day?

They shouldn't pay any attention to it. The language spec should drive the implementations, not a single implementation driving the language specification.

Normal exceptions for languages that have a spec based on a reference implementation.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#98

Post by lionkor »

alexb_ wrote: post #63

This thread is also a good read: https://twitter.com/Aella_Girl/status/1522633160483385345 Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is…

> the only reason this barrier was ever breached for this person was due to their large twitter following

I feel like their approach to solving the problem actually does represent how most people deal with it - they ASK someone. There are hundreds of massive programming discord servers, with extremely engaged tutors, helpers, and resources.

If you want to learn to program, you'll need guidance, and I think that's OK. You won't go buying any old welder and some metal and just start welding (or at least it won't go very well). You'll seek out people who already do it, get advice, or maybe even seek an education in it if you are really aiming for the long term.

Programming looks like it has a low barrier of entry, because you don't have to commit to much. To weld you need to buy (or rent) a welder and material, to do carpentry you need to buy at least some basic tools, to work on your car you need a car, to be an architect you'll need to pay someone to build it, etc.

For programming, you seemingly only need a computer (or even just a phone), which most people have access to. This apparent lack of need for commitment makes it look like "it shouldn't be that hard", but that's IMO a complete misunderstanding.

This is why I'd prefer hiring people who have at least somewhat of a formal programming education. In my university, for example, we learned how to use git, linux, write JS, CSS, html, c++, php, do SQL, manage and design databases, and generally just learned a lot of "background knowledge". With that, it's trivial to pick up almost any tech afterwards.

For anyone else trying to get into programming, join a discord or reddit, or slack, or matrix, or IRC community, which is focused on what you're learning. It will save you weeks of trying.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#99

Post by threads2 »

hudo wrote: post #81

My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tuto…

Always wanted to learn about webpack - doesn't feel good using CRA (create-react-app), needing to configure webpack, ejecting CRA, and then being the "owner" of the config without knowing anything about it - thanks for the impetus.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#100

Post by AgentME »

mattlondon wrote: post #42

I think the problem was using Node in the first place - most the article is fighting node + NPM nonsense. I personally try to avoid Node + NPM where I can these days, and use Deno for backend stuff since it is much more sane IMO. I've never heard of people putting typescript into a .js file - is that some node thing? Modules in the browser for vanilla JS is a delight and Just Works though. I've started doing it recen…

+1 for Deno. It seems like it's taking the good ideas that developed from the node+npm ecosystem while filing off the unnecessary complexity that's accumulated in the ecosystem over the years. I've worked with node+npm+typescript/babel/webpack/etc for years and know the ecosystem pretty well, but I get apprehensive when thinking of starting a new project with it because there's such a deluge of not-very-meaningful choices and piles of configs for using best-practices while setting up a project. Getting into using Deno has been so refreshingly simple in comparison, and it's made me enthusiastic about starting new projects or libraries.

I've had some game/mod ideas for a while that involves having players write real code to interact with games, and I would create some tutorials for beginners to get started writing code so they can use it. I love Typescript and think it would make a good language for it, but I absolutely dreaded the idea when I realized using it properly would involve having to onboard users to all the tooling of Node+npm+build configs+testing tools+eslint etc. Onboarding users to Rust properly almost seems simpler in comparison because of its integrated tooling even accounting for the fact that the language itself is so much harder to use! I mostly scrapped the idea for the time being because of this, but now that I've discovered Deno I've been reinvigorated on the idea. A beginner tutorial involving Deno can actually focus on using the language with a few libraries without having the user get sidetracked into being distracted by a dozen other tools.

Post reply on HN