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

A Modern JavaScript Tutorial

javascript.info

Post reply on HN
Print view View original

271–280 of 299 posts

Re: A Modern JavaScript Tutorial

#271

Post by derivagral »

bovermyer wrote: post #266

This is great. However, it gives the example of copying a variable by assigning another variable to it. This doesn't copy a variable's contents - it makes the new variable a pointer to the original variable. As someone who doesn't use Javascript much... is there a way to force it to copy the current state of the original variable to the new variable, without it being a reference and without having to use something li…

In addition to the cloning stuff, I've seen use of an immutables library [0] to make this stuff a little more explicit and simple. Not sure if that's still fashionable though.

[0] e.g. https://immutable-js.github.io/immutable-js/

Re: A Modern JavaScript Tutorial

#272

Post by SamBam »

DrScientist wrote: post #232
SamBam wrote: post #125

Earlier quoted context omitted.

Because applications on the web are increasingly that -- full applications. I create scientific models and simulations for use in schools. Whether it's simulating a hurricane, or continental drift, electronics, or molecular interactions, the simulations themselves need to run on the browser, and all the UI that provides the users with all the affordances to interact with the model needs to also be written in JS/TS. I…

Hmm - I think that's my point - it's no longer the web is it - just a way to deliver traditional applications. I can see if you want to write an Excel in the web - that you might have a complex code base - but surely that's the exception - not the rule? So back to the statement of 'modern web = ts' Isn't that wrong - these applications aren't really web - and are the exception, not the norm?

> it's no longer the web is it - just a way to deliver traditional applications

This statement is meaningless to me. What makes it "no longer the web?"

"The web" now includes fully-fledged applications. It's fine to make a distinction between things that are full applications and things that are close to blogs, if you like, but it doesn't change the fact that many people develop full applications for the web.

And I think this is clearly a lot more common you are recognizing.

Re: A Modern JavaScript Tutorial

#273

Post by jefftk »

DrScientist wrote: post #233
jefftk wrote: post #114

Earlier quoted context omitted.

Do you think the Zoom web client should have fewer than 10k lines? Or be broken up? What about Google Docs?

Aren't those the exception and not the rule. Hence the statement modern web = ts is wrong. Personally I used the zoom native client and not the web one. I spend most of my time in offline office and not the web version

> I used the zoom native client and not the web one

You might want to reconsider that; they have a pretty bad security track record: https://www.securemac.com/news/zoom-security-flaw-puts-you-a... https://talosintelligence.com/vulnerability_reports/TALOS-20... https://talosintelligence.com/vulnerability_reports/TALOS-20... https://blog.0patch.com/2020/07/remote-code-execution-vulner...

Re: A Modern JavaScript Tutorial

#274

Post by RobertKerans »

OJFord wrote: post #210
codetrotter wrote: post #150

Earlier quoted context omitted.

I think time of day, novelty, luck, and whether any mods notice the post and decide to give it a second wind. By novelty I mean something that is easily recognized as new and important. It doesn’t help that something is new if no one catches the point of reading about it. Could be a bad title or a bad article. Or bad luck. In terms of good luck I mean a couple of specific things especially: - If a few people see it t…

To agree with and concretise what your saying - I think (without actually somehow checking) my most popular submissions have all been something that I was led to by another thing(s) I was reading on HN at the time. Whether conscious or not (probably mostly conscious) I think they simply had the same temporal relevance for other people as they did for me. All that said, I don't know what it would be in this case. I ex…

> What it seems to lack, which I find a sticking point whenever I consider some greenfield personal project, is the dizzying array of 'tooling stuff' that JS has, and how it does or doesn't fit together, etc. There's just all sorts of weird layers and not quite equivalents and can be equivalents but could also be used togethers, half the stuff it's not even clear what it is or if it's necessary at all.

Aha, yes, this. I am [currently] a JavaScript person and it is a shitshow. The cliché used to point and laugh at JS is framework churn, but that's not really much of a thing [imo], it's the tooling. The tools can be genuinely very good if you pick the right combination in the right context, but that's often more luck than judgement.

I suspect as wasm usage becomes more widespread, it'll get worse, not better, at least for a while. There's always a shining future to hope for (and despite the gripes, things have generally improved steadily over the years, so not too idealistic a hope).

If Rome[1] fulfils its goals (big if), then you might get what you want. Very early days though, and going to be very hard for the maintainers to keep control as the scope of the project expands.

Aside, but I think it would be interesting to figure out how much cargo culting is going on with JS tooling. Theory: most configurations of tooling beyond "install CRA/similar" are built up via Googling done when building out highly context-specific configs -> that brings back articles on how to set up tooling that was specific to the author's particular situation -> they are used in lieu of the tool's documentation because Things Just Need To Get Done Now and it's just some dev dependencies, whatever -> those configs are used in a situation they aren't needed -> process repeats.

[1] https://rome.tools/

Re: A Modern JavaScript Tutorial

#275

Post by cphoover »

Hmmm there are a lot of language footguns or advanced features that don't have any disclaimers for beginners. I don't think a beginner should be told to use Proxy object handlers before learning the basics of JS, async and functional programming.

Re: A Modern JavaScript Tutorial

#276

Post by cosmotic »

brundolf wrote: post #70
cosmotic wrote: post #30

Oh no! It's already out of date! (That's a JS changes too fast joke) But seriously, calling it 'modern' is pointless. It's not adding anything valuable and its just going to become out of date (and thus wrong).

