7 ms·

Patterns.dev

627 points by handfuloflight 11mo ago

1970-01-01 11mo ago
Thanks, I was looking for something just like this today!
HumanOstrich 11mo ago
I was glancing around and landed on the page for the flyweight pattern.[1] It looks like `addBook` is using the spread operator, which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern. It also attaches extra arbitrary properties, but still assigns the result to a `book` variable. I don't think this is a great example. [1]: https://www.patterns.dev/vanilla/flyweight-pattern/ https://www.patterns.dev/vanilla/flyweight-pattern/ Edit: I forgot to give you kudos for all the effort it must have taken to create all this content, and I appreciate that you're making it available for free.
- KPGv2 11mo ago
  > which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern No, the opposite: it highlights the benefits of the flyweight pattern. The shallow copy saves memory. That's the point. You have two identical books. Rather than wasting memory with a deep copy, you make a shallow copy, where all your props point to locations in memory where values are located, and then you modify whatever is different. Now your shallow copy only consumes a small bit of extra memory. And if those props are all primitives, then you can then modify that shallow copy, and it won't affect the original.
  - HumanOstrich 11mo ago
    The point is to not make a copy at all for the shared data of the same book. That's even what the page claims is happening (but it's wrong). That's the whole point of the flyweight pattern[1]. Instead, the example returns the same book instance for the same isbn in `createBook`, then blindly copies the shared data like title, author, and isbn every time in `addBook` to a new object. > The shallow copy saves memory.... Versus not making a copy? A shallow copy of primitives still copies them and uses additional memory. Maybe there's some low-level optimization that makes it more efficient than that, but it's not relevant here. And there isn't any deep cloning happening in the example. Might as well get rid of the complexity and instantiate a new Book class every time. And maybe stop shallow-copying class instances into new plain objects. It works for the example but has footguns. Conveniently, there are other patterns on the site that would help you avoid creating an amalgamation of random merged class instances and objects. The whole example is a mess. [1]: https://en.wikipedia.org/wiki/Flyweight_pattern https://en.wikipedia.org/wiki/Flyweight_pattern
- songodongo 11mo ago
  Good to know I wasn’t the only one thinking “wait a second…” when reading that one and seeing the spread operator being used.
seabass 11mo ago
Love this! Just wanted to note that I think there’s a mistake on the flyweight pattern page’s example. You’re using getting a boolean with Set.has but treating it like a Book (as if you had used Set.get). I also don’t really understand how this saves memory if you’re spreading the result into a new object, but maybe someone here can enlighten me!
- seabass 11mo ago
  Ah I think I understand now. The return type of createBook is true | Book, which is likely a mistake, but happens to work because when you attempt to spread a boolean into an object it removes itself. But if you were to edit the example to have a stable return type of Book then it would no longer save memory, so perhaps that was intentional?
8cvor6j844qw_d6 11mo ago
Looks great, time to add it to my bookmarks. Anyone has other sites like these to share? - Domain-driven design, design patterns, and antipatterns https://deviq.com/ https://deviq.com/ - Refactoring and Design Patterns https://refactoring.guru/ https://refactoring.guru/ - Standard Patterns in Choice-Based Games https://heterogenoustasks.wordpress.com/2015/01/26/standard-patterns-in-choice-based-games/ https://heterogenoustasks.wordpress.com/2015/01/26/standard-...
- begueradj 11mo ago
  Useful links. Thank you.
- rambleraptor 11mo ago
  I’ll make a plug for aep.dev, which is a collection of API design best practices and assorted tooling
  - JimDabell 11mo ago
    Google has something similar: https://google.aip.dev https://google.aip.dev
    - rambleraptor 11mo ago
      AEP began its life as a fork of AIP! We’ve got a bunch of ex-Google folks on the project, including the former API Lead at Google.
- sdovan1 11mo ago
  - Java Design Patterns https://java-design-patterns.com/ https://java-design-patterns.com/
  - vips7L 11mo ago
    Love how you were downvoted for mentioning Java.
android521 11mo ago
The ones that actually match POSD (deep modules, small interfaces, lower complexity) and work great with plain functions are: Module Pattern Factory Pattern (factory functions) Mediator / Middleware Pattern (as function pipelines) Hooks Pattern (custom hooks, generalized) Container / Presentational Pattern (implemented with function components + hooks) Everything else is either neutral, UI-only, or fights POSD (Singleton, Mixin, etc.). Patterns from that page you should treat skeptically for POSD From Patterns.dev, for your POSD-style codebase I’d avoid or downplay: Singleton Pattern → encourages global state and tight coupling. Patterns Mixin Pattern → tends to increase interface surface and make dependencies opaque. Patterns Observer Pattern → powerful, but event-based wiring can obscure data flow and increase “system complexity” (classic POSD warning). Patterns
- neogodless 11mo ago
  What does POSD stand for?
  - culi 11mo ago
    I'm assuming Philosophy of Software Design but I've never seen anyone blatantly presume it's an implicit initialism
  - jakubmazanec 11mo ago
    I'm assuming John Ousterhout's book A Philosophy of Software Design [1], which I would recommend reading before reading about design patterns, because it's more fundamental. [1] https://news.ycombinator.com/item?id=37975558 https://news.ycombinator.com/item?id=37975558
deleted 11mo ago
[deleted]
vivzkestrel 11mo ago
fantastic resource! kindly add svelte design patterns too and sveltekit if you can
nl 11mo ago
Does anyone remember the Yahoo design patterns library? It was mostly for UX pattern (eg: ways to "Rate an object") and it was really good. Almost 20 years ago.. damn. https://creativecommons.org/2006/02/14/yahoodesignpatternlibrary/ https://creativecommons.org/2006/02/14/yahoodesignpatternlib... https://web.archive.org/web/20060221111812/http://developer.yahoo.net/ypatterns/index.php https://web.archive.org/web/20060221111812/http://developer.... They had a great comparison of the different behaviors leaderboards could encourage in users.
- 101008 11mo ago
  Oh, the second link is amazing. I love the old web, and that brought a lot of nostalgia.
- culi 11mo ago
  Not quite the same thing, but there's this incredible (open source) project called The Component Gallery that is basically just a repository of UI components across 93 (currently) different design systems. It's an incredible resource if you're building a component from scratch and either want some design inspo or technical advice. Many of the design systems have thorough guidelines for a11y/ARIA best practices that I've learned a ton from https://component.gallery/ https://component.gallery/
- paulirish 11mo ago
  Amen! The terms "accordion" and "carousel" were really codified by the pattern library. Establishing a common vernacular definitely accelerates things.
