Like the email based one more. But this seems more complete.
A Modern JavaScript Tutorial
281–290 of 299 posts
Re: A Modern JavaScript Tutorial
#282Earlier quoted context omitted.
I get CoffeeScript vibes from TypeScript, and look at where CoffeScript is now.
> and look at where CoffeScript is now Largely absorbed by modern javascript? ;-)
If you look below, this is my point. It's inevitable for JavaScript to adopt most of TS' flagship features.
Re: A Modern JavaScript Tutorial
#283Earlier quoted context omitted.
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.
This aspect is irrelevant to the discussion because the OP only covers the language itself.
Re: A Modern JavaScript Tutorial
#284Earlier quoted context omitted.
In that JavaScript only needs to adopt a few of its features for the benefits of welding yet another compiles-to-JS toolchain on to projects to dwindle in comparison to writing ES8+.
Adding optional type annotations to JS would be interesting. It might help with VM optimization.
Python already does type annotations, and I have no use for Mypy other than using it for type checking in my editors via LSP. I don't import it or use it as a dependency at all in projects.
I feel like JavaScript adopting type annotations in a similar manner will make TypeScript look the same as Mypy in many regards: nice to have, but not necessary most of the time because the parent language ships with most of its features.
Re: A Modern JavaScript Tutorial
#285Earlier quoted context omitted.
I used to be on the "always use semicolons" side of this argument. Having shipped multiple projects using both methods my verdict is clear: It doesn't matter. Why it doesn't matter you ask? Because 1) I am enforcing either decision with eslint rules and 2) i write unit tests 3) code is transpiled (thus semicolons are handled perfectly at the output). Having these three in place, I have yet to encounter a single "gotc…
>I have yet to encounter a single "gotcha" out of omitting semicolons. keyword "yet". It seems like such a insignificant win, with the downside being some very hard to debug runtime error because one element of your build chain has a bug or misses an edge case. I honestly don't see the logic.
I explained the logic: By having tooling and tests it place, I am protected against gotchas and I haven't ever encountered a problem. Thus, i do not advocate you must ommit semicolons. I am saying "it doesn't matter what you do" provided you have the tooling in place. Do whatever feels best, what you like, what you feel comfortable with.
And here is the upside: I've minimized the time I spend arguing about this detail with my colleagues to 0s. Because it doesn't matter :)
Re: A Modern JavaScript Tutorial
#286Earlier quoted context omitted.
> 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 late…
I get the analogy, but build/lint/format functionalities are currently split across multiple different tools and their many multiple plugins. They aren't standards, they're just a bunch of tools that people have to glue together every time they create a new project. Attempting to put them together into a single binary with no dependencies isn't creating another standard, it's just creating a single tool (one similar to those extant for other modern languages).
I realise you may be being slightly facetious to make a [fair] point, but if not: Yarn and NPM are package managers, NPM comes with Node. npx is a command line tool for npm that generally obseletes most need for globally installing packages, it is a small but nice nice recent improvement to the JS ecosystem.
LSP is a protocol implemented by plugins for text editors/IDEs, it's got nothing to do with a specific language, what do you mean by mentioning that?
Re: A Modern JavaScript Tutorial
#287Earlier quoted context omitted.
> 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, app…
> 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.
That's a fair point, and later last night I regretted having used some unhelpful rhetoric. I often struggle to resist that temptation. In my defense though I was only going toe to toe with someone who had already demonstrated a willingness to dispense with courtesy in the name of pure inquiry.
Re: A Modern JavaScript Tutorial
#288Earlier quoted context omitted.
What are you talking about? Did you even take a look at the table of contents?
I didn’t downvote, but calling people out for not reading the article — even if it seems blindingly true — is against HN rules and always gets downvoted.
Now I'm being downvoted because my comment seems like a non-sequitur. But prior to an edit, my parent was wondering why they were being downvoted, which is what I replied to.
Re: A Modern JavaScript Tutorial
#289Earlier quoted context omitted.
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 late…
I get the analogy, but build/lint/format functionalities are currently split across multiple different tools and their many multiple plugins. They aren't standards, they're just a bunch of tools that people have to glue together every time they create a new project. Attempting to put them together into a single binary with no dependencies isn't creating another standard, it's just creating a single tool (one similar…
Yarn and npm I'm familiar with, though I don't know why to prefer one over the other. Yarn's newer, I suppose that's pro or con depending who you talk to. Npx I had no idea.
LSP has two parts, a client implented by an editor (or plugin for one), and a server for whichever specific language.
If you always use vim but several languages, you need one language client for vim, and a language server for, yes, each specific language you want to write with it. `vls` for example for vue/js/etc. distributed with `vetur` which is God knows what also distributing God knows what else, and the rabbit hole continues. :)
(And your language server might be the only linter and formatter you need/want, so they're then wasted being in Rome, is what made me think of it.)
Re: A Modern JavaScript Tutorial
#290Earlier quoted context omitted.
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, app…
> 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. That's a fair point, and later last night I regretted having used some unhelpful rhetoric. I often struggle to resist that temptation. In my defense though I was only going toe to toe with someone who had already demonstrated a willingness to dispens…
Shoehorning big words into a message usually has the opposite of the intended effect. This instance is not the exception.