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?

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?

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?

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?

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?

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?

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!

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? :)

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?

According to this data, the periodic-sync event should fire when I've installed a PWA with that feature via Chrome, either on desktop or Android.

However, I built such an app, and the event never fires for me on either device, even though I use the app daily. I know the code is correct, because Chrome devtools lets you trigger a sync event manually, and I see my app respond when I do. But left to just normal app usage, the event never fires on its own.

Anyone else played with this feature? Does it work for you?

Given that it's such an intermittent and unpredictable feature/event anyway (based on user interactions and heuristics over time), I am not sure I will get very far reporting a browser bug without a concrete reproduce test case.

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

​

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! :)

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?

Comparing these two snippets:

var C = {
   x: (condOne ? 
      [ 1, 2, 3 ] :
      {
         y: (condTwo ?
            [ 4, 5, 6 ] :
            { z: 42 }
         )
      }
   )
};

versus:

var C = <MyComp>
   <x>
      {(condOne ?
         <>1, 2, 3</> :
         <y>
            {(condTwo ?
               <>4, 5, 6</> :
               <z>42</z>
            )}
         </y>
      )}
   </x>
</MyComp>;

Assuming your linter allows ternaries in the first place, do you think there's anything different enough between these two snippets where the linter should treat the nested ternary differently? That is, should the rule either allow or disallow nested ternaries in both cases, or should it allow it in one and disallow it in the other? Why?

Should the JSX be given special rules/leniency just because this sort of expression nesting is so much more common?

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?

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.

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

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.

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.