- no_wizard 11mo ago
  YUI was ahead of its time as well
  - deleted 11mo ago
    [deleted]
  - cachius 11mo ago
    And it spawned ExtJS. Which could have been React, but they messed up. Literally they built a faster Facebook app 'Fastbook' in 2012. Short history lesson: https://medium.com/hackernoon/the-rise-and-fall-of-ext-js-c9d727131991 https://medium.com/hackernoon/the-rise-and-fall-of-ext-js-c9... In August 2006, a guy by the name of Jack Slocum (now CEO of Alta5) began to blog of his experiments with YUI. Over time, these experiments became more complex and Jack would start to bundle them into what would later be named YUI-ext (Yahoo UI extensions) — the precursor to Ext JS (Extensible JavaScript). Jack Slocum’s blog was used to communicate his vision for YUI-ext and garnered community support from around the world. The release of the Grid component for YUI-ext would forever change the trajectory of the library and the community as the GridPanel would become the core UI component for many applications to come. Throughout its early life, Jack continued to build upon YUI-ext by adding features to the framework, such as animations, Modals, Tab Panel, Resizable elements and a layout manager that greatly expanded upon the YUI framework. These components would seldom extend the YUI library and had their own rendering functions. YUI-ext created a foundation for web programmers unlike anything the world had seen before and many developers flocked to the framework and invested in the newly formed community. The net result was the explosive expansion of YUI-ext. From YUI-ext to Ext JS In January 2007 we found Jack extremely busy to push out YUI-ext 0.40 and it is this version where we find the namespace of the framework change from YAHOO.ext to a much simpler Ext (pronounced “ekst J S” or “E-X-T J S” by some of us old-school community members). February 2007, Ext JS 1.0 was being developed in tandem with a new website, ExtJS.com. In April 2007, the launch of ExtJS.com was announced to the community along with the release of Ext JS 1.0. https://web.archive.org/web/20230222210535/https://jackslocum.com/the-rise-and-fall-of-ext-js-a-long-overdue-reply-and-apology-65ec5c1afda0?gi=af7e9452f5e5 https://web.archive.org/web/20230222210535/https://jackslocu... For those that don’t know, Ext JS was one of the first JavaScript frameworks in the early days of Web 2.0. It was the first framework to offer a complete package of everything needed to build full-fledged applications using just JavaScript in a web browser. At one point, it was used by over 2 million developers worldwide, 70% of the fortune 500, and 8 of the top 10 financial institutions. It was years ahead of everyone else, open source, and had an incredible community of passionate people contributing to its success. As that success grew, so did the number of copycat competitors. They eventually started taking the code and assets and embedding them into their own frameworks. Adobe embedded it in Cold Fusion and other competitive frameworks followed their lead without any contribution to the framework or community. At the time the thought of competing directly against a behemoth like Adobe was scary. How could they take our product and offer it as their own? I took what I thought was the right action to “protect” Ext JS from being “stolen” by changing to a more restrictive license. That was a huge mistake. Looking back in hindsight, without the fear, I have a much clearer picture. I see what truly made Ext JS great was not the code - it was all the people who loved, contributed and supported it. As we worked on making our own dreams a reality, we helped others do the same, sharing our knowledge, code, and solving tough challenges together. That is what really mattered — our community. That is what I should have protected, not the code. You were my closest friends. I am sorry I changed the license after we all came to an agreement on the first license. That was a breach of integrity and you deserved better. I would do it differently if I could.
fiddlerwoaroof 11mo ago
I wish people would stop promoting the singleton pattern: in almost every case I’ve seen, singletons are unnecessary tech debt and solve a problem that’s better solved with some form of dependency injection (and I don’t mean the XML/YAML monstrosities various frameworks force on you but rather constructor arguments or factory functions)
- HumanOstrich 11mo ago
  The site is not "promoting" the singleton pattern. In fact, there is a "Tradeoffs"[1] section that calls it an anti-pattern in JavaScript. In spite of that, there are plenty of reasonable use cases for singletons in many languages, including JavaScript. For example, ES Modules are effectively singletons. If you import the same module in multiple places, it only gets evaluated once. Let's not turn the singleton pattern into forbidden knowledge. [1]: https://www.patterns.dev/vanilla/singleton-pattern/#tradeoffs https://www.patterns.dev/vanilla/singleton-pattern/#tradeoff...
- deaux 11mo ago
  Why pose DI as replacing singletons when they're used together all the time? Injecting dependencies to create a singleton repository or service class, which is shared across requests.
- hokumguru 11mo ago
  Off the top of my head, rails (currentattributes), Laravel (facades) especially, and most iOS apps use singletons quite well. It’s all in moderation and depends highly on how it’s used, much like every other design pattern. I think people just don’t like Singletons because they’ve been especially misused in the past but I guarantee the same argument stands for any other design pattern.
- dkersten 11mo ago
  Singletons are globals and should be treated the same as every other global (that is, used sparingly and with care). Worse is that singletons enfurece a single instance which is almost always unnecessary. It’s trivial to only create as many instances as you need.
- 11mo ago
wavemode 11mo ago
Great site! I tend to advocate for people to study design patterns. Not for the purpose that you will necessarily ever use most (or even any) of these exact patterns in your software, but just that you've strengthened your mental muscle for software design in general. I encounter lots of engineers who simply aren't able to think "outside the box" when building something new.
- lock1 11mo ago
  I always wondered if people actually find it beneficial to follow these "design patterns" or not. Personally, I prefer to learn FP patterns, which tend to be backed with nice mathematical properties behind them.
noveltyaccount 11mo ago
In my senior year of college two decades ago, I needed one or two credit hours to finish up, and I signed up for a once per week software patents (as in, intellectual property, I thought) course. It turned out to be a patterns course taught by none other than Ralph Johnson and the text was his famous Gang of Four Design Patterns book. Happy accident, it turned out to be among the most professionally useful courses I ever took. https://en.wikipedia.org/wiki/Ralph_Johnson_(computer_scientist) https://en.wikipedia.org/wiki/Ralph_Johnson_(computer_scient...
deleted 11mo ago
[deleted]
phplovesong 11mo ago
When overused these kind of "patterns" always lead to slow and hard to grasp code that is a nightmare to maintain.
- z3t4 11mo ago
  My experience is that they are best discovered independently as a way to abstract code, and let them come naturally to solve a problem. So for most things in Dev, if you do something prematurely you might end up with a good solution for a non existing problem.
  - oleggromov 11mo ago
    Or, even more likely, a bad solution for a non-existent problem.
- FieryMechanic 11mo ago
  Like many things they shine when use appropriately.
