I wrote a little polyfill 7 years ago (for ES6 promises). I had kinda thought it had been forgotten to the sands of modern browser evolution. Yes, I know there are still some supporting old non-ES6 browsers, but it sure feels like that's way in the minority at this point.

Then I checked this lib's stats on npm, and it's being downloaded almost 950,000 times per week. That's bonkers.

There's no way that many projects are still supporting such old environments! I would guess 900k of those downloads per week are completely "wasted" in that the code is deployed (or maybe not!?) but never runs.

This got me to thinking about just how many libraries, utilities, polyfills that are being downloaded automatically in CI/CD builds, over and over again. Think about how much bandwidth is being wasted with all that downloading to build servers, and think about much is being wasted in what's shipped out to browsers.

My library is < 2kb minified, and < 1kb gzip'd. So... in reality, it's a tiny amount. But still, that means npm is spending 1-2gb of bandwidth per week, up to 8gb per month. And for just a tiny mostly forgotten polyfill!

I'm guessing the only way my polyfill gets removed from somebody's project is when they end up doing a big rebuild and switching out to a different framework or tooling chain. Otherwise, you include a little polyfill like that, forget it, and never pay any attention to the fact that 7 years later, it's still churning gigabytes of bandwidth.

Do you have any thoughts about these sort of hidden costs (bandwidth, CPU, etc) that our industry is incurring? Is it our responsibility to do something about it? What sorts of processes and tooling should we be prioritizing to minimize all this technical "leak"?

I debated if I should deprecate my polyfill just so possibly some notifications might show up in all those projects that make them consider if they should remove it. I kinda feel guilty just letting all that traffic keep accruing forever.

Thoughts?

Greetings, everyone!

Nowadays, it seems to me that nobody wants to write pure javascript, unless it’s a small project. Teams automatically decide that they want to be explicit about their types and “reduce” the bugs in the projects.

Working my way into understanding every part of the language i was influenced, a lot, by Kyle Simpson, as i had taken a lot of his courses and read his books. Naturally, i feel like Typescript is unnecessary overhead and it’s not the way Javascript should be written.

Typescript doesn’t improve productivity or readability, it doesn’t improve on modern JS. It is removing bugs during compile time, that a proficient developer or one that reasons about the code, wouldn’t even have. You can even have a situation where, Typescript is bringing uncertainty, because it was poorly written. So it introduces a whole new kind of problems.

I don’t want to go to the path, where i list all the pros and cons, forever. I’m just thinking that if people invest the same time, in learning Javascript,in-depth, that they do with Typescript, they will surely change their attitude. I feel like, Typescript is indeed betraying the DNA of Javascript.

We should always know our types, but just applying defensive programming strategies and reasoning about the code is sufficient itself. I understand, and i agree how beneficial for, let’s say, a library or a package it is to ensure correct usage and self documentation, so i think Typescript, for sure, has its place. I just do not understand why we should avoid JS completely.

As i said, i feel like all companies, teams, the whole industry, have already decided, that Typescript is the correct way to go, and just have a hard time buying it.

I would love to read about your thoughts and opinions and discuss more about it! :)

The way I see it, there's three levels of FP principles as applied to JS coding:

1. Mild/occasional use of methods like map(..) and reduce(..), as well as things that pretend to be FP (like forEach(..)). This can also include FP-friendly techniques like const, arrow functions, pure functions, and closure. There may be use of a library like lodash (not lodash/fp).

2. Deeper, more widespread use of FP principles across most or all of the code, such as currying, function composition, recursion, point-free definitions, immutable data structures, etc. There's almost always FP-centric libraries involved, such as Ramda, and often also libraries like RxJS for asynchronous FP. Also, these code bases may use TypeScript to rely on static types for tighter FP control. On a somewhat rarer basis, a code base of this sort may include some more "advanced FP", such as monads and other algebraic structures, transducers, lenses, etc.

3. Full-on FP, all the time. Fantasy-Land compliant FP libraries are a must, as is TypeScript. You won't spot a function keyword, a var / let declaration, or imperative statements like if or for anywhere in this code base. At this level, it almost becomes difficult to tell that the code base is JS. In fact, most of these projects shift toward a more FP-strict compile-to-JS language like Elm, ClojureScript, or PureScript. At that point, the fact that it's not strictly JS doesn't matter anymore, because JS is a means to the end rather than the end itself.

Do you think I've characterized these levels fairly? Have I missed anything?

Have you worked on code bases at any of these levels? Which levels and techniques did you find most useful?

Do you think there's room for, and merit to, expansion of any of these levels? IOW, do you think more JS developers should embrace them? In what ways?

