[HN Gopher] Patterns.dev
___________________________________________________________________
Patterns.dev
Author : handfuloflight
Score : 562 points
Date : 2025-12-11 01:18 UTC (21 hours ago)
(HTM) web link (www.patterns.dev)
(TXT) w3m dump (www.patterns.dev)
| 1970-01-01 wrote:
| Thanks, I was looking for something just like this today!
| HumanOstrich wrote:
| 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/
|
| 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 wrote:
| > 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 wrote:
| 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
| songodongo wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/
|
| - Refactoring and Design Patterns
|
| https://refactoring.guru/
|
| - Standard Patterns in Choice-Based Games
|
| https://heterogenoustasks.wordpress.com/2015/01/26/standard-...
| rambleraptor wrote:
| I'll make a plug for aep.dev, which is a collection of API
| design best practices and assorted tooling
| JimDabell wrote:
| Google has something similar:
|
| https://google.aip.dev
| rambleraptor wrote:
| 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 wrote:
| - Java Design Patterns
|
| https://java-design-patterns.com/
| vips7L wrote:
| Love how you were downvoted for mentioning Java.
| mdhb wrote:
| The JS community is so freaking strange sometimes.
| culi wrote:
| I posted this elsewhere in this thread:
|
| https://component.gallery/
|
| Great meta resource for building UI components.
| lelandfe wrote:
| Design patterns and component libraries are a bit related but
| they're pretty different concerns ultimately.
| culi wrote:
| It's more of a meta resource. Many of these design
| guidelines go in depth on accessibility best practices and
| UI patterns
| culi wrote:
| Oh here's a resource for common "idioms" across programming
| languages
|
| https://programming-idioms.org/
| crabmusket wrote:
| Microsoft's cloud design patterns are quite well-written IMO,
| if you're into that kind of thing
|
| https://learn.microsoft.com/en-us/azure/architecture/pattern...
| bbminner wrote:
| I think it is difficult to oversell the bob nystrom game
| patterns book
|
| https://gameprogrammingpatterns.com/contents.html
| begueradj wrote:
| Useful links. Thank you.
| esfandia wrote:
| The OG site for patterns is of course the Portland Pattern
| Repository. I believe Ward Cunningham invented wiki for this
| purpose initially!
|
| https://c2.com/ppr/
| endymion-light wrote:
| +1 for refactoring.guru, find it really useful whenever i want
| to refactor some pre-existing code. Only wish they had a
| physical book!
| elktown wrote:
| Here be dragons. People trying to pattern-match their problems
| to design patterns can waste a lot of time and effort over many
| years. Use responsibly.
| gopher_space wrote:
| To your point, everything we do is context-sensitive and
| patterns are revealed by abstracting context.
| slig wrote:
| https://www.deceptive.design/
| android521 wrote:
| 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 wrote:
| What does POSD stand for?
| culi wrote:
| I'm assuming Philosophy of Software Design but I've never
| seen anyone blatantly presume it's an implicit initialism
| jakubmazanec wrote:
| 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
| vivzkestrel wrote:
| fantastic resource! kindly add svelte design patterns too and
| sveltekit if you can
| nl wrote:
| 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/yahoodesignpatternlib...
|
| https://web.archive.org/web/20060221111812/http://developer....
|
| They had a great comparison of the different behaviors
| leaderboards could encourage in users.
| 101008 wrote:
| Oh, the second link is amazing. I love the old web, and that
| brought a lot of nostalgia.
| culi wrote:
| 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/
| paulirish wrote:
| Amen! The terms "accordion" and "carousel" were really codified
| by the pattern library. Establishing a common vernacular
| definitely accelerates things.
| no_wizard wrote:
| YUI was ahead of its time as well
| cachius wrote:
| 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-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://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.
| dahcryn wrote:
| we often forget how great Yahoo engineering was back in the
| day, sad it was destroyed by bad management and horrible
| business cases prioritization
| dimaor wrote:
| for some reason I remember him being related to YUI, but I
| learned JS from Douglas Crockford, one of the best lectures
| from the old days of JS.
| fiddlerwoaroof wrote:
| 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 wrote:
| 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/#tradeoff...
| deaux wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gm678 wrote:
| Yes, I have to admit my interest was piqued by the banner, and
| I then scrolled down, saw the first example was singletons, and
| closed the tab.
| wavemode wrote:
| 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 wrote:
| 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 wrote:
| 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_scient...
| phplovesong wrote:
| When overused these kind of "patterns" always lead to slow and
| hard to grasp code that is a nightmare to maintain.
| z3t4 wrote:
| 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 wrote:
| Or, even more likely, a bad solution for a non-existent
| problem.
| FieryMechanic wrote:
| Like many things they shine when use appropriately.
| akst wrote:
| 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/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/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/672280a8ded69...
| Simplita wrote:
| This resource aged surprisingly well. Still one of the clearest
| ways to understand common frontend patterns.
| crabmusket wrote:
| 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 wrote:
| 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)_ , S _olid Doors With Glass(237)_. And finally,
| for the shape of the passages, in detail, start with _The Shape
| of Indoor Space (191)_
| socketcluster wrote:
| 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 wrote:
| For webdev especially everything I do is basically
| singletons... For UI state management its just perfect and
| that's about the hardest thing in web dev. Also easy to recover
| state with, in a SPA if a user refreshes the site. Or control
| whether a modal is open or not. Easy to centralize logic too...
| Never looked into any other patterns as a lot of them seem like
| bloat.
| hyfgfh wrote:
| Agreed! The problem is that some 'seniors' never cared to learn
| patterns in the first place. That's a huge problem for
| frontend, where we have increasingly complex architectures and
| people with very little experience with design.
|
| Even some principles aren't known. I always recommend the book
| Head First: Design Patterns. It's in Java, but the lessons can
| be applied in every language.
|
| Unfortunately, we are in a 'post-knowledge' era... I don't know
| how we can keep things up at this pace.
| prodigycorp wrote:
| What's interesting about frontend is that there are two ways
| to evaluate it: by how it looks and how it's written.
|
| It definitely biases how people evaluate llms. Many cite
| Claude as their favorite llm for generating frontend code,
| but I suspect that many people prefer it because the output
| is prettier, rather than better composed.
| davidkunz wrote:
| > It's in Java, but the lessons can be applied in every
| language.
|
| I can only discourage anyone from applying Java patterns all
| over the place. One example in JavaScript: There was a
| functionality that required some parameters with default
| values. The plain solution would have been:
| function doStuff({ x = 9, y = 10 } = {}) { ... }
|
| Instead, they created a class with private properties and
| used the builder pattern to set them. Totally unnecessary.
| Kwpolska wrote:
| I've read that book, and it felt very childish and
| condescending.
|
| Design patterns cannot be applied in every language. While
| some patterns are applicable everywhere, many of them provide
| replacements for missing language features. For example, the
| Builder pattern is not very useful in languages with default
| parameters and named arguments.
| microtherion wrote:
| I'm not sure what Builder would have to do with default
| parameters and named arguments.
|
| Builder is extremely useful to pair with a parser, e.g.
| SAX. The parser parses the input, and the builder then
| decides what to do with it.
| Kwpolska wrote:
| Here is an example of the Builder pattern that
| illustrates my point: https://www.baeldung.com/java-
| builder-pattern#bd-classic-bui...
|
| Let's remove the category argument and you get this:
| Post post = new Post.Builder() .title("Java
| Builder Pattern") .text("Explaining how to
| implement the Builder Pattern in Java")
| .build();
|
| This builder is a more readable alternative to this:
| Post post = new Post("Java Builder Pattern", "Explaining
| how to implement the Builder Pattern in Java", null);
|
| But if Java supported named arguments and default values
| (the default would be null), this could just be:
| Post post = new Post(title: "Java Builder Pattern", text:
| "Explaining how to implement the Builder Pattern in
| Java");
| vips7L wrote:
| Funny part is that Java does have named parameters, but
| only for annotations!
| signal11 wrote:
| Design patterns _are_ language independent, but a lot of the
| ones many Java devs focus on are a bit meh.
|
| In a world with only assembly language, for instance, it's a
| bit like making a big deal about a "guarded repetition"
| pattern (aka a while loop).
|
| Eg in Lisps, a lot of patterns become one-liners. At that
| point these patterns become a "can you write decent Lisp"
| question[1].
|
| [1] https://mishadoff.com/blog/clojure-design-patterns/
| agumonkey wrote:
| What about the social / communication aspect ? Having a common
| vocabulary of pattern may help reduce cognitive load when
| reading others code. Just a soft opinion because I assume it's
| the reason frameworks and conventions help teamwork. Less per-
| context custom solutions.
| zelphirkalt wrote:
| It really depends. If under the guise of "best practices" and
| "patterns" a team creates an unmaintainable, not easily
| extensible mess, then all this community aspect was good for
| exactly nothing but shoulder patting. If instead pattern are
| used sparingly, where they actually make sense, then sure, it
| can help.
|
| We need to keep in mind, that the most composable concept in
| computer programming is the pure function (or maybe a
| mathematical "relation", if we want to abstract further). Not
| a mutating object. Not some constellation of objects that
| constitutes a pattern. Those are merely special cases.
|
| I am currently developing a GUI application. Most of the
| classes in my code are classes, that are custom widgets. The
| GUI framework is OOP, so that is kind of infectious for the
| rest of the code. Still I try to keep some stuff separately
| as pure functions. Probably will outsource more stuff like
| that into completely self sufficient functions. The only
| pattern I have so far in the whole application, is a
| mediator, which I use as a way to have objects register
| themselves as listeners to specific events and for other
| objects to send these events to anyone who will listen. That
| way objects don't need to know, which other objects are
| interested in learning about some event. Could I have built
| in some factories and whatnot? Surely I could have, but there
| would have been very little, if any benefit. Even the
| mediator only exists, because the GUI framework does not have
| a way to send events that include data, so I need a way to do
| that. Otherwise I could even get rid of that pattern as well.
|
| In this way pattern are useful for when you really need them,
| but these OOP pattern by themselves, without context, don't
| really have a value. No code becomes better by building in
| more patterns, unless the situation requires such a solution.
| svilen_dobrev wrote:
| the actual software design patterns, unbiased by
| language/particular-usage, are subtle. i would go as far as say
| that there are also "design-patterns"-usage patterns.. and
| those might be even more subtle. e.g. what is/constitutes
| "interpreter", and when to use one, and when/if one is being
| used behind-the-scenes. Sometimes it is a single piece that is
| easily pinpointable. Sometimes a whole (sub)system behaves like
| one (e.g. event-sourcing stuff) but it's not easily cut into
| this is this, that is that.
|
| But anyway, this site seems javascript/frontend wanna-bees
| oriented.. please don't take those tutorials as mantras-to-
| follow-at-any-rate. See if you can take the knowledge and move
| on.
|
| A very good book, besides the GoF one, is the "Organisational
| patterns book by James Coplien, Neil Harrison" [1]. It contains
| some of the GoF *plus* all the non-technical ones, and they are
| bundled together - as software making is not just the coding..
| i have the list of those patterns essences (patlets) extracted,
| here the link -
| https://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patle...
|
| edit: it's from ~2003-5 and images are missing. May need to
| scan them from the book. Closest i found is [2], at least to
| get some idea
|
| [1] http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/
|
| [2] https://www.scrumbook.org/book-outline/history-of-the-
| patter...
| palata wrote:
| I see it as a common vocabulary to talk about tools. It's
| simpler to say "I made a singleton" than to describe it.
|
| Just like we have words for a nail, a screw, a hammer. If you
| had to say "I used a tool that I find works well with nails",
| that would be annoying and ambiguous.
|
| Now of course, if you quickly screwed something with your
| swiss-army knife and a junior came and told you that this is
| wrong, because you should _always_ use a proper screwdriver,
| and therefore you should rent a car and drive 30min to go buy
| it right now, you would kindly tell them to fuck off. Doesn 't
| mean that there is no value in the concept of a screwdriver
| itself.
| Yokohiii wrote:
| You point out the cultural issue that this creates and sweep
| it under the rug, violently.
|
| The thought model complicates the process of writing new
| code, "what pattern do i need here?" and the perception of
| existing code, "oh this is pattern X, why isn't that
| communicated clearly?". The truth is that design patterns are
| at best stagnant in quality and quantity over time (GoF is
| over 30 years old!), but the quantity and quality of problems
| is infinite.
|
| I've thought in patterns quite some time in my early career.
| With my colleague back then everything was an pattern and we
| were kind of in sync with that approach. But it quickly falls
| apart if you have peers that are less try hard on it. You can
| spend days, weeks, months to study design patterns and then
| have to explain it to someone in 5 minutes that simply
| doesn't care. I can't blame anyone to not care, so that has
| to be accounted for.
|
| I think the common language argument is tempting, but also
| too stressed. Good and useful programming knowledge is bound
| by reality. An integer is a indisputable thing that is always
| useful. A "singleton" is just a fancy rephrasing of "global
| state".
| palata wrote:
| I did not mean "everybody has to learn the vocabulary". I
| meant the opposite, actually: it's fine not to know the
| word for the tool (I don't enjoy reading about patterns
| just to learn about patterns, it's not my thing at all).
|
| Say I build a tool that makes it easier for me to drive a
| nail and call it a "Naildriver". If I show it to a
| colleague, they may be able to tell me "oh, this is
| generally called a hammer!". Maybe they will even tell me
| how I may improve my hammer, because they happen to like to
| learn about hammers in their free time. Or maybe now that
| they said it's a known concept, I will enjoy reading about
| hammers online (doesn't mean I will now read the entire
| encyclopedia of tools).
|
| The fact that there is a name for the concept ("it's called
| a hammer") does not say you have to know the word. It's
| just useful to have a word for it, because then we can
| reference it in discussions and share knowledge about it
| more easily.
| TINJ wrote:
| > 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.
|
| Isn't this called 'dynamic programming'? It's actually a habit
| people should pick up when grinding leetcode.
| viraptor wrote:
| No, dynamic programming is when you split your bigger problem
| into a smaller one + 1 step to get to your bigger size. Then
| apply that recursively until you solve the trivial problem at
| the end and get back the answer for your original problem
| size.
| arethuza wrote:
| If you already have Sets handy - why not use the Set
| Intersection? (Assuming the Set implementation has that
| capability).
| zelphirkalt wrote:
| Putting both contents (lists, arrays, whatever you have)
| into sets, and then calculating the intersection might be
| more expensive than building the intersected set right away
| sourcing both non-set contents, I imagine. Though it would
| probably be easier to read and understand. But that can be
| solved by naming of functions that process the 2 non-set
| things.
| viraptor wrote:
| I wouldn't say it's cringe. A factory is a factory. Calling it
| that in the code may not be the best idea, but having the
| shared vocabulary is nice. Basically, patterns work well when
| they're descriptive rather than prescriptive.
|
| There are two cases that are unique though: state machines and
| visitors are so much things on their own, that you'll use those
| names almost every time you run into the pattern.
| microtherion wrote:
| > A factory is a factory.
|
| Yes, but what about factory factories?
| https://factoryfactoryfactory.net
| zelphirkalt wrote:
| The visitor pattern is my go to example for patterns, that
| you don't really need, when you have a language that has
| first class functions, which implies among other things, that
| you can pass functions as arguments, like you can pass
| anything else.
|
| The magical "visitor" pattern becomes nothing more than
| simple callback passing or passing a function, which is one
| of the most natural things to do in a modern programming
| language.
|
| State machines at least are useful as a conceptual thing, to
| find a way to think about how one solves a problem, no matter
| how they are ultimately implemented in the end.
| vips7L wrote:
| I've always seen the visitor pattern as a poor-mans pattern
| matching. How do you solve the same thing with callbacks?
| DHRicoF wrote:
| For your example, if both lists are small enough, the constant
| factor on the cost of creating the hashmap eliminates any
| advantage you could have. Anyway, it's not like most places
| were I've seen a nested loop used for search the developer had
| cared. Today I am in a bad mood.
|
| I have to touch some of the most unnerving modules in a legacy
| project and everything is a trap. Lot's of similar repeated
| code with ugly patterns and some big brain trying to hide the
| ugliness with layers and layers of indirections and
| inheritance, and calling it clean because there is a factory
| class. The biggest joke? each implementation have a different
| interface for key methods, so later you to check what instance
| got created.
|
| I want to keel myself. Anyone could assist me in a seppuku?
| sureglymop wrote:
| Don't kill yourself. Stop and leave. Every day you will build
| up a tiny bit more resentment and then first you will become
| more cynical but eventually you will burn out. Be proactive
| and leave this behind, move on with life.
| Izkata wrote:
| > 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.
|
| This is a "hash join" in relational databases. You can see it
| in the query planner output of at least postgres.
| Jaxan wrote:
| > Very useful pattern but I don't believe it has a name.
|
| This is an instance of "use the right data structure for the
| job". To me it has little to do with architectural design
| (where design patterns live), but it has to do with algorithmic
| design.
| pajtai wrote:
| Looks great. Wish it had a table of contents. Am I missing it?
| rswail wrote:
| 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 wrote:
| 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 wrote:
| This looks like an excellent resource for interview preparation.
| Bookmarked.
| dkersten wrote:
| 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.
| bingemaker wrote:
| Looks more or less like GoF? Maybe compressing files and
| optimizing 3rd party js files are not patterns.
| emaro wrote:
| 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 wrote:
| 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 wrote:
| Somewhat true - I usually find that in these languages the
| patterns are there they are just less obvious.
| ssrc wrote:
| 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.
| mrsmrtss wrote:
| How do optional inheritance and namespaces (which you can
| ignore to use a single global namespace) make a language
| inflexible? If anything, these traits make your language more
| powerful, not less.
| jonkoops wrote:
| This is a common thing I see when developers that come from an
| OOP enterprise environment familiar with Java, C#, etc. do
| JavaScript, they try to use all the same patterns, default to
| classes for everything. It just doesn't fit the language.
| threetonesun wrote:
| It was fascinating to me to see JavaScript add the class
| keyword, have it be widely adopted thanks to React, then just
| a few years later seeing `class` in JavaScript code is, as
| you said, a clear sign a Java/C# dev was here.
| arscan wrote:
| I haven't done JavaScript in a long while, is using 'class'
| not a favored way of writing JS these days? I wrote JS
| heavily pre-class, and never really got comfortable using
| it before switching my focus to other languages.
| gcau wrote:
| The poster you're replying to is plain wrong, using
| "class" is ubiquitously common in the
| javascript/typescript world, it's the idiomatic way to
| create classes, and it has better semantics than trying
| to use prototypes. You might compile away the class
| keyword for compatibility, though.
| kbolino wrote:
| But you don't have to do _either_ of those things. There
| 's a third way, with functions and bare objects. I'm not
| sure that's what GP meant, but a lot of the JS I've
| written (which tends to be for the browser, mostly
| vanilla, and quick-and-dirty, to be fair) never touches
| classes or prototypes. The JSON data being
| produced/consumed is just a bag of fields, the operations
| on the document are just top-level functions, events get
| handled in callback closures, responses to HTTP requests
| get handled with promises, etc. Sprinkle in some JSDoc
| comments and you even get fairly workable autocomplete
| suggestions. Of course, the web APIs are built on
| prototypes/classes, so it's not like they're totally
| absent. But with things like data attributes,
| querySelector, and HTML templates, the usual needs for my
| own code to be OOP (or even structs-with-methods a la
| Go/Rust) just don't emerge that much.
| baq wrote:
| design patterns are a language, it's just that the programming
| language they're being implemented in doesn't support them
| natively.
|
| e.g. observer pattern in java is what, [array of
| functions].forEach() in js? not worth calling that by name.
| another example, singletons - in Python, it's just a module
| (caveats apply obviously, but if we apply them, some also apply
| in java).
|
| this is why designing a minimal language to make it 'simple' is
| misguided: you'll end up having to reinvent the design pattern
| language anyway. there are good reasons to design a simple
| language, but simple for the sake of simple is missing the
| point.
| layer8 wrote:
| I would put it slightly differently: Patterns (including anti-
| patterns) happen whether you call them such or not. Any
| developer will sooner or later come up with patterns like
| Adapter or Builder or Composite or Iterator. In that sense,
| patterns are not invented, but discovered. The benefit of
| design patterns is to be able to communicate these discovered
| patterns, and to define agreed names for them, so that you
| don't have to describe the pattern each time you talk to
| another developer, but can refer to it by a well-understood
| name. (Or when not yet well-understood, can refer to the
| corresponding pattern description.) It extends the language we
| use to talk about software design.
|
| The point of design patterns is less about the individual
| patterns, than about having "design pattern" as a general
| concept of coding patterns relevant to software design, that
| you name and describe because they keep reoccurring.
| zeroq wrote:
| I would go even further.
|
| For me design patterns are more of vocabulary than a tool.
|
| It's not about - hey I found this book and we'll be using
| these building block from now on - rather, it's about having
| words that everyone immediately recognizes and associate with
| exact same ideas.
| naasking wrote:
| Yes and no. Some patterns exist because the language isn't
| expressive enough. This is one reason why the patterns made
| sense in the OP's .NET programs, but made less sense in JS.
| JS simply doesn't require as much ceremony for some things
| because it's dynamically typed and reflection kind of comes
| for free.
| moron4hire wrote:
| I would say that reflection in JS is _terrible_ compared to
| .NET. You can only just barely figure out what is in an
| _object_ , but it's a hell of a time figuring out what any
| of those things can do. I wouldn't so much as call what JS
| does "reflection" any more than "making objects out of
| poorly implemented hashmaps."
| actionfromafar wrote:
| "Javascript" === "Chaotic neutral lisp"
| moron4hire wrote:
| Yeah, I don't like the comparisons of JS to Lisp, because
| I think they mostly center on the existance of the map
| and filter methods of Array. To me, that's just not what
| Lisp is about. C# has map/filter/etc, and we don't say C#
| is-a Lisp.
|
| And there are many other such features that were once
| unique/unique-ish to Lisp, that were major selling points
| for using Lisp at the time, but are now pretty common
| across a very diverse set of languages. Garbage
| collection being one. Higher order functions being
| another.
|
| Lisp's big idea that stuck to being unique to Lisp is
| homoiconicity. It's the one thing that continues to be
| valuable enough to warrant using Lisp, despite everything
| else that has been stolen and copied.
|
| Of course, not that I ever used Common Lisp, and not that
| I use Racket anymore. I enjoyed the hell out of
| programming in Racket. Up until the point I needed to
| access a database. Man, who's got time for that
| Jankasarous Rex? But I really would love a homoiconic
| language for the .NET CLR. That would be pretty sweet.
| socalgal2 wrote:
| lisp to me is (1) the language itself is a lists of lists
| (2) defmacro lets you manipulate those lists of list at
| compile time. JS doesn't this do either of these at all
| AFAICT and so is absolutely nothing like lisp.
|
| Most lisp programs are about writing DSLs using defmacro.
|
| What's the similarity to lisp except that both are
| programming languages?
| no_wizard wrote:
| >You can only just barely figure out what is in an object
|
| There's a couple really well documented and understood
| ways of doing this in the language. I'm not sure what
| you're specifically referencing without more information.
|
| >I wouldn't so much as call what JS does "reflection" any
| more than "making objects out of poorly implemented
| hashmaps."
|
| Is this anymore different than .NET deriving everything
| from a base `System.Object`[0] type?
|
| Also, what is missing in JS reflection wise that you
| can't do that would make sense for its environment?
| (namely, this excludes compile time reflection stuff I
| know .NET can do, it wouldn't make sense for a scripting
| language as it currently is)
|
| [0]: https://learn.microsoft.com/en-
| us/dotnet/api/system.object?v...
| moron4hire wrote:
| In JavaScript, one can tell if an object has a method by
| iterating over the object keys and seeing if the value is
| `instanceof Function`.
|
| But that actually tells you very little. You _might_ be
| able to tell that it takes a certain number of
| parameters, if you are running on a system that
| implements Function.prototype.length. But you will have
| no way of telling what the arguments to those parameters
| should be, or even what they were even named. There 's no
| way to tell if the function is a method that needs to be
| `.call()`ed with a value for "this", or if it's just a
| function that happens to live in an object literal, or if
| it's actually a class constructor that must be called
| with `new`! And there is certainly no way to tell whether
| the function returns a value, say nothing about the type
| of value it returns.
|
| With .NET reflection, I can do ask those things I lament
| missing in JS, and guarantee the type safeness of it.
| daxfohl wrote:
| Yeah, I've seen (okay, and been responsible for) a lot of "the
| road to hell is paved with good intentions" due to jumping to
| some pattern or other because, well, it _feels_ like the right
| thing to do. It makes the code cleaner at delivery time, and is
| usually very intuitive _when the design is fresh in your mind_.
| But IME it doesn 't take long before that freshness goes away,
| and the next time you look at it (let alone anyone else) you
| find it hard to follow the logic anymore. Usually
| "constructing" the pattern and "executing" the pattern are in
| different places in the code, and there's not a straightforward
| way to mentally step through one without continually cross-
| referencing the other. At some point you wish you'd just
| written one long switch block that you could step through.
|
| And that's all before new requirements that break the pattern,
| or other engineers that don't have time to grok the design and
| hack in something that looks like a switch block for their
| thing, which eventually takes over most of the code anyway.
| ozim wrote:
| I see a lot of comments about how patterns are useless from
| people writing toy apps or at least ones that never had to deal
| with really enterprise scale stuff. So for me they are like
| people building a shed screaming at people building sky
| scrapers that no one ever needs to pour so much concrete to
| form a foundation.
|
| Parent comment is not like that.
| khannn wrote:
| People were shifted from Java to Javascript and kept the Java
| patterns and maybe the organization had standards requiring
| their use.
| css_apologist wrote:
| 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 wrote:
| "Design Patterns are a sign of missing language features".
|
| https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeature...
|
| https://norvig.com/design-patterns/design-patterns.pdf
|
| https://medium.com/@letsCodeDevelopers/your-design-patterns-...
| css_apologist wrote:
| 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 wrote:
| although this article does get me thinking of documenting the
| "patterns" i use, and why.
| dominicrose wrote:
| 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 wrote:
| 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 wrote:
| Did this get an update? It's been around for a while.
| verdverm wrote:
| 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
___________________________________________________________________
(page generated 2025-12-11 23:01 UTC)