akst 11mo ago
A singleton for me is just making sure you define a single instance of something at the entry point of your app and passing it down via constructor arguments, which is normally what I do. I understand you can override modules in tests, and if you have a version of your app that runs in a different environment where you might replace a HTTP service with a different variant (like if an RPC service that normally performs HTTP requests, but in one case maybe you want to talk to specific process, worker or window using message passing). I really really feel using constructor args is just a lot simpler in most cases. But I think there's a reason why people don't always do this: 1. Sometimes someone is using a framework that imposes a high level of inversion of control where you don't get to control how your dependencies are initialised. 2. (this was me when I was much younger) Someone dogmatically avoided using classes and thought they could get away with just data and functions, and then they realise there is some value in some shared instance of something and then they just undermine any functional purity. Don't get me wrong, functional purity is great, but there are parts of your apps that just aren't going to be functionally pure. And you don't need to go full OOP when you use classes. ---------------------------------------- Here are some examples of what I mean. Here's one example, where I have an app defined in web components and I define the components for each part of the app before passing them into the skeleton. It's a more simple app and I avoid some shared state by different landmark components communicating by events. https://github.com/AKST/analysis-notebook/blob/b3f082fc63c9bdf39d00be9bbf99d70a735a3a14/index.js#L35-L40 https://github.com/AKST/analysis-notebook/blob/b3f082fc63c9b... ---------------------------------------- Here's another example, this app is built of multiple command line instructions that sometimes have their own version of services (singletons) with specific configuration, sometimes they are initialised in child processes. https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69a587892d285fd34c3aa0b11f712/lib/tasks/gis/stage_api_data.py#L156-L170 https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69... Because this app is doing a lot of scrapeing and I wanted to also child worker processes to do their own HTTP I was going to make a variant of my HTTP service which talked to a daemon process that tracked state for open connections to specific domains to avoid opening too many simultaneously and getting blocked by that host. Updating the code that uses HTTP will be effortless, because it will continue to conform to the same API. I know this because I've already done this multiple times with HTTP scrapping in the app. https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69a587892d285fd34c3aa0b11f712/lib/tasks/gis/stage_api_data.py#L90-L103 https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69...
Simplita 11mo ago
This resource aged surprisingly well. Still one of the clearest ways to understand common frontend patterns.
crabmusket 11mo ago
This is a nicely laid out collection of tutorials, but I'm sad that collections like this have drifted away from the very deliberate structure that A Pattern Language introduced. While patterns weren't invented by Alexander and co, they did inspire a lot of what we see in tech these days, inherited via design patterns etc. In A Pattern Language, each pattern is hyperlinked to other patterns in a kind of hierarchy, where larger patterns (like "house cluster") are broken down into smaller constituent parts ("main entrance") all the way to quite granular details ("low doorway"). This is because you can't just take a pattern on its own; it forms part of a larger whole. Tech pattern books often focus on small recurring structures (e.g. "command pattern" from this site), but not how they help create some larger pattern, or in the other direction, what are the smaller patterns that help create them. This sounds like a lot of hard work of course, which is why people don't do it.* I would love to see this accomplished though. If only I had an extra 36 hours in each day. One thing that A Pattern Language is also great at is motivating each pattern with a specific problem or symptom. This site seems to do a decent job at that, though some problems seem... kind of weakly motivated. For example, the above mentioned "command pattern" is motivated by "what if we need to rename a method?" which... is pretty weak tbh. *EDIT: also because fitting patterns into a whole, maybe unavoidably, will promote a perspective, or a way of building a whole system. A pattern book for web applications written from an HTMX point of view would be a very different book to one written from a React slant. Maybe one pattern language can accommodate both sets of technologies, or maybe not.
- crabmusket 11mo ago
  Here's an excerpt from APL showing what I mean about the connections to the other patterns. This isn't the whole pattern, there's a lot between the problem statement and summary. Annotations in brackets are mine. --- Short Passages (132) [Context, or pre-links] The Flow Through Rooms (131) describes the generosity of light and movement in the way that rooms connect to one another and recommends against the use of passages. But when there has to be a passage in an office or a house and when it is too small to be a Building Thoroughfare (101), it must be treated very specially, as if it were itself a room. This pattern gives the character of these smallest passages, and so completes the circulation system laid down by Circulation Realms (98) and Building Thoroughfare (101) and The Flow Through Rooms (131). [Problem statement] Long, sterile corridors set the scene for everything bad about modern architecture. In fact, the ugly long repetitive corridors of the machine age have so far infected the word "corridor" that it is hard to imagine that a corridor could ever be a place of beauty, a moment in your passage from room to room, which means as much as all the moments you spend in the rooms themselves. [Pattern contents here] [Pattern summary] Keep passages short. Make them as much like rooms as possible, with carpets or wood on the floor, furniture, bookshelves, beautiful windows. Make them generous in shape, and always give them plenty of light; the best corridors and passages of all are those which have windows along an entire wall. [Elaboration, or post-links] Put in windows, bookshelves, and furnishings to make them as much like actual rooms as possible, with alcoves, seats along the edge - Light on Two Sides of Every Room (159), Alcoves (179), Window Place (180), Thick Walls (197), Closets Between Rooms (198); open up the long side into the garden or out onto balconies - Outdoor Room (163), Gallery Surround (166), Low Sill (222). Make interior windows between the passage and the rooms which open off it - Interior Windows(194), Solid Doors With Glass(237). And finally, for the shape of the passages, in detail, start with The Shape of Indoor Space (191)
