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

231–240 of 299 posts

Re: A Modern JavaScript Tutorial

#231

Post by speedgoose »

earthboundkid wrote: post #155
speedgoose wrote: post #121

Earlier quoted context omitted.

template, bytes, string.

`bytes` is the name of a stdlib package. `string` is the name of a built in type. `template` is technically available, but only because it’s the name of this package, so it can’t refer to itself.

True, but they are all available. The stdlib bytes packages is not loaded, and it's valid to use `string` as a variable name, I just tried.

But even if these names were not available, I don't think using `tpl` or `t` or `b` is what should be preferred.

Re: A Modern JavaScript Tutorial

#232

Post by DrScientist »

SamBam wrote: post #125
DrScientist wrote: post #102

Earlier quoted context omitted.

I'd guess I'd have to question why you need 10K lines of code for a single web page - perhaps you need to break up your SPA?

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?

Re: A Modern JavaScript Tutorial

#233

Post by DrScientist »

jefftk wrote: post #114
DrScientist wrote: post #102

Earlier quoted context omitted.

I'd guess I'd have to question why you need 10K lines of code for a single web page - perhaps you need to break up your SPA?

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

Re: A Modern JavaScript Tutorial

#234

Post by z3t4 »

heavyset_go wrote: post #229
sanderjd wrote: post #221

Earlier quoted context omitted.

I don't get this. What do you mean by coffeescript vibes? They are super different languages...

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.

Re: A Modern JavaScript Tutorial

#235

Post by randomsearch »

wwweston wrote: post #227
stingraycharles wrote: post #142

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=2024328 Here’s an example great bike shed discussion from ~10y ago about whether or not to use semicolons with JavaScript. “If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision, and you definitely should not tell anyone else how to write their J…

Something I always thought was interesting about that argument is how a similar line of reasoning could apply to the `==` and `===` comparison operators. Just about anyone who's ever written JS probably knows about the heavy lean towards "always use `===`". And it's not without good reason, because there are more than handful of not-entirely-intuitive implicit coercions/comparison corners associated with `==`. Person…

“Explicit is better than implicit.”

Re: A Modern JavaScript Tutorial

#236

Post by DrScientist »

uryga wrote: post #170
DrScientist wrote: post #104

Earlier quoted context omitted.

I understand the power of types - I just wonder why the heck you are writing so much JS/TS code? Are you doing server stuff with it? You could argue here there are much better languages and platforms for that.

have you worked with GUIs much? complex interactive UIs take a surprising amount of code, doubly so if what you're doing isn't covered well by your platform/toolkit's native inputs. i'm working on a webapp with a scheduling thing and even drawing a nice-but-not-interactive day schedule is a bunch of work. consider a day view that lays out overlapping events next to each other: Dec 8 ----------- 9 10 AAA 11 AAA BBB 12…

But you can split it with with web components and es6 modules to be sane without resorting to a pre-processor so you code won't run directly on the platform.

Re: A Modern JavaScript Tutorial

#237

Post by DrScientist »

raytracer wrote: post #169
scpedicini wrote: post #143

Earlier quoted context omitted.

I don't really experience this issue and I use Web storm which is basically the same thing. I find that the dynamic type hinting plus the combination of using JS Doc formatted comments rarely leaves me with any ambiguity when writing vanilla JavaScript.

Are you using types in your JS Doc comments? If so, that's not vanilla JavaScript.

It is because it runs in the browser unprocessed.

You edit a file and reload, no munging pipeline,

Re: A Modern JavaScript Tutorial

#239

Post by feu »

hn_throwaway_99 wrote: post #192
DrScientist wrote: post #104

Earlier quoted context omitted.

I understand the power of types - I just wonder why the heck you are writing so much JS/TS code? Are you doing server stuff with it? You could argue here there are much better languages and platforms for that.

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 maintenance. It's really disappointing, as I quite like TS.

Re: A Modern JavaScript Tutorial

#240

Post by qwerty456127 »

So glad people still make things like this despite so many tutorials and books already being available. This means people still care to make something purely for sake of making it better - obviously nobody would be interested if it wasn't. Crafting tutorials should be considered an art.
Post reply on HN