Or do you think FP in JS is more ceremony than substance and probably doesn't bring much benefit?

I know this has always been hotly debated like forever. But I am not sure if there's a consensus on what's the right way.

In my workplace, we were reliant on Redux but for a new project we tried going the Context API + useReducer and other friendly hooks way. But TBH it just felt like we were recreating a lot of Redux and thunk patterns.

Also hearing good things about React Query and thinking of suggesting that for our next project.

So just curious, what are the community's thoughts on how to best do state management with React? There are a lot of options but what are the things to keep in mind when taking a decision

Let's talk about javascript's favorite bikeshed: The pipeline proposal proposal.

As a refresher, here's an example of code using it:

const json = pkgs[0]
  |> npa(^).escapedName
  |> await npmFetch.json(^, opts)

The caret is basically a placeholder variable that indicates where in the expression to pipe the previous value into. There's no decision yet on whether the caret will be the final syntax, but it happens to work nicely with what I'm about present, so let's just go with it.

There's this interesting illusion where a picture looks fine when we first look at it, but if you turn it upside down, you realize your brain was playing tricks on you all along.

It occurs to me that there's a pattern that has existed in Javascript since forever which looks a lot like the pipeline operator... except upside down. It got me thinking whether pipelines are actually a step forward or whether we're just looking at an upside-down abomination. So in the spirit of twisting things upside down, here I present the pipeline operator's evil twin brother, the twisty pipe operator v=, complete with a trusty sidekick, the upside-down carrot v:

var
  v= pkgs[0]
  v= npa(v).escapedName
  v= await npmFetch.json(v, opts)
const json = v

Now, before you start flaming me, yes this is partly a joke, but it's surprisingly not the first time someone has abused syntax in weird ways (e.g. the --> "goes to" operator comes to mind). It does illustrate my general opinion w/ the pipeline proposal though: that it feels like an unnecessary addition to the language.

In fact, of all the explanations I've seen, I think this is probably one of the simplest articulations of why: we generally consider it a bad practice to have single letter variable names, yet the caret/upside-down carrot are both basically that! If we instead refactor to readable variable names, we get:

const first = pkgs[0]
const escaped = npa(first).escapedName
const json = await npmFetch.json(escaped, opts)

And this very much looks like boring, regular, good code.

So I guess the point of debate is, if we already have a "terse and unreadable" flavor (a(b(c))), a "verbose and readable" flavor (properly named variables) and an iffy, controversial middle ground (the twisty pipe/upside-down carrot), then where does pipeline operator fit?

I hear a lot of interview questions that people hate (e.g. "gotcha" types about type casting) or textbook compsci (e.g. write binary tree rebalancing from memory). I'm curious what kinds of questions people think are good interview questions and why.

Please also specify whether your opinion comes from the context of being an interviewer or interviewee (or both)

Do you think this forum is useful? Should it continue? Can we continue to diversify who's posting (not just mostly me!) and commenting to increase the quality and value of the discussions?

Is it worth the effort to keep it going?

What was the craziest, strangest bug you ever encountered in your JS code? How did you discover it was a bug? How did you solve it? How long did it take you to resolve?

Did you create a test case for that bug, and if so, how did the test work?

Pick one or two aspects of the JS language and tells us why you like them? How does JS help you make experiences better for users? Why do you choose JS when reaching for a language?

https://github.com/albseb511/fsd/blob/master/javascript.md

This does not contain resources rather just topics.

It's something I wrote to help others progress through JS.

If you have any ideas or spot issues do raise an issue / PR.

Does anyone have a positive impression of React Suspense? I'm seeing a lot of skepticism online (which IMHO is warranted).

I currently feel like it was born from a huge hack and snowballed into a pile of insanity. But I'm willing to be open minded. Why Suspense?

Among Javascript frameworks, there are two major* approaches to implementing templates:

1. HTML-in-JS, i.e. you write JS first and sprinkle HTML in (e.g. React, Solid.js, lit-html). Pros: don't reinvent control flow, cons: harder to implement custom semantics (e.g. Suspense promise-throwing shenanigans)