socketcluster 11mo ago
I find that the more senior you become, the less you rely on software design patterns. Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more complexity than they would have created had they not used design patterns. There are situations where design patterns may be useful but they're much more rare than most people think. A lot of juniors seem to think that every problem requires them to apply a design pattern from their toolbox. They try to frame every problem within the constraints of design patterns that they know. This can create problems. In fact, there are many coding patterns which are far simpler than 'design patterns' and much more useful, but nobody talks about them because they're too trivial to discuss. For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I use it literally ALL the time. The idea of storing intermediate state in some kind of HashMap is a game-changer IMO but there's no name for that pattern of coding. In general, knowing what data structure is most appropriate for various scenarios is a game changer... But still, don't abuse. Basic data structures like arrays are fine most of the time. Anyway, it's good to absorb the wisdom behind some design patterns but you should not try to fit every problem to them and dont say stuff like "For this problem, I applied Design Pattern X" - If you do, senior engineers will know you're a junior. If you use a design pattern correctly, it will probably not look exactly like in the textbook. It's kind of hard to give it a name. It may be a mix of patterns. It's the principle that counts. Reality is too complex for rigid design patterns. On the other hand, some design patterns are too common and obvious to deserve a name. For example, the factory pattern is super common... I use it all the time but it's so basic and obvious that I will sound like a total noob if I go around calling my function "socket factory pattern"... I will call it "Utility function to obtain a socket" or something. I will never refer to it as a factory pattern, it's a bit cringe.
- zwnow 11mo ago
pajtai 11mo ago
Looks great. Wish it had a table of contents. Am I missing it?
rswail 11mo ago
Patterns are needed for languages for which the actual underlying concept is unavailable. For example, prototype pattern is for languages that don't have a way to express interfaces/traits etc as something that can be attached to other language entities.
pedrozieg 11mo ago
Most teams don’t fail because they picked the wrong framework; they fail because they never ship enough iterations for it to matter. Anything that reliably shortens that loop is “good tech,” even if it’s ugly, uncool, or built on last decade’s stack.
sh4rks 11mo ago
This looks like an excellent resource for interview preparation. Bookmarked.
dkersten 11mo ago
I hate that singleton is first. Singletons are just globals with extra steps, and have all the same problems globals have, just people (especially juniors) think they somehow are better. In reality they’re worse because they conflate global access with enforced single instance. You almost never need to enforce a single instance. If you only want one of something, then create only one. Don’t enforce it unless it’s critical that there’s only one. Loggers are often given as an example of a “good” singleton and yet we often need multiple loggers for things like audit logs, or separating log types. Instead of singletons, use dependency injection, use context objects, use service locators, or… just use globals and accept that they come with downsides instead of hiding behind the false sense of code quality that is a singleton.
- deleted 11mo ago
  [deleted]
