Live data from Hacker News

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

lea.verou.me

371–380 of 391 posts

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

#371

Earlier quoted context omitted.

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 the…

Setting aside Django and learning it as a beginner, the job market for Python as a whole is a bit odd. It's great for grad students coming in from other disciplines but pretty harsh and credentialist towards the more typical self-taught web dev profile.

That said, both the concrete things you pick up with the language and the meta skills you pick up fighting with frameworks, libraries and dependencies will come in useful. Keep learning and you'll be more employable. Best of luck! I've been there.

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

#372

Earlier quoted context omitted.

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 the…

Setting aside Django and learning it as a beginner, the job market for Python as a whole is a bit odd. It's great for grad students coming in from other disciplines but pretty harsh and credentialist towards the more typical self-taught web dev profile. That said, both the concrete things you pick up with the language and the meta skills you pick up fighting with frameworks, libraries and dependencies will come in us…

Thanks, after Django comes Spring. I found java cumbersome but apparently there's much more java work in spain.

I'll see how it goes.

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

#373
post #293
post #48

Earlier quoted context omitted.

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

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

Because npm is the biggest repo in the history of computing and Deno makes it redundant. The people at Jetbrains knew about backwards compatibility when they created Kotlin. It's too late to just ditch npm.

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

#374
post #363

Earlier quoted context omitted.

Given how many front-end packages are on NPM, it's obviously not the case that the libraries provided were sufficient for scripting the DOM. Just take left_pad itself, that's something the language should provide, and it's an issue that it ended up being a point of failure. I have no particular love for using JS as a language to power everything from IoT devices to web servers, but it doesn't really matter how I feel…

>Just take left_pad itself, that's something the language should provide, and it's an issue that it ended up being a point of failure. Why should the language provide that? What other languages provide an equivalent to that? left_pad is intended for formatting text within a terminal, not a website. There's no need for it within the context of a website, because HTML has tables, CSS and other elements for that.

> What other languages provide an equivalent to that?

https://www.php.net/manual/en/function.str-pad.php

https://docs.ruby-lang.org/en/3.1/String.html

https://developer.apple.com/documentation/foundation/nsstrin...

> left_pad is intended for formatting text within a terminal, not a website. There's no need for it within the context of a website

This is just not correct. It’s for padding a string with any character, for example adding leading zeroes to a number for display purposes. There are plenty of reasons to want to do that in a browser.

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

#375
post #373
post #293

Earlier quoted context omitted.

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

Because npm is the biggest repo in the history of computing and Deno makes it redundant. The people at Jetbrains knew about backwards compatibility when they created Kotlin. It's too late to just ditch npm.

Not quite sure why you shouldn't be able to create a proxy service that serves NPM packages in a form that Deno can consume if you feel the overwhelming need to use NPM packages. (I don't, personally, but tastes differ, I'm sure.)

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

#376
post #161

Earlier quoted context omitted.

Oh, there is another way to code with JS on the server side? Something else besides node?

Don't code with JS on the server side at all. There's no real advantage to having JS both on the server and in the client, and there are plenty of alternatives that actually support the features Typescript and the like pretend exist in JS, but really don't.

That sounds like that should have started with "Don't code with Typescript on the server side at all" instead. If Typescript is pretending things unsuccessfully, you might as well stick with plain Javascript. (It wouldn't surprise me if Javascript ultimately lived longer, just like Smalltalk actually outlived Strongtalk in the end.)

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

#377
post #54

Earlier quoted context omitted.

Go is yet to prove its stability over timespans similar to those languages you've mentioned, but it doesn't have many of noted (and similar) quirks.

I recently had to work on a library I wrote in Go in late 2013. I think it was Go 1.2 back then. (Current release is Go 1.18) It just worked. And code was quite readable. I mean it not as a complement to myself, rather the fact that Go is designed to be readable and it pays off. I only had to add modules support (basically run `go mod init` in the library's folder) to make it 100% modern-version friendly. That was as…

I don’t think it is that impressive, though I have the most experience with Java, where a fat jar on a random, obsolete website displaying some university material will just work.

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

#378

Earlier quoted context omitted.

Webpack can be rather complex but that's because you can do a lot with it. It's not really any harder to learn than any other piece of software and the person you were replying to is correct in referring to the official documentation. If you go through the official tutorials you will come out the other end knowing perfectly well how to configure it from scratch. If you don't want to dedicate a few hours to learning W…

This works until you need to have one tiny thing different than the standard path, that a tool implements. Usually the problems come, when you do not want to do the thing "everyone else" does, but want to avoid some downside of that mainstream approach. The contrast is other programming language ecosystems. Once you understand how they look up modules from which to import things you need, you are set and can deliver…

> Once you understand how they look up modules from which to import things you need, you are set and can deliver a working program

Sure, being restricted to a single paradigm can simplify things in this regard but it comes with its own set of problems. I've used build systems and package managers for C/C++, Nim, D, Python and a number of others and they all come with their own headaches, learning curves, bugs, and WTFs. Software is never perfect, documentation is incomplete and inaccurate and sometimes shit just doesn't work the way you need it to. You can write terrible code in any language, if you need proof just do a filtered search on GitHub for your language of choice and page through some of the projects. I don't think JS is any more at fault than the rest, it just has more people learning it and hacking things together so you see more of it. It's not the programming language's fault if you write bad code, that's always up to your own proclivities and time constraints so I don't think we should try to pin it on the existence of such and such a module or library or the design of the package manager.

The hugely positive side is that there are a large number of people in the JS ecosystem actively trying to solve these problems and also educating others on how to solve their own. It's a bigger tent than any other programming language I've used, more active, welcoming, less judgemental and more beginner friendly. For people just beginning programming I'd still recommend starting with JS for those reasons.

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

#379
post #21

I can feel the author, in particular about the mess that is node_modules resolutions (and the fact that it sounds like 99% of "tutorials" - or even package READMEs - about Node seem to be written by someone that didn't really think things through). Anyway: I think the underlying problem is that it has been hidden that Node is NOT JavaScript. It uses (some) of the JavaScript syntax, but it doesn't use its standard lib…

I think the reason it's worth it (to the extent that it is) is not that it's good for novices, it's that it can leverage V8 and libuv. If your claim is "you're on the backend, you have saner options" then I would agree, but this isn't really about beginners.

Don't get me wrong: the reason why both Node and Deno (and probably JavaScript itself!) are so successful is that v8 is a ridiculously good runtime, and libuv is great.

Deno did something smart: all the non-web-compatible APIs are under the Deno package. That's great, and almost fixes the issue I am highlighting.

If Node could do the same, and provide a way to find at "compile time" (that is, statically), if a package is web-compatible or not, that would be very good.

My issue has probably more to do with npm than with Node itself.

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

#380
post #267
post #202

Earlier quoted context omitted.

Well, I disagree with everything you say (especially calling this gatekeeping). You simply are unwilling to learn about the tools you're working with. I'm sorry we couldn't work it out. Best of luck!

It isn't ignorance - the people who complain the loudest about the JS ecosystem are the people who use it the most.

I can see what you're saying. I agree and don't think it's ignorance, which is why I'm calling it false entitlement. It's all open source software, maintained by humans just like the rest of us. I'd say, go do something about it if you care so much, instead of complaining.
Post reply on HN