Champions of Norrath has ruined every single isometric RPG for me.

Baldur’s Gate 3 is meh to me. I acknowledge it’s technical, narrative, and gameplay achievements. I can’t get into it.

My backstory was the game is good and gameplay is immediately in your control. No rolling of dice, no pauses between moves. Just loot, aim, and kill. Hack/slash at its finest.

Yeah, I have my own stuff that lets me do MSSQL, DynamoDB, REST/HATEAOS, regular Hash Maps, and some obscure databases (FilePro).

I throw them in a tree structure and perform depth-first searches for resources. Some of them have stuff for change data capture streaming as well, (eg: SQLNotifications, DynamoDB Stream, WebSockets).

DynamoDB was a rough one to optimize because I have to code to pick the best index. You don’t do that with SQL.

The code on backend is the same as frontend, but a different tree. Frontend queries against REST and a cache layer. Backend queries against anything, REST included.

SSR is a overloaded term.

• There’s SSR to help improve FCP (first contentful paint). This is not really so much an improvement to the client side framework as it is a crutch to workaround the fact that the frameworks are dynamically constructed clientside. But the first paint would just be Root node which is essentially empty. Because React and Vue are so heavily tied to the DOM structure, it expects to be the compositor of the tree, not something written in HTML. For pure HTML to be the compositor, you would need to add some rehydration to React/Vue to take a pre-composed state and reintegrate it into what React expects.

• SSR is also used to dynamically build content that is presented to the user that is not necessarily tied to rendering. This is popular with PHP, where instead of putting a blank table and then having the client fetch content over JS and then populate that table, the server just hands you the precompiled HTML. Not all the data as sent over JS may be useful (eg: only 10% is used after filtering and pagination), so to save transfer size and query latency, it may be the server that gets the always data from the store or cache. There’s less client JS in execution, which may also help in performance.

• Then there’s SSR for the purpose of improving SEO. This relates more to the first point, but maybe the first paint isn’t important. Maybe client-side construction is plenty fast. But because the root is just blank, search engines that don’t perform synchronous JavaScript can’t actually read the content being shown to the user after all the rendering is said and done.

Personally, I’ve moved to Web Components that solves almost all of this. You can author layouts in HTML and anything that you want in your HTML file for SEO is included in the source. I would only use SSR to target the second issue, where you want to save on trips to build dynamic content. It is somewhat wasteful to give clients instructions to fetch and render when the server can do that on the first trip. The issue is rehydrating, or picking up from that state, but that truly depends on how complex your Web Components are. If they are sparse and simple enough, then all states should be able to be expressed over attributes. First paint can be reduced with the template shadow root, but I feel it’s more trouble then it’s worth and has negligible performance gains compared to just doing a prerender JS to register components and the browser will only render synchronously what’s in the viewport anyway. That means time to first paint is not dependent of how big your page is. It’s only dependent on how many elements you want to register before DOMContentLoaded.

From a financial aspect, I’m not about to ditch static CDNs to reinterpret nearly every single request with some server for SSR. The costs are nowhere near the same to try to reinterpret with SSR. You can micro-optimize to death with a SSR to CDN route and then hydrate, but I feel you risk complicating deployments to where you’re so vendor-locked you have extra hoops to jump to make changes. God forbid you want to change frontend systems. At that point the DX pain is too much to justify and wanting to get out is inevitable.

You wrote:

To mitigate problems caused by DRY fundamentalisms, the “write everything twice” (WET) principle was coined.

I’m listing when and how it was coined with the article that coined it. If you have another source to claim it wasn’t in the fashion I’ve described feel free to provide sources to the contrary. I even sources it from the very Wikipedia entry you shared.

WET is a clear guideline

Again, feel free to provide sources to back up your claim.

Your comment sounds like a weak attempt at revisionism.

Again. Feel free to back up your claims with actual sources. The concept of AHA by Kent C Dobbs, of Angular fame says:

There’s another concept that people have referred to as WET programming which stands for “Write Everything Twice.” That’s similarly dogmatic and over prescriptive. Conlin Durbin has defined this as […]

https://kentcdodds.com/blog/aha-programming

He then goes on to link to the article/blog I mentioned where Durbin states:

Instead, I propose WET programming.

And he goes on to explain this new concept of Write Everything Twice.

If you actually interested in discussion about the debate of DRY/WET/AHA, I’m all for it. But don’t misinterpret or try to change what is already well-written.

Also, don’t throw accusations at people who provide you documentation and proof and then contest while providing absolutely none yourself. That doesn’t sound like any earnest interest in discussion.

WET is not what you think it is, or at least not originally. It’s not some alternative to DRY. It didn’t stand for Write Everything Twice. It stands for Write Every Time. It’s supposed to be a negative way to describe code that isn’t DRY. It’s also abbreviated as “Waste Everyone’s Time”.

Much, much, much later somebody tried to reuse the term for “Write Everything Twice” but talking specifically about the benefits of singular, repeated templating because the abstraction needed to refactor code into “Write-Once” can make things harder to understand. In other words, it creates a chain of pre-required knowledge of how the abstraction works well before you can even work with it.

