Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patterns.dev

patterns.dev

Post reply on HN
Print view View original

81–90 of 158 posts

Re: Patterns.dev

#81

Post by skydhash »

emaro wrote: post #79

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…

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.

Re: Patterns.dev

#82

Post by jonkoops »

emaro wrote: post #79

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…

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.

Re: Patterns.dev

#83

Post by [deleted] »

no_wizard wrote: post #22
nl wrote: post #12

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.

YUI was ahead of its time as well

[deleted]

Re: Patterns.dev

#84

Post by lelandfe »

culi wrote: post #19
8cvor6j844qw_d6 wrote: post #6

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-...

I posted this elsewhere in this thread: https://component.gallery/ Great meta resource for building UI components.

Design patterns and component libraries are a bit related but they're pretty different concerns ultimately.

Re: Patterns.dev

#85

Post by baq »

emaro wrote: post #79

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…

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.

Re: Patterns.dev

#86

Post by gm678 »

fiddlerwoaroof wrote: post #14

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)

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.

Re: Patterns.dev

#89

Post by css_apologist »

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.

Re: Patterns.dev

#90

Post by css_apologist »

css_apologist wrote: post #89

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 g…

although this article does get me thinking of documenting the “patterns” i use, and why.
Post reply on HN