Nothing will become inaccurate, because JS never introduces breaking changes. The guide might come to lack some newer things over time, but I doubt those will include any major paradigm shifts, because the past ~10 years have likely been the most dynamic that JS will ever see in terms of idioms and best-practices. JS made a radical shift into a mature language, and now it is mostly on the other side of that transitio…

JS (the language) may never introduce breaking changes, but JS (the ecosystem) sure does. With a quite normal react app, breaking changes are a constant battle. Clone the repo, oops, one package was upgraded that broke another; upgrade that one, oops, it breaks another. The package manager is supposed to deal with that, but it (effectively) doesn't.

Re: A Modern JavaScript Tutorial

#277

Post by hn_throwaway_99 »

feu wrote: post #239
hn_throwaway_99 wrote: post #192

Earlier quoted context omitted.

Yes, in my current tech stack our entire backend is in Node with TypeScript, and the front end is React with TypeScript. > You could argue here there are much better languages and platforms for that. You could, but I think you'd be wrong. I come from a background of using Java on the backend for over a decade, then some time with various backend languages including Python and Ruby. This is the first time in my career…

>primarily because the structural typing of TS makes thing much easier to refactor compared to the nominal typing of Java. That's interesting. This year I switched from server-side Java to server-side TS and I find that refactoring is incredibly painful when compared to Java. I think any productivity gains in the greenfield portion of a TS project are quickly offset by the pain of refactoring and debugging during mai…

I'm curious, could you give an example where refactoring is more difficult? I find TS much more easy to refactor because since the structural typing basically just says, for example, "This method argument needs to have these properties of these types", if I find out "Uh oh, this method actually needs one more piece of data", in Java I'd have to change the definition of the type that was passed in which could have lots more unintended side-effects, while in TS I can essentially "localize" my changes just to wherever I call that method.

The "blast radius" if you will with nominal type systems is just always much larger.

Re: A Modern JavaScript Tutorial

#278

Post by pwdisswordfish4 »

resu_nimda wrote: post #223
pwdisswordfish4 wrote: post #206

Earlier quoted context omitted.

> It seems clear that you find niceties and pleasantries to be not genuine or unnecessary Wrong. It seems clear you all like making assumptions and treating them as unshakeable truth. I scarcely think that your suggested wording (your second attempt, keep in mind) would have satisfied even you without this conversational backdrop providing context. > I highly doubt it would have performed worse than your strategy, Th…

> Wrong. It seems clear you all like making assumptions and treating them as unshakeable truth. Can you explain, then, why 1) your original post was devoid of any such language, and 2) you dismissed my suggestion, which added some, as being likely to cynically have the opposite effect of what was intended? I get what you're saying. People often do couch cynicism and trolling in pleasantries. Which makes it difficult…

There's a perverse irony in the way your responses here exude condescension while ostensibly trying educate and inform about the sort of things that people respond to. Although it looks like you came here to argue (which now explains the presumptuousness), I didn't, and I'm not wasting any (more) of my time indulging you.

> I get what you're saying. People often do couch cynicism and trolling in pleasantries.

No, apparently you don't, because that's not at all what I said or what I'm trying to say. Aside from failing at that, you almost succeeded at deflecting, but not quite. The attempt to change the subject and avoid responding directly is yet more reason to stop this here.

Re: A Modern JavaScript Tutorial

#279

Post by OJFord »

RobertKerans wrote: post #274
OJFord wrote: post #210

Earlier quoted context omitted.

To agree with and concretise what your saying - I think (without actually somehow checking) my most popular submissions have all been something that I was led to by another thing(s) I was reading on HN at the time. Whether conscious or not (probably mostly conscious) I think they simply had the same temporal relevance for other people as they did for me. All that said, I don't know what it would be in this case. I ex…

> What it seems to lack, which I find a sticking point whenever I consider some greenfield personal project, is the dizzying array of 'tooling stuff' that JS has, and how it does or doesn't fit together, etc. There's just all sorts of weird layers and not quite equivalents and can be equivalents but could also be used togethers, half the stuff it's not even clear what it is or if it's necessary at all. Aha, yes, this…

Rome just sounds like XKCD standards.

It starts off by giving installation instructions for yarn/npm/npx. Which should I use if I'm starting a project and I heard on HN Rome is the easy one true way to do it? I don't already have yarn or npm or npx so there's no existing reason to care, but now I feel I need to find out about them and their potential tradeoffs since it's probably easier to choose now than change later.

And then you get past that and want to use LSP with your editor, and realise it's not one tool to rule them all after all anyway!

Re: A Modern JavaScript Tutorial

#280

Post by _greim_ »

letitbeirie wrote: post #189
_greim_ wrote: post #107

Earlier quoted context omitted.

I've been thinking a lot about why this is, and I think one reason is because TS adds mental overhead to the language, while simultaneously removing other mental overhead. However, for JS programmers, worrying about types is habitual. Offloading that task to a robot is great, but it doesn't mean the habit will just disappear. Thus to them, TS seems to mainly add overhead.

> for JS programmers, worrying about types is habitual Couldn't the same be said for COBOL programmes and GOTOs?

Yeah I guess I'd generalize it as programming having two kinds of learning. First is memorization of syntax and semantics of the language. Second is a kind of shadow learning, or "street smarts" for survival in the language; which parts of town to avoid and which paths avoid dark alleys, etc. These habits are hard to quantify, and beginner programmers especially tend to apply the "street smarts" from their first language to every future language, which creates problems.
Post reply on HN