bingemaker 11mo ago
Looks more or less like GoF? Maybe compressing files and optimizing 3rd party js files are not patterns.
emaro 11mo ago
Design patterns can be really helpful. In my previous job I worked on enterprise .NET applications. It made sense to use common patterns, because most applications were big and the patterns made it easier to understand unfamiliar code, within an application but also across different teams and applications. New projects looked familiar, because the same style and the same patterns were used. Now I'm working on an old (+10 years) JS application. Similar patterns were implemented, but in this case it's not helpful at all. The code looks very corporate and Java EE style, with a ton of getters and setters (`getName() {}`, not `get name() {}`, factories, facades, adapters, etc, etc. It's usually completely unclear what the benefit of the pattern is, and code is more complicated, for instance because creating new instances of business objects is split into `Object.build` which calls `new Object`, with no guidelines at all what part of the initialization should be in `build` and what should be in the constructor. The gist of my comment is that patterns can be useful, but usually they're overused and if you implement one without understanding why and without benefiting from faster understanding the code because the pattern is applied consistently over multiple instances, the result is worse than just implementing what you need in a readable way (YAGNI).
- skydhash 11mo ago
  A lot of patterns only make sense in languages like C# or Java, which are inflexible by design. You have two hierarchical trees (inheritance and namespaces) that you have to work around. With something simpler like C, Go, JavaScript, you don’t have those obstacles and a solution can be way simpler to implement.
  - richardlblair 11mo ago
    Somewhat true - I usually find that in these languages the patterns are there they are just less obvious.
  - ssrc 11mo ago
    Some patterns in the GoF book only apply to C++/Java as they were in 1994, but I don't see any reason why other languages would have no useful patterns. The Linux kernel (C) is full of patterns for example. Funny thing, Peter Norvig also has this position, that patterns only apply to languages like Java, but his book on Lisp and the Python course he had on Udemy (?) are super-pattern-y.
css_apologist 11mo ago
a lot of these are misleading, or ungrounded see the prototype, and observable pattern they explain the basic concept, but in the only way you would never use it in real life
andybak 11mo ago
"Design Patterns are a sign of missing language features". https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeature... https://norvig.com/design-patterns/design-patterns.pdf https://norvig.com/design-patterns/design-patterns.pdf https://medium.com/@letsCodeDevelopers/your-design-patterns-are-just-workarounds-for-language-flaws-612a44719264 https://medium.com/@letsCodeDevelopers/your-design-patterns-...
css_apologist 11mo ago
this site reads like its 2017 its low quality, breadth but no depth more important is to deeply understand the basics of working with immutable data. try writing applications with no for loops or forEach (and actually use the array methods as they are intended), no cloneDeep hacks and obviously no direct property mutation, always create a new object. in real world you still use for loops plenty, but as a junior its good to see what its like to live without it for a while.
- css_apologist 11mo ago
  although this article does get me thinking of documenting the “patterns” i use, and why.
- dominicrose 11mo ago
  I've used Clojure/Script in the past and it's good to enforce working with immutable data. Immutable.js has similar data structures but it's not the standard way of doing things and uglier to debug. Using standard objects, immutability is not enforced in JS and throwing a few Object.freeze calls won't change that so we lose half the benefits that Clojure would bring: parallel/concurrent programming benefits, easier deep equality checks, performance... If the code is not performance sensitive and can run in a single thread, simply "not mutating some of the mutable data" is a start for someone interested in immutability. That's what ramdajs does, it doesn't invent new data structures or freeze objects but simply returns new ones. Only a few functions from ramdajs are actually useful in 2025 since JS has evolved with things like array/object destructuring and "..." but in any case it's an inspiring library.
  - css_apologist 11mo ago
    I've used these things. IME, nowadays it's not worth the bundle size to bring in these libraries. map/filter seems quite optimized, {...obj} is fast since its only shallow. Yes it does come down to practices vs better libraries, but in practice, it's fine IME One thing to note, i was very excited that we have a bunch of lazy methods on Iterator protocol, but they are slow as shit as of earlier this year. I wrote a parser a year ago with extreme use of .map (every step of processing was cloning the tokens), and i thought, let's migrate it to lazy iterator - it got ~10x slower :(. The compile time was fine for my use cases, so i didn't give immutable-js a try, but it was a surprise I did some benchmarks on map+filter vs mutable for of + push, and on firefox up to 200-300 elements map+filter is actually faster (unforunately not on chrome). Of course, its not the best, but my experience is that modern js engines are fast enough for most use cases to not have to bring in any libraries anymore
bmiekre 11mo ago
Did this get an update? It's been around for a while.
kaycey2022 11mo ago
Are these patterns also the same for mobile apps?
tigrezno 11mo ago
Too bad the examples are not Typescript, because it's a totally different beast.
verdverm 11mo ago
Is this JavaScript's take on the GOF book selections plus all the shenans, er "patterns," the ecosystem build tools require? I was hoping for more high-level architecture based on war stories and experience. This is pretty basic stuff, which has it's value for people earlier in their journey, and does seem to have effort put in from a quick peruse
PUSH_AX 11mo ago
I don't think I've thought about patterns in over a decade, maybe I use one or two without realising it's a "pattern".
lacoolj 11mo ago
I'm reading these articles in Addy's voice. It's quite wonderful

627 points by handfuloflight 11mo ago

1970-01-01 11mo ago

Thanks, I was looking for something just like this today!

I was glancing around and landed on the page for the flyweight pattern.[1] It looks like `addBook` is using the spread operator, which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern. It also attaches extra arbitrary properties, but still assigns the result to a `book` variable. I don't think this is a great example. [1]: https://www.patterns.dev/vanilla/flyweight-pattern/ https://www.patterns.dev/vanilla/flyweight-pattern/ Edit: I forgot to give you kudos for all the effort it must have taken to create all this content, and I appreciate that you're making it available for free.

KPGv2 11mo ago
> which always creates a shallow copy of the book instance properties, thus nullifying any benefits of the flyweight pattern No, the opposite: it highlights the benefits of the flyweight pattern. The shallow copy saves memory. That's the point. You have two identical books. Rather than wasting memory with a deep copy, you make a shallow copy, where all your props point to locations in memory where values are located, and then you modify whatever is different. Now your shallow copy only consumes a small bit of extra memory. And if those props are all primitives, then you can then modify that shallow copy, and it won't affect the original.
- HumanOstrich 11mo ago
  The point is to not make a copy at all for the shared data of the same book. That's even what the page claims is happening (but it's wrong). That's the whole point of the flyweight pattern[1]. Instead, the example returns the same book instance for the same isbn in `createBook`, then blindly copies the shared data like title, author, and isbn every time in `addBook` to a new object. > The shallow copy saves memory.... Versus not making a copy? A shallow copy of primitives still copies them and uses additional memory. Maybe there's some low-level optimization that makes it more efficient than that, but it's not relevant here. And there isn't any deep cloning happening in the example. Might as well get rid of the complexity and instantiate a new Book class every time. And maybe stop shallow-copying class instances into new plain objects. It works for the example but has footguns. Conveniently, there are other patterns on the site that would help you avoid creating an amalgamation of random merged class instances and objects. The whole example is a mess. [1]: https://en.wikipedia.org/wiki/Flyweight_pattern https://en.wikipedia.org/wiki/Flyweight_pattern
songodongo 11mo ago
Good to know I wasn’t the only one thinking “wait a second…” when reading that one and seeing the spread operator being used.

seabass 11mo ago

Love this! Just wanted to note that I think there’s a mistake on the flyweight pattern page’s example. You’re using getting a boolean with Set.has but treating it like a Book (as if you had used Set.get). I also don’t really understand how this saves memory if you’re spreading the result into a new object, but maybe someone here can enlighten me!

seabass 11mo ago
Ah I think I understand now. The return type of createBook is true | Book, which is likely a mistake, but happens to work because when you attempt to spread a boolean into an object it removes itself. But if you were to edit the example to have a stable return type of Book then it would no longer save memory, so perhaps that was intentional?

8cvor6j844qw_d6 11mo ago

Looks great, time to add it to my bookmarks. Anyone has other sites like these to share? - Domain-driven design, design patterns, and antipatterns https://deviq.com/ https://deviq.com/ - Refactoring and Design Patterns https://refactoring.guru/ https://refactoring.guru/ - Standard Patterns in Choice-Based Games https://heterogenoustasks.wordpress.com/2015/01/26/standard-patterns-in-choice-based-games/ https://heterogenoustasks.wordpress.com/2015/01/26/standard-...

begueradj 11mo ago
Useful links. Thank you.
rambleraptor 11mo ago
I’ll make a plug for aep.dev, which is a collection of API design best practices and assorted tooling
- JimDabell 11mo ago
  Google has something similar: https://google.aip.dev https://google.aip.dev
  - rambleraptor 11mo ago
    AEP began its life as a fork of AIP! We’ve got a bunch of ex-Google folks on the project, including the former API Lead at Google.
sdovan1 11mo ago
- Java Design Patterns https://java-design-patterns.com/ https://java-design-patterns.com/
- vips7L 11mo ago
  Love how you were downvoted for mentioning Java.

android521 11mo ago

The ones that actually match POSD (deep modules, small interfaces, lower complexity) and work great with plain functions are: Module Pattern Factory Pattern (factory functions) Mediator / Middleware Pattern (as function pipelines) Hooks Pattern (custom hooks, generalized) Container / Presentational Pattern (implemented with function components + hooks) Everything else is either neutral, UI-only, or fights POSD (Singleton, Mixin, etc.). Patterns from that page you should treat skeptically for POSD From Patterns.dev, for your POSD-style codebase I’d avoid or downplay: Singleton Pattern → encourages global state and tight coupling. Patterns Mixin Pattern → tends to increase interface surface and make dependencies opaque. Patterns Observer Pattern → powerful, but event-based wiring can obscure data flow and increase “system complexity” (classic POSD warning). Patterns

neogodless 11mo ago
What does POSD stand for?
- culi 11mo ago
  I'm assuming Philosophy of Software Design but I've never seen anyone blatantly presume it's an implicit initialism
- jakubmazanec 11mo ago
  I'm assuming John Ousterhout's book A Philosophy of Software Design [1], which I would recommend reading before reading about design patterns, because it's more fundamental. [1] https://news.ycombinator.com/item?id=37975558 https://news.ycombinator.com/item?id=37975558

deleted 11mo ago

[deleted]

vivzkestrel 11mo ago

fantastic resource! kindly add svelte design patterns too and sveltekit if you can

nl 11mo ago

Does anyone remember the Yahoo design patterns library? It was mostly for UX pattern (eg: ways to "Rate an object") and it was really good. Almost 20 years ago.. damn. https://creativecommons.org/2006/02/14/yahoodesignpatternlibrary/ https://creativecommons.org/2006/02/14/yahoodesignpatternlib... https://web.archive.org/web/20060221111812/http://developer.yahoo.net/ypatterns/index.php https://web.archive.org/web/20060221111812/http://developer.... They had a great comparison of the different behaviors leaderboards could encourage in users.

101008 11mo ago
Oh, the second link is amazing. I love the old web, and that brought a lot of nostalgia.
culi 11mo ago
Not quite the same thing, but there's this incredible (open source) project called The Component Gallery that is basically just a repository of UI components across 93 (currently) different design systems. It's an incredible resource if you're building a component from scratch and either want some design inspo or technical advice. Many of the design systems have thorough guidelines for a11y/ARIA best practices that I've learned a ton from https://component.gallery/ https://component.gallery/
paulirish 11mo ago
Amen! The terms "accordion" and "carousel" were really codified by the pattern library. Establishing a common vernacular definitely accelerates things.
no_wizard 11mo ago
YUI was ahead of its time as well
- deleted 11mo ago
  [deleted]
- cachius 11mo ago
  And it spawned ExtJS. Which could have been React, but they messed up. Literally they built a faster Facebook app 'Fastbook' in 2012. Short history lesson: https://medium.com/hackernoon/the-rise-and-fall-of-ext-js-c9d727131991 https://medium.com/hackernoon/the-rise-and-fall-of-ext-js-c9... In August 2006, a guy by the name of Jack Slocum (now CEO of Alta5) began to blog of his experiments with YUI. Over time, these experiments became more complex and Jack would start to bundle them into what would later be named YUI-ext (Yahoo UI extensions) — the precursor to Ext JS (Extensible JavaScript). Jack Slocum’s blog was used to communicate his vision for YUI-ext and garnered community support from around the world. The release of the Grid component for YUI-ext would forever change the trajectory of the library and the community as the GridPanel would become the core UI component for many applications to come. Throughout its early life, Jack continued to build upon YUI-ext by adding features to the framework, such as animations, Modals, Tab Panel, Resizable elements and a layout manager that greatly expanded upon the YUI framework. These components would seldom extend the YUI library and had their own rendering functions. YUI-ext created a foundation for web programmers unlike anything the world had seen before and many developers flocked to the framework and invested in the newly formed community. The net result was the explosive expansion of YUI-ext. From YUI-ext to Ext JS In January 2007 we found Jack extremely busy to push out YUI-ext 0.40 and it is this version where we find the namespace of the framework change from YAHOO.ext to a much simpler Ext (pronounced “ekst J S” or “E-X-T J S” by some of us old-school community members). February 2007, Ext JS 1.0 was being developed in tandem with a new website, ExtJS.com. In April 2007, the launch of ExtJS.com was announced to the community along with the release of Ext JS 1.0. https://web.archive.org/web/20230222210535/https://jackslocum.com/the-rise-and-fall-of-ext-js-a-long-overdue-reply-and-apology-65ec5c1afda0?gi=af7e9452f5e5 https://web.archive.org/web/20230222210535/https://jackslocu... For those that don’t know, Ext JS was one of the first JavaScript frameworks in the early days of Web 2.0. It was the first framework to offer a complete package of everything needed to build full-fledged applications using just JavaScript in a web browser. At one point, it was used by over 2 million developers worldwide, 70% of the fortune 500, and 8 of the top 10 financial institutions. It was years ahead of everyone else, open source, and had an incredible community of passionate people contributing to its success. As that success grew, so did the number of copycat competitors. They eventually started taking the code and assets and embedding them into their own frameworks. Adobe embedded it in Cold Fusion and other competitive frameworks followed their lead without any contribution to the framework or community. At the time the thought of competing directly against a behemoth like Adobe was scary. How could they take our product and offer it as their own? I took what I thought was the right action to “protect” Ext JS from being “stolen” by changing to a more restrictive license. That was a huge mistake. Looking back in hindsight, without the fear, I have a much clearer picture. I see what truly made Ext JS great was not the code - it was all the people who loved, contributed and supported it. As we worked on making our own dreams a reality, we helped others do the same, sharing our knowledge, code, and solving tough challenges together. That is what really mattered — our community. That is what I should have protected, not the code. You were my closest friends. I am sorry I changed the license after we all came to an agreement on the first license. That was a breach of integrity and you deserved better. I would do it differently if I could.

fiddlerwoaroof 11mo ago

I wish people would stop promoting the singleton pattern: in almost every case I’ve seen, singletons are unnecessary tech debt and solve a problem that’s better solved with some form of dependency injection (and I don’t mean the XML/YAML monstrosities various frameworks force on you but rather constructor arguments or factory functions)

HumanOstrich 11mo ago
The site is not "promoting" the singleton pattern. In fact, there is a "Tradeoffs"[1] section that calls it an anti-pattern in JavaScript. In spite of that, there are plenty of reasonable use cases for singletons in many languages, including JavaScript. For example, ES Modules are effectively singletons. If you import the same module in multiple places, it only gets evaluated once. Let's not turn the singleton pattern into forbidden knowledge. [1]: https://www.patterns.dev/vanilla/singleton-pattern/#tradeoffs https://www.patterns.dev/vanilla/singleton-pattern/#tradeoff...
deaux 11mo ago
Why pose DI as replacing singletons when they're used together all the time? Injecting dependencies to create a singleton repository or service class, which is shared across requests.
hokumguru 11mo ago
Off the top of my head, rails (currentattributes), Laravel (facades) especially, and most iOS apps use singletons quite well. It’s all in moderation and depends highly on how it’s used, much like every other design pattern. I think people just don’t like Singletons because they’ve been especially misused in the past but I guarantee the same argument stands for any other design pattern.
dkersten 11mo ago
Singletons are globals and should be treated the same as every other global (that is, used sparingly and with care). Worse is that singletons enfurece a single instance which is almost always unnecessary. It’s trivial to only create as many instances as you need.
11mo ago

wavemode 11mo ago

Great site! I tend to advocate for people to study design patterns. Not for the purpose that you will necessarily ever use most (or even any) of these exact patterns in your software, but just that you've strengthened your mental muscle for software design in general. I encounter lots of engineers who simply aren't able to think "outside the box" when building something new.

lock1 11mo ago
I always wondered if people actually find it beneficial to follow these "design patterns" or not. Personally, I prefer to learn FP patterns, which tend to be backed with nice mathematical properties behind them.

noveltyaccount 11mo ago

In my senior year of college two decades ago, I needed one or two credit hours to finish up, and I signed up for a once per week software patents (as in, intellectual property, I thought) course. It turned out to be a patterns course taught by none other than Ralph Johnson and the text was his famous Gang of Four Design Patterns book. Happy accident, it turned out to be among the most professionally useful courses I ever took. https://en.wikipedia.org/wiki/Ralph_Johnson_(computer_scientist) https://en.wikipedia.org/wiki/Ralph_Johnson_(computer_scient...

deleted 11mo ago

[deleted]

phplovesong 11mo ago

When overused these kind of "patterns" always lead to slow and hard to grasp code that is a nightmare to maintain.

z3t4 11mo ago
My experience is that they are best discovered independently as a way to abstract code, and let them come naturally to solve a problem. So for most things in Dev, if you do something prematurely you might end up with a good solution for a non existing problem.
- oleggromov 11mo ago
  Or, even more likely, a bad solution for a non-existent problem.
FieryMechanic 11mo ago
Like many things they shine when use appropriately.

akst 11mo ago

A singleton for me is just making sure you define a single instance of something at the entry point of your app and passing it down via constructor arguments, which is normally what I do. I understand you can override modules in tests, and if you have a version of your app that runs in a different environment where you might replace a HTTP service with a different variant (like if an RPC service that normally performs HTTP requests, but in one case maybe you want to talk to specific process, worker or window using message passing). I really really feel using constructor args is just a lot simpler in most cases. But I think there's a reason why people don't always do this: 1. Sometimes someone is using a framework that imposes a high level of inversion of control where you don't get to control how your dependencies are initialised. 2. (this was me when I was much younger) Someone dogmatically avoided using classes and thought they could get away with just data and functions, and then they realise there is some value in some shared instance of something and then they just undermine any functional purity. Don't get me wrong, functional purity is great, but there are parts of your apps that just aren't going to be functionally pure. And you don't need to go full OOP when you use classes. ---------------------------------------- Here are some examples of what I mean. Here's one example, where I have an app defined in web components and I define the components for each part of the app before passing them into the skeleton. It's a more simple app and I avoid some shared state by different landmark components communicating by events. https://github.com/AKST/analysis-notebook/blob/b3f082fc63c9bdf39d00be9bbf99d70a735a3a14/index.js#L35-L40 https://github.com/AKST/analysis-notebook/blob/b3f082fc63c9b... ---------------------------------------- Here's another example, this app is built of multiple command line instructions that sometimes have their own version of services (singletons) with specific configuration, sometimes they are initialised in child processes. https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69a587892d285fd34c3aa0b11f712/lib/tasks/gis/stage_api_data.py#L156-L170 https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69... Because this app is doing a lot of scrapeing and I wanted to also child worker processes to do their own HTTP I was going to make a variant of my HTTP service which talked to a daemon process that tracked state for open connections to specific domains to avoid opening too many simultaneously and getting blocked by that host. Updating the code that uses HTTP will be effortless, because it will continue to conform to the same API. I know this because I've already done this multiple times with HTTP scrapping in the app. https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69a587892d285fd34c3aa0b11f712/lib/tasks/gis/stage_api_data.py#L90-L103 https://github.com/AKST/Aus-Land-Data-ETL/blob/672280a8ded69...

Simplita 11mo ago

This resource aged surprisingly well. Still one of the clearest ways to understand common frontend patterns.

crabmusket 11mo ago

This is a nicely laid out collection of tutorials, but I'm sad that collections like this have drifted away from the very deliberate structure that A Pattern Language introduced. While patterns weren't invented by Alexander and co, they did inspire a lot of what we see in tech these days, inherited via design patterns etc. In A Pattern Language, each pattern is hyperlinked to other patterns in a kind of hierarchy, where larger patterns (like "house cluster") are broken down into smaller constituent parts ("main entrance") all the way to quite granular details ("low doorway"). This is because you can't just take a pattern on its own; it forms part of a larger whole. Tech pattern books often focus on small recurring structures (e.g. "command pattern" from this site), but not how they help create some larger pattern, or in the other direction, what are the smaller patterns that help create them. This sounds like a lot of hard work of course, which is why people don't do it.* I would love to see this accomplished though. If only I had an extra 36 hours in each day. One thing that A Pattern Language is also great at is motivating each pattern with a specific problem or symptom. This site seems to do a decent job at that, though some problems seem... kind of weakly motivated. For example, the above mentioned "command pattern" is motivated by "what if we need to rename a method?" which... is pretty weak tbh. *EDIT: also because fitting patterns into a whole, maybe unavoidably, will promote a perspective, or a way of building a whole system. A pattern book for web applications written from an HTMX point of view would be a very different book to one written from a React slant. Maybe one pattern language can accommodate both sets of technologies, or maybe not.

crabmusket 11mo ago
Here's an excerpt from APL showing what I mean about the connections to the other patterns. This isn't the whole pattern, there's a lot between the problem statement and summary. Annotations in brackets are mine. --- Short Passages (132) [Context, or pre-links] The Flow Through Rooms (131) describes the generosity of light and movement in the way that rooms connect to one another and recommends against the use of passages. But when there has to be a passage in an office or a house and when it is too small to be a Building Thoroughfare (101), it must be treated very specially, as if it were itself a room. This pattern gives the character of these smallest passages, and so completes the circulation system laid down by Circulation Realms (98) and Building Thoroughfare (101) and The Flow Through Rooms (131). [Problem statement] Long, sterile corridors set the scene for everything bad about modern architecture. In fact, the ugly long repetitive corridors of the machine age have so far infected the word "corridor" that it is hard to imagine that a corridor could ever be a place of beauty, a moment in your passage from room to room, which means as much as all the moments you spend in the rooms themselves. [Pattern contents here] [Pattern summary] Keep passages short. Make them as much like rooms as possible, with carpets or wood on the floor, furniture, bookshelves, beautiful windows. Make them generous in shape, and always give them plenty of light; the best corridors and passages of all are those which have windows along an entire wall. [Elaboration, or post-links] Put in windows, bookshelves, and furnishings to make them as much like actual rooms as possible, with alcoves, seats along the edge - Light on Two Sides of Every Room (159), Alcoves (179), Window Place (180), Thick Walls (197), Closets Between Rooms (198); open up the long side into the garden or out onto balconies - Outdoor Room (163), Gallery Surround (166), Low Sill (222). Make interior windows between the passage and the rooms which open off it - Interior Windows(194), Solid Doors With Glass(237). And finally, for the shape of the passages, in detail, start with The Shape of Indoor Space (191)

socketcluster 11mo ago

I find that the more senior you become, the less you rely on software design patterns. Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more complexity than they would have created had they not used design patterns. There are situations where design patterns may be useful but they're much more rare than most people think. A lot of juniors seem to think that every problem requires them to apply a design pattern from their toolbox. They try to frame every problem within the constraints of design patterns that they know. This can create problems. In fact, there are many coding patterns which are far simpler than 'design patterns' and much more useful, but nobody talks about them because they're too trivial to discuss. For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I use it literally ALL the time. The idea of storing intermediate state in some kind of HashMap is a game-changer IMO but there's no name for that pattern of coding. In general, knowing what data structure is most appropriate for various scenarios is a game changer... But still, don't abuse. Basic data structures like arrays are fine most of the time. Anyway, it's good to absorb the wisdom behind some design patterns but you should not try to fit every problem to them and dont say stuff like "For this problem, I applied Design Pattern X" - If you do, senior engineers will know you're a junior. If you use a design pattern correctly, it will probably not look exactly like in the textbook. It's kind of hard to give it a name. It may be a mix of patterns. It's the principle that counts. Reality is too complex for rigid design patterns. On the other hand, some design patterns are too common and obvious to deserve a name. For example, the factory pattern is super common... I use it all the time but it's so basic and obvious that I will sound like a total noob if I go around calling my function "socket factory pattern"... I will call it "Utility function to obtain a socket" or something. I will never refer to it as a factory pattern, it's a bit cringe.

zwnow 11mo ago

pajtai 11mo ago

Looks great. Wish it had a table of contents. Am I missing it?

rswail 11mo ago

Patterns are needed for languages for which the actual underlying concept is unavailable. For example, prototype pattern is for languages that don't have a way to express interfaces/traits etc as something that can be attached to other language entities.

pedrozieg 11mo ago

Most teams don’t fail because they picked the wrong framework; they fail because they never ship enough iterations for it to matter. Anything that reliably shortens that loop is “good tech,” even if it’s ugly, uncool, or built on last decade’s stack.

sh4rks 11mo ago

This looks like an excellent resource for interview preparation. Bookmarked.

dkersten 11mo ago

I hate that singleton is first. Singletons are just globals with extra steps, and have all the same problems globals have, just people (especially juniors) think they somehow are better. In reality they’re worse because they conflate global access with enforced single instance. You almost never need to enforce a single instance. If you only want one of something, then create only one. Don’t enforce it unless it’s critical that there’s only one. Loggers are often given as an example of a “good” singleton and yet we often need multiple loggers for things like audit logs, or separating log types. Instead of singletons, use dependency injection, use context objects, use service locators, or… just use globals and accept that they come with downsides instead of hiding behind the false sense of code quality that is a singleton.

deleted 11mo ago
[deleted]

bingemaker 11mo ago

Looks more or less like GoF? Maybe compressing files and optimizing 3rd party js files are not patterns.

emaro 11mo ago

Design patterns can be really helpful. In my previous job I worked on enterprise .NET applications. It made sense to use common patterns, because most applications were big and the patterns made it easier to understand unfamiliar code, within an application but also across different teams and applications. New projects looked familiar, because the same style and the same patterns were used. Now I'm working on an old (+10 years) JS application. Similar patterns were implemented, but in this case it's not helpful at all. The code looks very corporate and Java EE style, with a ton of getters and setters (`getName() {}`, not `get name() {}`, factories, facades, adapters, etc, etc. It's usually completely unclear what the benefit of the pattern is, and code is more complicated, for instance because creating new instances of business objects is split into `Object.build` which calls `new Object`, with no guidelines at all what part of the initialization should be in `build` and what should be in the constructor. The gist of my comment is that patterns can be useful, but usually they're overused and if you implement one without understanding why and without benefiting from faster understanding the code because the pattern is applied consistently over multiple instances, the result is worse than just implementing what you need in a readable way (YAGNI).

skydhash 11mo ago
A lot of patterns only make sense in languages like C# or Java, which are inflexible by design. You have two hierarchical trees (inheritance and namespaces) that you have to work around. With something simpler like C, Go, JavaScript, you don’t have those obstacles and a solution can be way simpler to implement.
- richardlblair 11mo ago
  Somewhat true - I usually find that in these languages the patterns are there they are just less obvious.
- ssrc 11mo ago
  Some patterns in the GoF book only apply to C++/Java as they were in 1994, but I don't see any reason why other languages would have no useful patterns. The Linux kernel (C) is full of patterns for example. Funny thing, Peter Norvig also has this position, that patterns only apply to languages like Java, but his book on Lisp and the Python course he had on Udemy (?) are super-pattern-y.

css_apologist 11mo ago

a lot of these are misleading, or ungrounded see the prototype, and observable pattern they explain the basic concept, but in the only way you would never use it in real life

andybak 11mo ago

"Design Patterns are a sign of missing language features". https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeature... https://norvig.com/design-patterns/design-patterns.pdf https://norvig.com/design-patterns/design-patterns.pdf https://medium.com/@letsCodeDevelopers/your-design-patterns-are-just-workarounds-for-language-flaws-612a44719264 https://medium.com/@letsCodeDevelopers/your-design-patterns-...

css_apologist 11mo ago

this site reads like its 2017 its low quality, breadth but no depth more important is to deeply understand the basics of working with immutable data. try writing applications with no for loops or forEach (and actually use the array methods as they are intended), no cloneDeep hacks and obviously no direct property mutation, always create a new object. in real world you still use for loops plenty, but as a junior its good to see what its like to live without it for a while.

css_apologist 11mo ago
although this article does get me thinking of documenting the “patterns” i use, and why.
dominicrose 11mo ago
I've used Clojure/Script in the past and it's good to enforce working with immutable data. Immutable.js has similar data structures but it's not the standard way of doing things and uglier to debug. Using standard objects, immutability is not enforced in JS and throwing a few Object.freeze calls won't change that so we lose half the benefits that Clojure would bring: parallel/concurrent programming benefits, easier deep equality checks, performance... If the code is not performance sensitive and can run in a single thread, simply "not mutating some of the mutable data" is a start for someone interested in immutability. That's what ramdajs does, it doesn't invent new data structures or freeze objects but simply returns new ones. Only a few functions from ramdajs are actually useful in 2025 since JS has evolved with things like array/object destructuring and "..." but in any case it's an inspiring library.
- css_apologist 11mo ago
  I've used these things. IME, nowadays it's not worth the bundle size to bring in these libraries. map/filter seems quite optimized, {...obj} is fast since its only shallow. Yes it does come down to practices vs better libraries, but in practice, it's fine IME One thing to note, i was very excited that we have a bunch of lazy methods on Iterator protocol, but they are slow as shit as of earlier this year. I wrote a parser a year ago with extreme use of .map (every step of processing was cloning the tokens), and i thought, let's migrate it to lazy iterator - it got ~10x slower :(. The compile time was fine for my use cases, so i didn't give immutable-js a try, but it was a surprise I did some benchmarks on map+filter vs mutable for of + push, and on firefox up to 200-300 elements map+filter is actually faster (unforunately not on chrome). Of course, its not the best, but my experience is that modern js engines are fast enough for most use cases to not have to bring in any libraries anymore

bmiekre 11mo ago

Did this get an update? It's been around for a while.

kaycey2022 11mo ago

Are these patterns also the same for mobile apps?

tigrezno 11mo ago

Too bad the examples are not Typescript, because it's a totally different beast.

verdverm 11mo ago

Is this JavaScript's take on the GOF book selections plus all the shenans, er "patterns," the ecosystem build tools require? I was hoping for more high-level architecture based on war stories and experience. This is pretty basic stuff, which has it's value for people earlier in their journey, and does seem to have effort put in from a quick peruse

PUSH_AX 11mo ago

I don't think I've thought about patterns in over a decade, maybe I use one or two without realising it's a "pattern".

lacoolj 11mo ago

I'm reading these articles in Addy's voice. It's quite wonderful