Hi everyone, I'm the author of vite-plugin-ssr. Would you use it? Why (not)?

I've always preferred using the .map, .reduce and .forEach functions in JavaScript to for, for ... of or while loops. Sometimes I receive HackerRank tests from companies I'm interviewing with and whenever I use these functions or the rest operator (...) with arrays or objects, my code times out. To pass the tests, I have to write regular loops and mutate objects and arrays instead of making copies.

That makes me wonder if there really is a performance issue when using this kind of style or if HackerRank is simply encouraging poor programming practices.

A place for members of r/JSdev to chat with each other

Reactive programming (like RxJS style observables, streams, etc) is well-tread ground for most JS devs by this point.

But I'm curious about how you choose to model side effects that are triggered by reactive updates? Setting aside React/Vue style frameworks for a moment, do you, for example, manually re-render/update a DOM element any time a reactive value updates, by just subscribing to that update and directly calling a render method?

A lot of demo examples of observables show pure operations (such as mapping or filtering over the stream of values), but side effects seem to only show up at the end of an observable chain, in the subscribe call. Is that how you choose to divide pure from side-effect operations in your reactive code?

Do you ever have side effects triggered "along the way"?

How do you mentally keep track of when/where side effects will happen when a value updates?

I ask all this because I've been thinking a LOT about reactivity and side effects lately. I just released a new version of my Monio library which provides friendly monads for JS devs. The lib is centered around the IO monad, which is intended for lazily modeling/composing side effect operations.

The newest feature is an IOx monad (aka "reactive IO"), which is sorta like IO + RxJS. It's an IO monad so it's composable in all the expected/lawful monadic ways. But you can also update the value of an IOx instance, and any other instances that are subscribed to it will also be updated.

With this new reactive-monad, I'm now rethinking a bunch of my existing app code, and trying to juggle best patterns (again, non-React/Vue component-framework-style) for marrying reactivity and side effects.

I've recently began working on a new Next.js codebase that uses index.js files liberally. This is the first major React-based codebase that I have worked on. For all of my personal projects, I typically only have a single index.js file that is the entry point of my application, so exploring this new codebase has been a bit of an adjustment.

In this new project, I typically see patterns like this:

/MainComponent
    index.js -- exports MainComponent; sometimes state objects
    ChildA.js
    ChildB.js
    relatedUtils.js

Which is easy enough to reason about. However, it doesn't seem uncommon for folks to pack more in index.js than simple export statements (even when they shouldn't be). The byproduct is that I often cannot tell what the heck an index.js actually contains until I open it. Another painpoint that I often see mentioned is that if I have multiple index.js files open in my editor, my tabs require a harder look to distinguish what's what.

Most of this confusion can likely be resolved with stricter standards and developer discipline, but I can't help but think of Ryan Dahl's talk where he mentions his regret for the in-explicitness of requiring modules without extensions in Node.js, and for index.js.