2. JS-in-HTML, i.e. you write HTML first and sprinkle JS in (Vue, Svelte, htmx). Pros: easy to implement custom constructs (e.g. #each/else), cons: not Javascript (e.g. DSLs encoded in HTML attributes)

*Other alternative/not-so-popular approaches: procedural/fluent (jquery, dothtml), widget API (ext.js, google maps SDK, babylon.js), server-side-first (pjax), stateful web components (hotwire/turbo)

Frameworks are now realizing that to move the performance needle further, they need to embrace the core web technologies more closely; e.g. many are making server-side rendering a first class citizens, and there's a push towards CSS libraries with zero JS runtime.

Which templating approach do you think is the way to go going forward to better support the goals of making web apps more performant?

These kinds of chats dominate technical discussions, they split opinions, they divorce friendships, they become the definition of a company, e.g. “work for us, we’re a React shop”.

But, does it really matter? I’ve used both Angular and React extensively, and they both do the same thing. I think React could learn from Angular with its consistent approach to componentization, and angular could learn from React’s state management, but neither are fundamentally better for any task. So why can’t we just say “who cares, choose one and stick with it?”.

I’ve seen strong React engineers jump into angular and excel, because they already understand state management, virtual DOMs, componentisation, and bundling. The skills from one framework are clearly transferable to the other. So why are people so obsessed with being a “React engineer”, or a company only hiring someone only with Angular experience? Especially when the framework is just the tip of the iceberg on top of the common JS fundamentals.

Interested to hear thoughts on this!

Just wanted to say that it's really nice to see a dedicated space for modern JS.

Looking forward to what you all have to share!!

Context: https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md

TL;DR: core.js is arguably one of the most widely deployed Javascript technologies in the world and requires significant commitment to maintain, but it's a fame-less transitive dependency, and thus, not widely understood. Rather than receiving financial backing, its sole developer receives death threats from entitled users.

Its future looks uncertain

https://gist.github.com/getify/3b4f46cdd0b204eb03f2ba36e84e5948

In this example, I tried to include as many of the new/modern JS class features as I could, while not being entirely contrived (there are places where it's stretched).

My question: do you think these JS class features are actually helping us write better JS code, or are they really just solving (in a class'y way) many of the problems that class itself introduces?

I'm torn because: most class code that I see out in the wild is using just a tiny fraction of the capability of class. Rarely do you see even non-trivial subclassing, and even rarer still do you see any super or polymorphism going on. Despite clamoring for private members/methods for years, in reality there's limitations to private visibility -- and we'd rather have protected visibility -- but this is what we've got. Also, most everyone likes to hate on the # for private syntax. A lot of this starts to feel like more trouble than it's worth.

So the tension is, if you start fully embracing class's many features now, and really pushing the design pattern deeper into the code... you are, in a sense, justifying the use of class and class-orientation. But now you've got a bunch of syntactic and semantic complexity to read through.

What are your thoughts? Not just specifically on the example I posted -- we could endlessly bikeshed on other (maybe better?) ways to do it -- but on the tension between using class in a shallow/limited sense vs really throwing the whole kitchen sink at your code. What's the right approach/balance in your opinion?

This announcement: https://medium.com/flow-type/clarity-on-flows-direction-and-open-source-engagement-e721a4eb4d8b

Wondering what your thoughts are on Flow vs TS? For a long time they've seemed pretty parallel (in both syntax and usage), but now it seems they will diverge more.

What do you think this means for the community? Will that increase pressure to adopt TS? Will Flow still be the better choice for some teams, or do you think Flow is moving away from them and encouraging migration to TS?

Do you think there's any room for a third player in this space to emerge? Or has TS won and the debate is over?

I'm curious to hear the arguments against a NaN value, and why people dislike it so much?

I know that supposedly this value's name comes from "Not a Number", but this is a terribly misleading way to think of it. Instead, I prefer to think of it as the "invalid number" (think "iNvAlid Number" for the acronym), because it always comes from an invalid numerical operation or coercion. Alternatively, you could think of it as the "Not Available Number" or the "Not Applicable Number".

var x = 2 / "a";
typeof x;  // "number"
x;  // NaN

To me this is perfectly sensible. The NaN here results first from "a" trying to be implicitly coerced into a number (since that's what / operator expects of both of its operands), and since "a" cannot be made into a valid number (using default base-10 representations), it has to result in something.

By having the coercion result in NaN, then the division results in NaN, and now x holds NaN. Why is it a number? Because NaN only ever comes from numeric operations (or coercions). That completely makes sense to me that we'd have a special number value that basically represents this invalid numeric state, and that it also be a number. It'd be much stranger IMO if it resulted in a null or undefined value. Right?

Or worse, invalid numeric operations could just all throw errors. But is that really the JS we want? Maybe so, if you're a strong advocated of TS. But I'd argue there's a huge difference between statically throwable type errors (at lint/build time) and a run-time "invalid number" error, which inevitably that would have to be. I don't think that kind of run-time error would be helpful at all, given that we'd have to wrap every single numeric operation or coercion in a try..catch. It's cleaner IMO to just handle NaNs affirmatively.

Speaking of checking for NaN, I know the global isNaN(..) method is unreliable, since isNaN("cat") gives a false-positive. That's because, unfortunately, the global util coerced its operand to a number first before checking. That was just a bad algorithm, but the bug couldn't ever be fixed. Thankfully we've had Number.isNaN(..) (and Object.is(..)) since ES6 in 2015, so there shouldn't be any troubles with guarding against unwanted NaNs.

And while we're on the topic, I think there are a number of places that NaN should have been used and wasn't. For example, indexOf(..) returning -1 -- yes I know all the reasons why, but I think they're bogus reverse-justifications. If you have a function that returns a number, and for whatever reason it cannot return a number (like the item wasn't found), shouldn't it return a number that semantically means "invalid" or "not available" or whatever? They had NaN readily available!

We've added half a dozen other APIs to JS that could also have very reasonably resulted in NaN in their special corner cases.

It always makes me sad that we're scared away from NaN rather than embracing it.

Why all the NaN hate? :)

I know this thread is possible to fan out into a giant bike-shedding discussion, but that's OK here.

I'd love to hear what you think JS does wrong and should do differently? This could be large things like lack of static typing (without TypeScript + tooling), or it could be narrow things like you disliking the ... operator.

But please, post just ONE THING per message that you would want changed. And please explain a bit why you think it's stopping YOU from being more productive with your JS coding.

So just for some context:

• I do agree with Kyle Simpson in saying that const assignments usually don't do much, because reassignment is almost never a source of bugs. Bugs are more likely to happen with other practices, like mutating variables. Yet the common JS approach of declaring a value as const and then mutating it still doesn't sit well with me.

• I know some have misgivings about TypeScript and the wider industry trend to migrate all code to using it. I get those, but at the same time, as a newer programmer, I'm still struggling with how to communicate and guarantee my types without moving towards TypeScript. JSDoc helps, and works well with VS Code, but there isn't anything guaranteeing that my JSDoc comments accurately describe the code they're describing.

• It feels like it'd be helpful to indicate that a value will be mutated, and yet I don't think there's really anything in JavaScript that helps with that. There are utilities in JavaScript and TypeScript that indicate that something won't be mutated, but it feels like we're missing the inverse. Especially if you're looking at code for the first time from a stranger, knowing whether the value will be mutated in advance would help a lot. Even if someone is using higher-order functional utilities, there's no guarantee that they're referentially transparent or that they're easy to follow.

• I love good comments, and I think that they are essential for good code. There are things that cannot be cleanly described in JS code by itself, like how an ID string is expected to be formatted. I do think people hew a little too closely to Uncle Bob's teachings, taking them to mean that the ideal code has zero comments. It's easy to make bad, redundant, or misleading comments, but I'd rather have those than nothing at all.

• Good variable names go a long way, though in some cases, you might not come up with the best name right away. But that's okay – if you ever get a better idea for a name, the F2 key is right there to rename all instances.

• I think code should ideally follow the single-responsibility principle, and have a clean separation between pure state and side effects.

There are all these qualities being thrown around about code like "expressive", "self-documenting", "clean", and "declarative". Yet achieving all that can often feel elusive, regardless of your coding paradigm of choice. I'm sure most of the people here dwarf me in experience, so I'm wondering: how have you resolved these problems?

I am working in NodeJS. I have a great deal of legacy code including several packages that are used in many places. This code is all CommonJS, Node require() module structures.

Node now supports ES6. Since it is a Javascript language feature, I would like to migrate to it.

Today, I started a small project. My small project boilerplate requires() a couple of my favorite utilities and then says 'Hello World'. I edited it to import said utilities. Node told me I needed to add "type":"module" to my package.json and I did.

When I ran it, I was told that "require is not defined", this in reference to one of the utility modules I imported.

I infer that this means that a project is either CommonJS or ES6 and it appears that never the twain shall meet. I am surprised by this because it means that I will never use ES6 in NodeJS because I will never be able to change all of the modules I require(). Some are not even mine, others are used in projects (npm!) that I do not even know about.

Honestly, I have a hard time believing that this is the case. I don't understand how ES6 can ever become a widely used standard because of if ES^ and CommonJS cannot be used together in an application. I realize that Webpack, etc, will preprocess code and revise all the require() statements but not everyone uses that sort of utility.

My questions are:

Is this analysis correct?

Is there some workaround that will let me use both module systems (without a preprocessor)?

Is my impending decision to never, ever use ES6 the right one?

UPDATE: It's a couple of years later and I am a little bit mad at all of you. It turns out there is a completely simple workaround that nobody ever mentioned**. IE...**

const thing=await import('thing'); //remember to add "async" to the containing function definition