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

291–300 of 391 posts

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

#291

Post by franciscop »

donatj wrote: post #256
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…

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…

Typescript IS a different language than Javascript (for good or for bad), meaning you are compounding the issues with Javascript ecosystem with the issues with Typescript compilation.

Most of my code today is very straightforward, start a project, add type: module and 90% of the packages will work. If it doesn't, I either pick one of the 1M+ alternatives, try to decipher the issue (often is changing the import format or entrypoint), or avoid using a package for the problem I was trying to solve if trivial enough.

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

#292

Post by giantrobot »

alexb_ wrote: post #142
moribunda wrote: post #137

Earlier quoted context omitted.

Manipulating csv has become way easier than it was. You have: 1. Spreadsheets where you can import this data and manipulate it visually 2. CLI tools made especially to work on csv, with fancy colors, shortcuts, examples 3. Visual tools for data analysis like google data studio, power bi etc. Where you basically dragon drop the data and pick charts 4. RStudio where you can load your data using file->open and then copy…

swear to god if one more person talks about the specifics of this illustrative case, and then goes on to explain how they are so silly and should have used tool "xyz" my head is going to explode

Python does not know what a CSV file is. It doesn't know what a JPEG is. If you want to work with these things you have to tell Python what they are. If you want to use a library to do that you need to know how to install a library such that Python knows what it is and where it is.

You can play around in Photoshop because and get decent results because it already knows what a JPEG is. All of the tools are built around working with 2D images and share a set of abstractions. You might do a shitty job but you're not likely to break your image or be unable to do anything.

Python is not "Photoshop for CSV files". It's not Photoshop for anything. So you must learn some basics to use it an Aella decided learning was stupid and she could just copy and paste her way through the process.

A rational person confronts by terms they didn't understand in some instructions would take a step back and realize maybe they were missing some fundamentals.

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

#293

Post by jhgb »

cutler wrote: post #48
wrnr wrote: post #5

Deno uses ES modules and has a build in TypeScript compiler and solves these issues. Just be careful when using different versions of different packages and always use the same version of a service like esm.sh that translates CommonJS modules to ES modules, it has a versioned API so esm.sh/v70/lodash@1.2 != esm.sh/v71/lodash@1.2. I hit my head on this problem for a couple of days.

But Deno is incompatible with npm, no? Deal breaker.

Why does it matter? Deno should not need NPM in any capacity, or does it?

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

#296

Post by MrJohz »

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…

You're description of the versioning issue doesn't make much sense to me, at least assuming you're talking about editions. Editions are guaranteed to be supported indefinitely, and different crates can have different editions while still being entirely compatible with each other. So a 2032 compiler should be entirely able to continue compiling the 2018 project, even though the depended-on crate is now using the 2030 edition.

The way you describe yanking also seems a bit confusing. If the original project had a dependency that was yanked for security concerns, then the original project was already compromised in the first place. Even then, assuming the lockfile was checked in, then it should still be possible to download the yanked file (plus the compromising code, although the act of downloading a yanked file produces a warning, I believe). If you mean that the project was working fine (no compromise) and then a later version of the dependency was compromised, then no changes are needed at all - the lockfile will always ensure the exact same version is downloaded.

If you genuinely think you've found a situation that isn't solved by the edition mechanism, or by the judicious use of lockfiles for all projects, then I'm sure the Rust team would love to hear it (although I can't speak for them). But from what it sounds like, you're describing issues with the Node ecosystem and assuming they also apply to Rust, despite a number of differences in how the two ecosystems operate.

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

#297

Post by corrral »

donatj wrote: post #256
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…

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the…

This seems like a great place to ask how the ever-loving shit you get a front-end project with simple NPM-fetched libraries to bundle into either a single .js file ready to go in a tag, or a block of tags with all the referenced .js files in a directory and ready to serve. Ideally with typescript support, but surely (ha. ha. ha. ha.) I can just tack that on top and point whatever-this-is at typescript's output directory and my package.json, so that shouldn't be a problem (yeah, right...).

I've written JS professionally for probably 12 or 13 out of the last 22 years, but I skipped the first couple iterations of frontend bundlers and tooling (kept rocking it old-school and just including plain .js files with script tags) until React, so I seem to have missed that intermediate phase, and now I cannot find it. I've lost probably 3 to 4 hours to trying to figure this out, last couple times I looked.

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

#298

Post by cxr »

whiddershins wrote: post #80

It is so true. I have seen experienced developers pull their hair out for a day or more trying to get a basic build system working, or to import a simple module. I have been that developer. I have been that developer, tried to communicate the lessons learned to other developers, and ended up finding out they couldn’t learn from my mistakes and had to reinvent the wheel with many hours of frustration anyway. I develop…

Thanks for sharing this account of your experience. This is helpful in the face of denialism.

See also: https://news.ycombinator.com/item?id=22991033>

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

#299

Post by spaniard89277 »

AlchemistCamp wrote: post #280
spaniard89277 wrote: post #155

Earlier quoted context omitted.

I'm one of those learners and this is true to an extent. But there's fantastic people in r/learnprogramming for example. Even better than the Discord of the self-paced bootcamp I'm doing... But the complexity is real. I'm learning Django, which is supposedly easy, and it's a completely different beast than learning the in and outs of a language. And Django has good documentation, for some libraries it's a mess.

You picked a tough spot to start!

Meh, I'm following the path they tell me. You're probably right tho, but I guess they want to make me employable.

I feel that I will use Django for personal stuff in the future too, so althogh it is comples I have enough drive to get through it.

I can't be many hours on it though. Programming was much more motivating when I was learning the basics, I could be coding all day with no problem. I loved the challenges they sent me.

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

#300

Post by aeturnum »

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…

I agree that the C family has some similar problems but I think you're missing part of what makes Javascript uniquely frustrating.

Javascript is deployed in many different environments and you need to learn not just how to include a library in each environment, but also how to interact with that library. Also unlike C or other languages - Javascript has a hard time warning you about when you've imported something the wrong way. C can at least tell you "this does not link" (so it was found but is binary incompatible) - in my experience if you copy and paste a node import line in the browser the browser will just say "this does not make sense to me." C gives more breadcrumbs.

I also think that once you get outside the C-likes, the story is universally better. For all of its packaging flaws, it's easy to get python packages for development.

Every time I want to make something in Javascript I'm frustrated all over again by how I need to know details about the Javascript ecosystem that I have no way of knowing at this stage (like: getting to hello world can require a working knowledge of WebPack). It's just no where near that bad other places.

Post reply on HN