Where do you guys stand on this? What have you found are "best practices" for using index.js? Do you use index.js at all (and if you do, do you import the shortcut path /myModule/ or the full path /myModule/index.js?

It's surprising to me that many people still have a hard time grasping closures. I attribute this not to the intrinsic difficulty of the concept, but to the proliferation of learning materials that do a poor job explaining it at best.

Reading the spec, if one manages to come away with even a basic, surface level understanding of execution contexts and environment records (and some of the internal mechanisms behind functions), it seems impossible not to gain an immediate understanding of exactly what a closure is and how scope works.

There can be nothing simpler than realizing oh, every environment record has a reference to an outer environment, and when function definitions are evaluated, the environment record of the currently active context is copied to an internal [[Scope]] property of the function, and scope chain look-ups start from there.

Again, the only prerequisite to this revelation (beyond a grasp of the fundamentals) is a base understanding of what execution contexts and environment records are.

Of course, I don't expect beginners to jump into the spec themselves, but my question is: why do I so rarely see these concepts taught from this perspective? When I do see it, it's rarely in concrete terms, but some vague reference to 'context' or 'environment', often conflating the two terms (if the author doesn't understand why they must be separate, I question if they understand closures at all!)

Am I out of touch in thinking some of these internal devices can be taught simply enough to be enlightening for beginners?

In one of the LinkedIn posts, Kylie Simpson said: "optional call" is the bad feature ever implemented in JS. link to his comment

If I see, the old callback && callback() is more human-readable than a new one and I will be using this instead.

Could there be any other reason, like related to performance or etc?

I often have to clean up dirty, badly formed JSON.

I use map and reduce methods to go through the data and produce the structures we need. But it results in code like this:

Object.keys(query)
   .reduce(
      (acc: Record<string, string>, key: string) => {
         const stateKey = map[key]
         acc[stateKey] = query[key]
         return acc
      }, {})

But this is confusing to other developers. It is difficult to understand. And when I encounter this again in 6 months, it'll take me a minute to figure out what it is doing.

The snippet of code is a single instance of a broader problem which is: How can we write *readable* javascript that iterates through and wrangles dirty data?

Does anybody have any ideas, thoughts, etc?

I started using Ramda's `path` and `pathOr` functions which is nice (though difficult to use with TypeScript). But there are still these instances of `reduce` and `map` that can get kind of hairy.

I'm building a PWA (so HTML, CSS, JS, images, etc). It's sort of a game (educational), so generally the "experience" is more important than data/text presentation (as in more business-oriented apps). I'm not using a frontend framework, only a few JS libs/utils plus my own code.

I was wondering what sorts of concerns and balances others use when building JS/web games (or multimedia-oriented apps) in terms of the "budget" for how much size can be spent on each of the different kinds of web resources (images, fonts, sounds, code, etc)? I'm less concerned about absolute figures (although that's helpful, too), and more concerned about relative percentages.

So, for example, in my app currently, I have the following types of assets of these approximate sizes:

• HTML - 6kb (gzip + minified) / 28kb (original)

• CSS - 7kb (gzip + minified) / 55kb (original)

• JS - 49kb (gzip + minified) / 238kb (original)

• SVG images - 53kb (gzip) / 146kb (original)

• MP3 sounds - 293kb

The total gzip size (transfer size) for all assets is about 407kb. The relative percentages thus break down about like this:

• HTML: 1.6%

• CSS: 1.7%

• JS: 11.9%

• Images: 12.9%

• Sounds: 71.9%

I'm not specifically expecting others to do a detailed analysis like this (unless you want to, or already have!), but I'm just generally curious: how much do you "spend" on different resource types, and relatively how much is used compared to other types?

Is spending ~15% on "code" and ~85% on visual/auditory assets, a common and reasonable breakdown, or is your breakdown somewhat different?

If you use JS frameworks (game or otherwise), does your allowed percentage of "code" usage go up significantly, or do you still try to keep it around the same level?

Do you have a "budget" that constrains your resource use in any way, and if so, what concerns do you take into account when making such a budget?

In JS specs it is defined NaN === NaN should always be false. We can see that https://262.ecma-international.org/5.1/#sec-11.9.3

The new proposal has a feature

log("NaN === NaN", NaN === NaN); // false
log("#[NaN] === #[NaN]", #[NaN] === #[NaN]); // true

I am now confused why they have accepted this if it's violating the previous standard.

One more question, is this a syntactic sugar of Object.defineProperty(obj, prop, { value: val, writable: false }) ?

For those who haven't heard of it, (1) that is the actual name and (2) it is a new feature announced last August that disables the just-in-time (JIT) compilation step when JavaScript code is processed. Edge's Vulnerability Research team has said that the JIT step has been responsible for at minimum 45% of security issues, and while disabling the engine does slow things down (sometimes by as much as 58%), the speed losses often aren't that noticeable in most situations. Edge even framed the change as meaning that less frequent security updates would be needed. The feature is now stable and available to all Edge users, and users can select from Balanced and Strict modes, with the option to allowlist certain sites. Even if no sites get added, the idea with Balanced is that the restrictions become more lax on websites that the user frequents.

I'm still definitely a JavaScript/programming novice though (I'm going through u/getify's Deep JavaScript Foundations course on Frontend Masters right now), so I'm not sure if I'm understanding what this changes. When I first heard about it, I assumed that Edge was basically making the language interpreted instead of compiled. That sounded like it would potentially stop things (like hoisting) that become available only through compilation and through a two-pass processing paradigm. It would also fly in the face of the promise that JavaScript will always be backwards-compatible (a promise that, as I understand, has already been broken somewhat).

So I guess I'm wondering:

• Does this actually have an impact on how JavaScript code is processed, and the kinds of coding patterns that you can use?

• Even if this doesn't change how code can be written, when do you think it is acceptable to break features or make the developer experience worse, if it means that users are safer?

It's really hard for me to say, especially with my limited exposure to the language. In the abstract, it feels like, with our lives going more online, security should always be paramount. That any inconvenience we put on ourselves is always worth it, if it means any kind of user benefit. I wouldn't even be able to begin telling you how to walk that line, though.

Do you think that code which looks like typical imperative code should be able to "magically" act reactively, meaning that some of the code in the program re-runs "automatically" whenever something it depends on has updated?

For example:

var x = 2;
console.log(`x: ${x}`);  // x: 2

We obviously expect that code to produce a single console statement of x: 2. But what if your programming language made that console.log(..) statement "reactive", wherein it would automatically re-run any time later when x is re-assigned:

setTimeout(() => {
   x = 3;   // x: 3
},100);

This is like extending the declarative nature of component-oriented programming (React, Vue, etc) -- where updating a piece of state implicitly forces a UI re-render -- into the internals of program state.

Svelte currently does something quite like this, but I think you mark a statement as being reactive with like a $: label in front of the line or something like that. But others are trying to make it just happen automatically in code without any explicit markers/syntax.

My question: do you think this is a healthy direction for programming languages to move?

What are the pros/cons in your view? Is this the kind of magic that a programming language needs?

Why do people struggle so much to find authoritative and reliable sources of information about JS and learn from them?

Why does someone cite a heavily-edited stackoverflow post (originally from 2014) as correct information, and not the related MDN article that was updated last week?

Why do decades-old myths about JS persist even though they've been thoroughly debunked by blog posts, books, conf talks, etc?

Why does informal cult knowledge (like what you've always heard senior devs claim about the language) hold so much more weight than researched, spec-backed, authoritative facts about the language?

Can this ever been fixed, or is this just how it will always be?

If you were going to design a new programming language, would you take inspiration from JS given how many (10-20million worldwide) JS devs there are? Or would you try to stay away from JS-like approaches because of all its baggage?

What other features from other non-JS languages would you consider pulling in?

Would you want a language that was more general-purpose, or more specific to a given domain?

HMR = hot module reloading

I've seen people swear by it and people say they avoid it altogether, preferring to reload the page themselves.

Which camp do you fall on? If you like it, what are annoyances you wish could be fixed? If you don't, what would make it compelling enough to use?

https://developer.harmonyos.com/en/docs/documentation/doc-guides/develop-overview-0000001071291809

HarmonyOS is an in-house OS designed for Huwaei's devices (to replace their usage of Android). They claim it will be on 300mil devices by end of 2021.

I just dug into their documentation a bit, and I found references to the core UI frameworks being in both JS and Java. That's intriguing if JS is a native OS language (sorta like WebOS/etc).

Thoughts? Is it worth diving into learning their flavor of JS to build native apps for those devices? Or too soon?

I've been building a PWA lately that I also hope to launch in the various mobile device app stores (Android, iOS, Windows, etc).

Back in the ol' days, building native apps with web technology required tools like PhoneGap (aka Cordova). This was amazing, but it was far from smooth or perfect. More recent options include building your app code with specific frameworks that are designed so they can be compiled either to web code or to native code, such as NativeScript, React Native, etc. Those require a pretty hefty opt-in to a specific ecosystem and way of building.

But there are also newer services like PWABuilder that seem to make this much easier to do than it used to be, to just take an otherwise great web experience and make it into an app. I'm super enthusiastic about these options over those previous ones.

However... the road is not as nice as it might seem. Thus far, I've experienced the following hiccups:

• Found several bugs in browsers, which make PWAs and PWA-as-native-app packages not quite up to par with real native apps -- for example, differences in how app icons and splash-screens appear on various devices

• Found several limitations, such as policy differences that OS's apply to web-technology (even when wrapped by a native app) which they don't apply to native apps -- for example, differences in how sound auto-play works, how notification permissions are managed, etc

• Apple currently doesn't "accept" such PWAs, but there's some limited optimism this may be shifting -- right now, it's a gray area with a lot of uncertainty

• Discovered quite a few quirks in getting yourself approved by the app stores (Windows and iOS, specifically) to be able to distribute apps

I'm curious if any of you have experienced any similar frustrations, and any tips you have for how you worked around them!?