The irony here is that DRY is not really about code duplication. It’s actually about system knowledge (structures and processes) being clear and unambiguous. Or, applied, you, as a person, not having to repeat yourself when it comes to sharing knowledge. It lends to simpler constructs that don’t need much explanation. The example given of Write Everything Twice is actually being DRY, but they don’t realize it.

Bill Venners: What’s the DRY principle?

Dave Thomas: Don’t Repeat Yourself (or DRY) is probably one of the most misunderstood parts of the book.

Bill Venners: How is DRY misunderstood and what is the correct way to understand it?

Dave Thomas: Most people take DRY to mean you shouldn’t duplicate code. That’s not its intention. The idea behind DRY is far grander than that.

DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system’s knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

https://www.artima.com/articles/orthogonality-and-the-dry-principle

The article/interview explains more about how DRY is meant to work and even talks about the pitfalls of code generators, which the WET article complains about (React).

The misunderstanding since DRY’s coining is probably because, like natural language, we change meanings we with our environment. DRY became a term people use to blast too much abstraction. But noisy abstractions are not DRY. In response we have a new term card AHA (Avoid Hasty Abstractions), which exists as a counter to what people think DRY is.

The TL;DR is DRY is meant to mean your code should be unambiguous, not some sort of mantra to deduplify your code. Apply its original principles, and follow AHA which should be a clearer safeguard to avoid your abstractions not following DRY.

I think it’s the junior dev blog spam and search results putting them higher.

People who fail to understand the value of peer-reviewed code are just going to copy/paste bad, but popular, code practices.

There irony here is that Stackoverflow was considered a common source of copy/pasted code.

You can use SharedArrayBuffer but honestly it feels like something engineered for one specific purpose (OpenGL).

It would be nice to have shared objects and strings with whatever syntax helps sync locks. You can technically use UTF8 with helpers like TextDecoder, and I could probably sit and write all that logic using Promises, but I’d imagine the amount of data conversion to make it happen would negate the performance gains from multithreading in the first place.

I used to not like JavaScript when I started, having done C# and Java for about a decade before moving.

But I feel differently now, having spent about a decade with it and having better tools (VSCode, Typescript, eslint). I code in JS, and use JSDocs whenever Typescript’s automatic type detection needs help (no-implicit-any).

The 2015 changes brought a paradigm shift to write more expressive/declarative code and it’s continued from there. async/await is much easier than the Future<T> in Java. Tree-shaking of imports is great at reducing code bundling size. Classes are also optional, not mandatory which helps simplify code (functions vs methods).

But for the nerdy stuff, I like I can still pass around functions as objects, something that harder to do in C# (delegates). It makes building functions more versatile dealing with arguments, so I can pass a string|number|function|Promise to one function and write more expressively httpPost(variableContent).

Not perfect though. The prototype system is powerful if you learn it, but definitely confusing. Multithreading is basically non-existent in usage since you have to essentially convert a function to string (serialize) or script threads into their own file.

I heard python is better for beginners, but I grew up on C style and needs my braces over indents.

Classes are very great for their intended use case: the classification of objects.

It’s very useful to combine a group of functions that only exist, and can only exist, in conjunction with another object. You also have the ability to take a type and morph it, allowing that one type to have large effects on everything that comes after it. But it has to be intentional. For example, a Button can be split and become an IconButton, or a ToggleButton, etc. It is a double-edged sword, since you can over complicate things when you don’t need inheritance.

Many people make the mistake of throwing functions everywhere, but don’t see the chain they create. For example: createFoo() will create an object. Then they’ll make another function, or a set of functions, that can only work the result of that function. You essentially made a broken apart class. I saw this recently in lit. Their render function returns TemplateResult. Then they have a bunch of functions that only accept TemplateResult as input. That can be rebuilt as a class and have those functions part of the class. Breaking them up instead of using a class isn’t necessary. It becomes extra weight to lug that result around instead of having the functions bound to it with this.

There is a good solid excuse for this practice, but it’s not a logical one, but an unfortunate consequence of our build tools. Tree-shaking loose functions is much easily done than a class. Because class functions can be invoked by name, it becomes nearly impossible to tree-shake.

People also, sometimes, confuse declarative syntax with functional programming. You can take a class, and use it declaratively, if you build out some helper functions. For example, take a look at [https://github.com/clshortfuse/materialdesignweb/blob/ec892c6f646ea7155edd8f7579389b27d02aa2fb/components/Button.js](this code). It’s still a class, that allows extensions, inheritance, function grouping, and construction, but you can manipulate it via a declarative syntax.

That’s one of the reasons classes in JavaScript get a bad rap. It’s structure is somewhat sporadic and can be hard to follow. But that’s a syntax issue, not a construct issue.

That said you should strive to use both functions and classes. If you can simplify your functions to allow mostly any primitive input, that’s great. It can be reused many times throughout your code. But if you have certain operations that only work with one type, then don’t be afraid to use a class.