On Growing: Lessons from the Story of WeChat - <AUTHOR> https://blog.ycombinator.com/lessons-from-wechat/ <comment><USER2> Some secret weapons this article did not mention

1\. Allen Zhang (Founder of WeChat) was the author of once popular desktop email client: Foxmail, and later Tencent acquired it, Zhang refactored a new version of web mail on mail.qq.com.

In order to support Microsoft Exchange protocol, Zhang and his team reversed engineered it, this was later the foundation of Wechat's binary protocol design, in Zhang's words, it's magnitudes faster and robust than your XMPP copycat. It's designed to work well in extremely poor signal coverage area with only GPRS 2G online access.

2\. Wechant literally stole telecom's SMS cake. Tencent put lots of effort striking deals with telecoms, ordinary IM startups might simply be blocked or QoS'd to death.

3\. Tecent also pushed very hard to third-party Android ROM publishers to pre- install Wechat. It's like 2-5 RMB per new user acquisition and the app can not be deleted unless rooted. Tecent also negotiated to made sure Wechat app always stays in memory and can not be easily killed so push messages can be received, Be noted, because Google was fully stripped in all legit Android phones in China, there's no Google Play or GCM service, some other IM competitors are struggling to have basic message receiving capabilities.

4\. Wechat is a lock-in mega app. Little known fact is it got a Tecent Browser (X5) fully builtin, it's an outdated Chromium build and its behavior is kinda headache to debug compared to othe mobile browsers like Chrome or Mobile Safari, lots of customised JS bridges and restrictions.

The evil part is that every link you view in wechat must renders exclusively in X5. E.g. if you open a youtube page, it renders in webview in wechat, if you have youtube app installed and wanna view the URL link in app, you have to click for the wechat menu, open the webpage in system browser, so your waste your data bandwidth for the second time and opens the exact webpage, and click "Open in App".

This ensures engagement times.

5\. Wechat blocks competitor URLs for obvious reasons, e.g. *.taobao.com domain since day 1 because "the link looks malicious and may harm your device". It force users to choose Tencent equivalents(JingDong).

<comment><USER3> Even if the team is lean the article made the product seem very heavy, all-in- one. I have a hard time seeing success with that in the west these days. Feature-filled communities was definitely a big thing once.

I get that a partnered article won't cover these kinds of practices. However it does leave a bad taste in my mouth to see this unapologetic praise in the article for what seems to be a monolithic monopoly play.

<comment><USER4> WeChat actually feels very light and has a way better UI than WhatsApp and Facebook Chat - though they rather slowly now copy it from WeChat. Crazy times, as now US has to copy the Chinese competition which is now like 2-3 years ahead.

<comment><USER5> it's ahead only if you think those markets are comparable, people outside China don't desire this functinality since they have many other good options, people in China has horrible options so WeChat looks actually pretty good to them and they use additional functionality on top of chat/wall

I lived in China since beginning of growth of WeChat and could see it in front of my eyes, in beginning it was very simple messenger and they kept growing userbase and adding more and more functionality, though you end up being locked in in their ecosystem, as was mentioned taobao links are blocked and those options under Wallet section are mostly not the best value, so I pretty much avoided those added functionality. Heck I rather top up electricity through Alipay, since it was easier than WeChat or some companies didn't have contracts with them.

anyway back to your comment, you say they are ahead of Whatsapp and Facebook, but please tell me in what exactly they are ahead, in selling tickets, paying utilities and sending money through messenger app? do people outside China desire this? if people don't desire it, they are not ahead, people in west have fast wire transfers, can pay pretty much anywhere in card so there is no necessity for such functionality, I could go on and on if you tell me in what area they are exactly ahead since I lived in China for years and I live in west so I can compare

Yes, WeChat is extremely convenient for life in China. Is it convenient and good app for life outside China? Hell no, I don't want and I don't need those features from Messenger, since we don't have blocked internet I can visit whatever website I want and use their services without state protectionism.

</comment></comment></comment></comment><comment><USER6> I remember watching this video a while ago by Nathan Freitas on the ability of the Chinese government to inspect, censor and control private communications through cooperation with apps like WeChat: [https://www.youtube.com/watch?v=KEJGqNf2rgk](https://www.youtube.com/watch?v=KEJGqNf2rgk)

In it, Nathan brings up a very alarming point in that Chinese communication apps like WeChat have _extremely_ robust inspection and censorship features built-in to the app, that were originally designed to be used by the Chinese government. Even though these features might not _yet_ be enabled for WeChat users in countries outside of China, there is very little stopping an authoritarian government in a different state with widespread WeChat adoption from making use of these features if they just negotiated the right deals with TenCent, instantly gaining unprecedented powers in shaping private communications of its citizens, which can be an exceptionally powerful tool in detecting and quelling dissent.

By exporting WeChat, China not just exporting a chat app, but also exporting a vital function of its Great Firewall: it's ability to control communications between citizens within it. Even for democratic states like India, where WeChat is starting to gain a foothold, this could pose a very real threat to freedom of speech if WeChat were ever to become dominant, and greatly increases the potential power of government should they ever want to overreach for it.

<comment><USER7> >By exporting WeChat, China not just exporting a chat app, but also exporting a vital function of its Great Firewall: it's ability to control communications between citizens within it. Even for democratic states like India, where WeChat is starting to gain a foothold, this could pose a very real threat to freedom of speech if WeChat were ever to become dominant, and greatly increases the potential power of government should they ever want to overreach for it.

Reminds me of Facebook, Twitter, Google.

<comment><USER6> Absolutely, between NSA's XKeyscore and all the for-profit corporate surveillance performed regularly in western companies, the only factors regular consumers have control over is a matter of what degree of surveillance they're willing to accept and which nation-states they would consider their adversary.

This was one of the sentiments raised in Nathan's talk, and the aim of the talk was not to just aimlessly bash and scapegoat China and WeChat, but rather to suggest taking a hard look at ourselves and the choices we're making in terms of becoming complacent to or outright enabling authoritarianism, because there's a frightening number of parallels that can be drawn between China and WeChat and the US government and US tech corporations.

</comment></comment></comment><comment><USER8> "WeChat defies the popular belief that growth is all about user growth. Instead they think about growth as increasing value (e.g., the number of tasks WeChat can do in the daily lives of users).

Unlike other social products, WeChat does not only measure growth by number of users or messages sent. Instead they also focus on measuring how deeply is the product engaged in every aspect of daily life (e.g., the number of tasks WeChat can help with in a day)."

100 times _this_. I can't think of a single large Western consumer software company who can actually think like that.

It has become a commonplace that WeChat is incredible, and everyone over here wants to build it. But solving that problem is hard. _Really_ hard.

<comment><USER9> > 100 times this. I can't think of a single large Western consumer software > company who can actually think like that.

I'm pretty sure execs from Google/Facebook/Apple think like this, it's just you don't read about it on TechCrunch, nor do they publicize it to their investors.

<comment><USER10> I would disagree with this. Facebook definitely has no problem creating an endless stream of content with >5% ad density.

<comment><USER11> But WeChat with all it's diverse functionality gets used as much as Facebook across their own portfolio.

> use the app an average of 50+ minutes, and 9 to 11 separate times, per day2. > To put that in context, it is the same as the "combined time" users spend > across a portfolio of Facebook apps

<comment><AUTHOR> 50% of WeChat users use it for 90 mins. Also the team really focuses on user efficiency -I.e.,, completing the task quickly and in the most efficient way

</comment></comment></comment></comment></comment><comment><USER12> Former WeChat PM here. Good analysis.

But annoyed that mot western coverage of the app focuses on the breadth of features/platform stuff and belies the many ways that it's an extremely solid messaging app compared to many.

The choices made in the fundamentals (adding friends, creating groups, notifications) are all super well thought out. People using it will use it for communicating with strangers and conducting business, something you don't see in any messaging app in the US. The core messaging features are versatile and ultilitarian. And it's chock full of power user features like tags, notes, pinning threads, etc. The core team had spent 10 years working on email clients and services before embarking on it and it shows. This is the foundation the rest was built on.

<comment><USER13> Your WeChat experience would be interesting, we can learn so much from it, clearly the app took over the Chinese ecosystem, so you guys did a lot of things right (which nobody has able to replicate).

I would love to talk to you about it!

</comment></comment><comment><USER14> _> We partnered up with China Tech Insights, a research group within Tencent (WeChat's parent company) to understand how WeChat drives its 889 Million monthly active users..._

I've always wondered if WeChat benefitted from something particular to the Chinese context, for example, favorable government support.[1] This is not exactly the sort of stellar investigative methodology that's going to answer that question. In fact the article makes it sounds like it's all general business and design principles, yet fails to address why WeChat's success is specific to China.

[1] "A successful stunt during last year's celebration of Chinese New Year's Eve saw CCTV, the official state broadcaster, offer millions of dollars in cash rewards to WeChat users who shook their phones on cue." [http://www.economist.com/news/business/21703428-chinas- wecha...](http://www.economist.com/news/business/21703428-chinas-wechat-shows- way-social-medias-future-wechats-world)

<comment><AUTHOR> I think WeChat's specific success in China was really driven by WeChat payments and QR code - both of which failed in the US. These two features were critical to support so many use cases that WeChat enables today (payments, peer to peer transfers, offline to online service). Yes the Chinese New Year helped garner interest and a lot of people use WeChat to send red packets, they also connected their bank accounts and started using it for payments. This is again in line with how WeChat launches every feature. They try to launch it in groups rather than getting each individual user to try it separately.

<comment><USER15> "WeChat's specific success in China was really driven by WeChat payments and QR code"

WeChat was successful (in DAU/MAU) way before WeChat payments existed. WeChat payments couldn't have succeeded without the existing user base.

<comment><AUTHOR> Before they turned on red packets they had only 300M MAUs. They do claim that red packets was a critical growth lever for them for new users

</comment></comment></comment></comment><comment><USER16> As a China-approved messenger application would anyone trust this as their primary mode of communication?

This is not meant to be snarky or biased. Considering the control China has on citizen communication (eg the great firewall), what guarantee does anyone using the app have that all data isn't being fed through the Chinese version of the NSA?

Also: how much of the growth can be attributed to less competition in the Chinese app market?

<comment><USER17> There is ridiculous amount of competition an innovation in the Chinese app market. Every time I visit China, I'm surprised by something new the folks can do with mobile.

That innovation is starting to spill into India with Chinese company investments. A year ago, mobile payments in small shops and businesses were ubiquitous only in China, now they're proliferating in Indian cities too.

The Western markets are quite tame in comparison.

<comment><USER18> Mobile payments aren't so big in the west because they aren't so necessary. Almost every shop in the USA takes cards, the same isn't true in china or many developing markets, but everyone has a phone so let's use the camera and QR codes to get around our lack of infrastructure.

<comment><USER15> There's something else going on as well, though. People in China will now use Alipay/WeChat to pay at (for example) restaurants even though they have a bank card, and the restaurant can take bank cards. The restaurants increasingly have specialised hardware (maybe part of the same POS terminal that takes bank cards) and aren't using a smartphone to process customers' mobile payments.

<comment><USER18> True, but is that anymore convenient than card tap? Also, We are seeing QR payments happening in the states also (like at Starbucks) though I honestly don't see the point.

<comment><USER15> I've not seen contactless card payments in China. I imagine both businesses and consumers would be worried about fraud. Quick payments with a mobile wallet (where the retailer scans a dynamic QR code on your phone) feel safer, as you need to explicitly go to that screen, and you get immediate notification on any transaction on your account.

</comment></comment></comment></comment></comment></comment><comment><USER19> > Tencent was already one of China's top internet companies in 2010, and the > biggest social company even before WeChat was launched.

> At the time, Tencent's products had ~650M monthly active Instant Messenger > accounts.

Lesson 1: Start with 650m active users

<comment><USER20> No. WeChat started from scratch. None of the QQ users were ported to WeChat on day 1. You had to create a different account based on your mobile phone number just like any other mobile apps. You can, of course, use QQ credentials to login AFTER you created your WeChat account but you still have to create a WeChat account first and then link it to QQ. None of 650MM users were automatically created initially AFAIK. It was a "bold move" to cannibalize Tencent's own users in a way, after all.

<comment><AUTHOR> Agreed. You could not import QQ contacts and in fact you could only add QQ contacts who were already on WeChat as "friends". So you had to discover WeChat on your own and could not invite a QQ user who had not yet discovered WeChat to join as a friend. WeChat did not ever push import all contacts from QQ to WeChat.

</comment></comment></comment><comment><USER21> Basically : They design for value for users instead of, and they add features relentlessly instead of hitting product-market fit and stopping development until a competitor comes out with something good (looking at FB).

This is probably due to the high level of competition and limited marketshare the firms in China are looking at. FB and Western firms want to rule the world, because they can, so they are still focusing on growth with iniciatives like internet.org. Chinese firms know their market is China, and they understand China, and it will be hard for them to export, so when they grow as big as WeChat the options are more limited.

Their option was to build a whole ecosystem around it that could capture maximum user value. They also seem to prize their users religiously, which is great for them. But it might not have happened for them that way either if they were hopeful of capturing the entire world.

</comment><comment><USER22> Although WeChat has less users than Facebook Messenger and WhatsApp, WeChat is lightyears ahead of what the west can offer , in terms of product. It has many many useful features and is smooth, reliable. Even WhatsApp and Messenger are copying WeChat. One of the examples is WeChat payment. You can send money to any contact as a text message.

<comment><USER23> you can make payments in messenger too...

[https://www.facebook.com/help/863171203733904/](https://www.facebook.com/help/863171203733904/)

<comment><USER24> `You can send or receive money in Messenger (example: send your friend $10 for lunch or receive $500 from your roommate for rent) after you add a debit card issued by a US bank to your account.`

It requires you to bind your account with a debit card. I am using WeChat for years but I never attach my debit card to it, because I do not have a China debit card. When I need e-money, I just ask my family or give my friends some cash and they transfer e-money to me. That's all. Then I can use the e-money for offline shopping, online shopping, sending Hongbao (as gift-card). I do not understand why debit card is required.

<comment><USER25> So where is that e-money coming from? You must be linking something... a bank account perhaps?

<comment><USER20> Yes, WeChat wallet serves as a non-interest bearing escrow. So someone somehow has to link bank account/debit cards to infuse money into WeChat network first. You obviously need to link to your bank account in order to cash the balance out of WeChat. But given "90%" daily payment use-cases that WeChat covers, you are more likely to spend the balance somewhere than cash them out.

</comment></comment></comment></comment></comment><comment><USER20> > Lesson 1: Build Your Own Competition. This lesson is reminiscent of Amazon's > move ... and Uber's move from town cars to UberX. If you don't create a > culture of disrupting yourself, then a competitor is likely to disrupt you.

That is more or less what Travis Kalanick explained to the driver Kamel their decision to introduce UberX after UberBlack during that controversial video shot in an Uber ride 2 month ago.[1]

[1]: [https://www.recode.net/2017/2/28/14766964/video-uber- travis-...](https://www.recode.net/2017/2/28/14766964/video-uber-travis- kalanick-driver-argument)

</comment><comment><USER26> Distilled down: fast execution with small tight dev teams, ruthless focus on adding direct user value/utility to every new feature (and choosing insightful metrics to validate this), management keeping their greed in check and an overriding culture/philosophy that good product is driven from understanding and respecting your users (don't waste their time, do value their attention, don't overcomplicate, don't needlessly monetise). Oh and incredible discipline and inventiveness in devising viral growth loops that don't break these rules.

Nice & inspiring.

</comment><comment><USER27> > Lesson 1: Build Your Own Competition

Imagine cable/media companies or Blockbuster did what Tencent did with WeChat and Amazon did with Kindle? Focus on product development even if it means potentially cannibalizing you're existing business...

Instead Netflix and Amazon Prime Video are totally dominating the marketplace for online video content and the TV studios will soon rely more and more on their platforms, platforms that are now spending billions to compete with them on content creation.

Amazon is also publishing books too, competing with the bigger publishers to some extent [1]. They should consider going harder into this space like they did with movie/TV production.

This is a great aspect of tech companies that 'traditional' ones continually overlook. Being future looking not protective.

[1] [https://kdp.amazon.com/signin?language=en_US](https://kdp.amazon.com/signin?language=en_US)

</comment><comment><USER28> These are good lessons, but we have to consider whether a piece of WeChat's growth has to do with government backing. It's much easier to design for increasing user value if you don't have to worry about a marketing strategy.

I'm not making a judgment on that - I'm just saying that it might not be applicable to all startups.

<comment><AUTHOR> WeChat had a lot of competition from Chinese mobile-first messaging apps when they started. It was by no means easy for them to scale and drive user growth.

</comment></comment><comment><USER29> Having lived in China for 6 months I can say: if you build a mobile OS to just run WeChat embedded. It would work for 90% of what average users (so no, not you here on HN) want from a phone.

Seriously. you can message, voice chat, call, video call, order plane tickets, split bills, order stuff online, buy movie tickets, pay utility bills, share photo's like FB timewall, create publics chatrooms, pay in physical stores and so much more.

That app was ridiculous. Miles ahead of even the biggest dream of any app- central company in the Western world. They built up an entire ecosystem in one app.

Obviously, it drained a lot of battery on Android. But Android itself is miles behind iOS anyway, since there is no Google in China and Android today is pretty much an empty shell without GPlay Services / Framework.

<comment><USER30> > Seriously. you can message, voice chat, call, video call, order plane > tickets, split bills, order stuff online, buy movie tickets, pay utility > bills, share photo's like FB timewall, create publics chatrooms, pay in > physical stores and so much more.

...All of that is handled within the app's runtime? (I would find it incredibly surprising if it did not hand off at least some of those to the phone layer.)

Or if it is - I would be surprised if what you describe doesn't already exist there.

<comment><USER29> Some of the features I encountered where just webpages being loaded inside the app. Like the ticket buying. Possibly just using Android Webview. Except it did perfectly integrate with the (built in) Payment service in the app.

</comment></comment></comment><comment><USER31> It really depends on your use cases. WeChat fits well in China as it is building a product exactly adding value for China culture and lifestyle there.

You can make utilities payment via WeChat, but I would much prefer to have a platform automate this for me and not part of an IM.

The West has been following the UNIX philosophy of doing 1 thing and does it very well.

Perhaps WeChat is not just an app, but an eco-system. As for UX on strictly IM functionality, I would prefer WhatsApp, FB Messenger, Telegram etc as it is much "lean" and lightweight to use.

I personally don't think WeChat can be successfully replicate their model to everywhere in the world.

However, a lesson to learn for everyone (including WeChat), build local product. Builds product that fits everyone's need accommodating their culture and lifestyle.

<comment><USER32> Is it really a "Western"-thing or more of a Silicon Valley thing?

I really think Google could have created the ultimate chat app... but I guess they are "creating their own competition."

<comment><USER18> It's really a western thing. Chinese like crowded pages with lots of functionality, they must feel very 热闹!!! The west prefers more distribution of functionality with simplicity so doing one thing is much more appealing to us.

<comment><USER32> But when I was visiting Italy and Greece, I noticed the sites most people viewed were also very crowded and busy.

<comment><USER18> Yes but not by choice. Besides, I've been to both Rome and Athens and didn't find either to be oarcicularly crowded compared to a Chinese tourist place.

</comment></comment></comment></comment></comment><comment><USER33> Unlike Facebook, using wechat on desktop is a pain. Also doesn't support multiple device.

<comment><USER15> "Also doesn't support multiple device."

Not strictly true. You can log in a second device (e.g. web browser, tablet client, desktop client) by scanning a QR code with your primary device.

My iPad is my secondary device. Not all messages are synced, but I can pick up my iPad to start or continue a conversation or do other stuff, without doing anything special. The full conversation history is only on my phone, though. The iPad only has the messages sent/received whilst I was actively using it.

</comment></comment><comment><USER34> There is one important spot the article misses to mention is its extremely great usability among different groups of people. People who are young or old, well-educated or poor, artistic or professional use WeChat as a communication tool.

Unlike many other apps who concentrate on serving young people, business people or colleagues, WeChat is the ultimate solution for me to talk with my classmates, my parents or even a courier who I just meet 3-minutes ago. This makes it stand out from just an app working above the operating system, but a common solution people on mobile just like phone call or messages. This makes WeChat special.

</comment><comment><USER10> > To summarize, the WeChat team found ways to be scrappy, compete with their > own products, built features that answered cultural needs and emphasized > group interactions and most of all they have relentlessly focused on > creating a simple tool that could extend into the hands of every mobile > consumer.

The summary misses the biggest lesson from the article! WeChat was able to get such amazing engagement and retention because it never attempted to milk a single facet for all it was worth. The model wasn't to maximize revenue before it broke the addiction.

</comment><comment><USER35> Now nobody talk about the "dating app" image wechat held in its early years, which brought it a lot of users.

<comment><AUTHOR> Yes. Shake and Message in a bottle features were used in that context in the early days.

</comment></comment><comment><USER36> Can something like WeChat work in the West? This is basically like an OS inside an app, you can book taxis, movie tickets, play games, send money etc. Having all the functionality integrated makes life easier, but comes at the cost of privacy : one company knows about your entire life.

<comment><USER22> Don't Google and Facebook know about your entire life already?

<comment><USER37> well yeah, but it doesn't mean that it is good in general

</comment></comment></comment><comment><USER30> I thought I remembered reading something about apple frowning on apps-within- apps?

I guess Wechat either sidesteps it by having everything be a 'profile' effectively just making it a chat app interfacing to other apps? Or maybe apple doesn't care about that restriction over there...?

</comment><comment><USER38> > Using voice messaging was strategic because the native mobile keyboard to > type Chinese characters at the time was not easy to use and consumers found > sending voice notes intuitive, personal and convenient for daily life.

this is amazing way of thinking around the problem

<comment><USER32> I find I use it more like the old Nextel days, where WeChat is essentially a type of walkie talkie.

</comment></comment><comment><USER39> is it bad that i got excited by the thought of high adoption rates of weechat (www.weechat.org) in china?

</comment><comment><USER5> TLDR Milestones - leave totalitarian government block all your competitors, be complacent and provide all your data to government, censor what people post on their public wall and in private messages as well

yeah, if someone is looking up to privy like this I would recommend moving to China or North Korea where they can try to release their another inspirited product

<comment><USER40> This is not a good comment for Hacker News—it contains more inflammation than information. We're hoping to optimize for signal/noise ratio here, which heads in the opposite direction. If you'd comment accordingly, we'd appreciate it.

Edit: unfortunately it looks like you've been posting plenty of unsubstantive and/or uncivil comments to Hacker News. We penalize accounts that do that and eventually ban them if they won't stop. Please (re-)read the site guidelines and post civilly and substantively, or not at all.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

<comment><USER5> are you sure you are not ABC (judging by nickname) who lived in China less than me and it's just here supporting their totalitarian government based on fantasies you read about China online without clue about real life in China? Because that's the case of ABCs, they know less about China than non-Chinese living there...

not sure what is not civil about my comments, I lived in China, I talk about Chinese app mentioned in article and provide what is behind real success of WeChat, which is not thanks to features they have, but thanks to government protection

<comment><USER32> So you are one of those bitter expats then (judging by your comments)?

<comment><USER5> It's hard to not be bitter, if you live in China for years as adult person and not some student enjoying parties and iresponsible youth years. The amount of ridiculous stuff you have to deal with every day (incompetent Chinese management in companies, unproductive Chinese coworkers, people blocking sidewalks and in general extremely selfish people anywhere you look, overcrowded subway, fighting to get to suburban bus and constant flow of people cutting the queue, toxic air, toxic food, dangerous roads, visa harassment, etc. etc.) is just unbearable after some time and eventually everyone will move away. It's not exactly country welcoming foreigners, which would explain why they have like 0.5% of population consisting of foreigners, now tell me other country with comparable population of foreigners.

But yeah, most of HN readers saw China only online and see how is it booming and stuff like that. Like look at amazing Beijing subway with many new modern nice and dandy lines, somehow everyone fail to see they are still at 50% level compared to any western city (in west you have roughly one line per 500K served population, in amazing Beijing 1mil sharing one line with no suburban trains or trams to supplement it). Same goes for their amazing HSR - omit the fact they stole German and Japanese technology, omit the fact their prices are more expensive than faster and more convenient flying in Europe and that they closed most of cheaper slower lines, so end result for people is to pay significantly more to get home.

Chinese gov propaganda department must be smiling reading comments on this website.</comment></comment></comment></comment></comment>


Ask HN: What were the online resources you used for patent searching? - <AUTHOR>

When you were bootstrapping, what were the online resources you used for patent searching?
I've found these:
http://ep.espacenet.com/?locale=EN_ep
http://patft.uspto.gov/
https://www.google.com/?tabm=pts&hl=en
http://www.patentarcade.com/p/patents.html
http://www.freepatentsonline.com/
http://www.patexia.com/ip-research
Any ways of tackling this different from these?:
http://www.ehow.com/how_4899582_patent-game-idea.html
http://www.ehow.com/how_10054413_game-patented.html
http://www.ehow.com/how_5798493_patent-ideas-new-game-inventions.html
I'm going to my local patent office to file a provisional patent for the first time. Before I talk to a lawyer I'm going to use as much resources online and come prepared.
Do you have any tips? <comment><USER2> I just got done filling for my first patent. It's a great feeling (when your finally done) and I wish you the best of luck. My patent lawyer told me to use <http://scholar.google.com/> she said its what the patent office is now using to search for prior art.</comment>


Breakup Notifier Reinstated by Facebook - <AUTHOR> http://www.breakupnotifier.com/?

<comment><USER2> Why?

The only difference I see is that friends are no longer displayed, instead it just lets me select gender and status of friends to watch.

</comment><comment><USER3> FYI: It looks like there's a rendering bug in Chrome that pushes most of the interesting content below the fold: <https://skitch.com/gbelote/r12ay/breakup- notifier></comment>


What's a good functional language for desktop scripting (like Python)? - <AUTHOR>

I'd like to get some time in with a fairly pure functional language and I'm not sure what I should be using for practice. I've played a little with Scheme and Erlang but neither one seem to have the chutzpah I need for doing Python-like scripting/programming. Maybe I'm doing it wrong?<p>(EDIT: Removed Windows from the title because I want it to be cross platform) <comment><USER2> Various parts of _Real World Haskell_ show how to do scripting-type tasks using Haskell, especially chapters 7 and 9 (linked below, but they'll make more sense if you also read the preceding chapters):

<http://book.realworldhaskell.org/read/io.html>

[http://book.realworldhaskell.org/read/io-case-study-a- librar...](http://book.realworldhaskell.org/read/io-case-study-a-library-for- searching-the-filesystem.html)

<comment><AUTHOR> Thanks! Any libraries for web oriented tasks?

<comment><USER2> There's a big list at [http://www.haskell.org/haskellwiki/Applications_and_librarie...](http://www.haskell.org/haskellwiki/Applications_and_libraries/Web_programming)

I haven't used any of these, and none of them look super-compelling to me, though HAppS seems fairly mature and full-featured.</comment></comment></comment>


Amazon wins FAA approval for Prime Air drone delivery fleet - <AUTHOR> https://www.cnbc.com/2020/08/31/amazon-prime-now-drone-delivery-fleet-gets-faa-approval.html <comment><USER2> Drone delivery is going to happen, but most people aren't going to benefit from it in the immediate future. Drones are too loud and the self-flying software isn't advanced enough to effortlessly and efficiently deal with the complications of urban delivery. Rural areas and exurbs are great options for drones because noise is less impactful and you can more easily drop off a 5lb box in front of someone's porch and not have to worry about hitting another building, cable/power lines, being targeted by thieves/the mischievous, etc. An Amazon van driving 10+ miles to and 10+ miles back to make a single delivery is also very expensive (gas, maintenance, driver, wear and tear, etc.), especially compared to an Amazon van in a city which will unload most of its cargo within a few square blocks.

Between Starlink and fast/cheap Internet in the most remote areas of the country, working from home becoming more mainstream, and things like drone delivery, the rural parts of this country are primed to become a far larger part of the economic and social fabric of this country. Toss in self-driving cars and cities lose even more of their advantages. It's an interesting time to be alive.

</comment><comment><USER3> Anyone else trying to remember what year it was when we all thought this was a cyber monday stunt? 2013

[https://www.usatoday.com/story/tech/2013/12/01/amazon- bezos-...](https://www.usatoday.com/story/tech/2013/12/01/amazon-bezos-drone- delivery/3799021/)

[https://spectrum.ieee.org/automaton/robotics/drones/amazon-p...](https://spectrum.ieee.org/automaton/robotics/drones/amazon- prime-air-package-drone-delivery)

</comment><comment><USER4> I'm skeptical that this article is accurately portraying the FAA permission that Amazon has been granted.

The FAA has been aggressive about forbidding beyond visual line of sight operation of drones without spotters or radar coverage. I suspect the permission is not for true BVLOS deliveries, but rather deliveries with a spotter watching the route, or BVLOS with a radar covering the entire route, or some other commercially impractical system of monitoring.

The FAA is being hamstrung by the pilots association and various other unions that are fearful that this kind of automated delivery will reduce the volume of pilot and union jobs available in America. The Luddites in DC are the most powerful force in American robot regulation today.

<comment><USER5> Wasn't it UPS that was prototyping a series of drones that docked on top of the truck, using it as a hub to deliver packages within a short range? I could see something like that being a logical next step for this tech.

<comment><USER4> That experiment very publicly failed in a demo in front of journalists.

<comment><USER6> Link?

</comment></comment></comment></comment><comment><USER6> Having a difficult time understanding the logistics of this. Is there a resource online with more details of what Amazon might do? I live in the 'burbs, but putting a drone-delivered box on my doorstep is quite non-trivial it seems.

</comment><comment><USER7> I'm worried about birds. The sky is the only safe place for them. I don't think I'm being overly sensitive either.

<comment><USER8> You only have to worry about deaf birds. Drones are pretty loud.

<comment><USER9> I guess all that noise might affect the life of birds in some way or another.

<comment><USER10> In my personal experience any radio controlled aircraft coming near a bird's nest will be challenged in the air. It certainly stresses them out in the mortal danger kind of way. It made me change where I do my "Park Flying" before I injured a bird.

<comment><USER11> I've flown a lot since the late 90's. A bunch of different areas. My dad was very into it. I've never had a bird attack an airplane or helicopter. I've never flown quadcopters/drones much as they require no skill and not fun. The closest I ever saw was a small foamie where a bird swooped towards it. Never came that close and moved on.</comment></comment></comment></comment></comment>


Bored to Tears by a Do-Nothing Dream Job - <AUTHOR> http://www.nytimes.com/2015/11/22/jobs/bored-to-tears-by-a-do-nothing-dream-job.html?_r=0 <comment><USER2> I've had one of these jobs for years. Each day I come in and expect the gig to be up. It never happens. This has been across 2 companies, for 10 years. From the outside it looks like a dream job, from the inside I'm highly depressed because the work is so unfulfilling. I have a need to be busy constantly, instead it's slowly seeing your skill set rot and dying a bit each day.

<comment><USER3> Does this not grant you the perfect opportunity for personal improvement?

Work on some pet projects to keep your skill set fresh, and in an ideal world, come up with something that makes you money and you can eventually turn into your full-time job.

<comment><USER4> Usually workplaces ban working on pet projects, or at the very least claim all IP rights on them.

<comment><USER5> This is quite true, but if the goal is to develop skills more than it is to develop IP, this shouldn't really matter.

I suspect very very few individuals have hit a grand slam startup idea out of the park while simultaneously learning a new language or domain.

</comment></comment></comment></comment><comment><USER6> I was a chef on private yacht. Fortunately we had satellite TV, internet in marinas, I was expected to fish if we were underway, if it was windy the mister would ask if I needed help getting the windsurf board off the top deck, I could use the boat credit card at all the tiki bars at the end of the dock, unlimited food budget, cook anything I wanted, and crew and owners always made them selves breakfast. Bored I started teaching myself how to code. Now I'm stressed not having done that in a few years distracted by Hacker News trying to build an Angular directive wondering why I didn't use React which I know nothing about. :(

<comment><USER7> should have taught yourself how to sail and become a pirate

<comment> saiya-jin or do a course for captains

</comment></comment></comment><comment><USER8> >We all need a reason to get up in the morning, preferably one to which we can attach some meaning.

Author makes a generalization here - one I have seen first hand not to be true on many occasions.

My first job was effectively working 2-3 hours a day in a medium sized company (>400 employees). The company inherited local market monopoly and a lot of employees had shares after privatization from communist era - which kept the communist hiring/work policy for almost 15 years after the fall of the regime.

Very few people actually disliked the fact that they accomplished little to nothing in their 8 hours at work, a lot of them were involved in stealing (drivers using company gas for their cars, reselling raw materials, stealing product labeled as "defective", etc.)

I would say 95% of the people were not only happy but probably proud that they were getting decent salaries for below reasonable amount of work (by any standard). There were people who didn't like that kind of environment and incentives (myself included) but we were in minority. I would say that what separated us from the others was ambition - we actually wanted to accomplish something in our career and majority of people working there were perfectly happy where they were.

Eventually the financial crisis hit, the market shifted, company profits went to shit, employees dumped their shares in panic and all of those incompetent people found themselves on the street with no career prospects after 20+ years of doing practically no work. The guys who were semi competent were long gone by then.

My point is - this sentiment of needing to accomplish something at work is not shared by everyone (some may pay lip service to it but in practice won't behave accordingly) it's not something I would generalize.

<comment><USER9> It does not mean they didn't have a reason to get up in the morning, just that those reasons were unrelated to the business line they "worked" in.

I have known a bunch of such people, in a variety of mostly governmental jobs (but one high level banker too and even one in a tiny 5 employees company !). They were going to work like you go to the pub. They went to socialise, engage in petty status/influence wars, and indeed, there was this competition to see how to profit from the system.

And even then, all of that is relative. Money alone is a powerful reason to get up in the morning for the vast majority of the world. That's really a first world problem that you want to be paid to do something with meaning. Hiring people to do nothing all is routinely done in third world outsource centre. You keep team around for months before a project starts and you don't hear much whining.

<comment><USER8> > It does not mean they didn't have a reason to get up in the morning, just > that those reasons were unrelated to the business line they "worked" in.

I agree - but it seems implied in the text (maybe I am misreading it).

I would say people who actually want meaningful work are an exception not the rule - most see it as a way to get money. Which I am not criticizing btw. - everyone has their own values - I am just saying you shouldn't assume that people care about the work they do on their jobs (and I've seen many people idealistically assume it, even I believed it before I started working).

</comment></comment></comment><comment><USER10> If you liked this article, you'll like this one too: [https://news.ycombinator.com/item?id=6087935](https://news.ycombinator.com/item?id=6087935) ("forgotten employee, something awful forums")

</comment><comment><USER11> I had a kind of job like this once...weeks might go by with nothing at all assigned to work on, and then a sudden hellstorm of unstoppable shit for a few days, then back to boredom.

I tried to work on other things, but you never knew when a pile of nonsense would end up on my table (and the boss was one of those terrible managers who exemplified all the things managers shouldn't do), if I tried to work on anything outside of what my job description entailed, I'd immediately get shot down.

So I slept a lot, worked out, studied languages, anything that could keep me occupied, but wouldn't count as "IP" the company could claim since I did it all on company time.

It was one of the most stressful jobs I've had and I finally just left, even though the pay and benefits were phenomenal.

It would have been better, and I would have been more productive when they needed me, if they had just turned me into an on-call employee with benefits and just let me do whatever else I wanted on the side.

<comment><USER2> Exactly this ^^^. In fact those that leave my company all end up as contractors.

</comment></comment><comment><USER12> To me this just says "I don't know how to find interesting problems by myself; I need somebody to supply them for me."

There's plenty of people out there who have problems they care about independently of anyone telling them to, and have to just work on these in the time left in the day that isn't taken up by their job and chores. If I got one of these do-nothing jobs I could get plenty of math done with that!

<comment><USER13> Yes but that is because you are a mathematician (or at least appear to be so). Private math can be done in so many places. I'm not criticizing as I would do the same with coding (and is how I started my own company).

However I would say predominantly most vocations/interest require considerable infrastructure (other people to work with and/or other resources) and cannot be done during a menial office job.

Even most academic studies require resources (like telescope time) that you really can't do with out full commitment. I would argue even the most brilliant will probably run out of creativity with out the right social interactions.. I could be wrong.

</comment></comment><comment><USER14> I had a similar experience. I worked at a travelling agency in the early 2000's. There were days without a single customer, and I was the only employee at that particular office. Internet access was shielded (and monitored!), and we had no radio. On 9/11 someone barged in and told me the news, because I was unaware.

Anyway, I got some books about HTML, and later PHP from the library and started coding in notepad. To this day I think this has been a blessing, a lot of my friends learned by copy-pasting scripts, but I had to learn from the bottom up.

Long story short: I learned how to code and got the hell away from that dead- end job.

</comment><comment><USER15> I think living a stress free life can turn out to be a bad thing. You need physical stress i.e exercise makes you healthy + happy. I wouldn't be surprised if purely mental stress had similar effects on Humans.

Obviously there's a threshold after which it starts affecting people negatively.

Also, just because a job seems like a dream doesn't mean that the day to day grind is for you. I know a lot of pilots who, after a few years of flying commercial airlines, can't stop bitching about the tedium of the job.

<comment><USER16> I think that's conflating "stress" with "challenge". One makes you and grow, while the other is just an incentive not to die.

There are challenging things which are not stressful, and stressful things which are not challenging. (Especially if they hinge on something beyond your control.)

</comment></comment><comment><USER17> >I've often wondered why the so-called Masters of the Universe, those C.E.O.s with multimillion-dollar monthly paychecks, keep working. Why, once they have earned enough money to live comfortably forever, do they still drag themselves to the office? The easy answer, the one I had always settled on, was greed.

>But as I watched the hours slowly drip by in my cubicle, an alternative reason came into view. Without a sense of purpose beyond the rent money, malaise sets in almost immediately. We all need a reason to get up in the morning

I enjoyed the article, but this is painful. Is it really that hard to imagine why someone with a lot of money would want to keep doing what they do, or that it might not be primarily about the money?

</comment><comment><USER18> A very related TED talk: The way we think about work is broken, by Barry Schwartz [1]

I found the book in a bookstore this weekend, and I ended up buying the audiobook [2].

[1] [https://www.ted.com/talks/barry_schwartz_the_way_we_think_ab...](https://www.ted.com/talks/barry_schwartz_the_way_we_think_about_work_is_broken)

[2] [http://www.audible.com/pd/Nonfiction/Why-We-Work- Audiobook/B...](http://www.audible.com/pd/Nonfiction/Why-We-Work- Audiobook/B013PWR1YW/)

</comment><comment><USER19> Hey, the grass is always greener...

</comment><comment><USER20> Why does this guy seem to have jobs where he either does nothing or where he works every waking moment? Seems to me like he should read up on work-life balance.

</comment><comment> saiya-jin yeah, the wonderful effects of real-life socialism & communism. same experience here, luckily I am young enough to only see and hear about it, not experience it (on) myself. luckily i moved away, since this mentality ain't gone completely yet.

every time I hear people b __ching about capitalism and glorifying some nice- on-the-paper utopias, where all will be happy and working for greater good of mankind (ie not entirely but in same ballpark - basic income), I just recall good old memories of this. haven 't yet heard a theory that is "this"-proof, but boy I sure would like to...

<comment><USER8> Yep, I noticed it on this forum recently as well. People complain when profit incentives don't lead to value creation in some instance and see that as a basis to reject capitalism. They don't consider what happens when you replace profit with politics - incentives end up being perverse by default (as we are seeing more and more in the West with regulatory capture and government granted monopolies).

I think basic income is the least disruptive of all as it keeps the incentives for industry there but still creates a floor for everyone. It would change availability of various services/disrupt pricing but I would prefer that to socialism any day.

</comment></comment><comment><USER21> Did he now have a computer with internet? How can you be bored when you have the internet.

<comment><USER21> not _</comment></comment>


Coreboot 4.10 - <AUTHOR> https://blogs.coreboot.org/blog/2019/07/22/announcing-coreboot-4-10/ <comment><USER2> > As usual, there was a lot of cleaning up going on, and there notably, a good > chunk of this year's Google Summer of Code project to clean out the issues > reported by Coverity Scan is already in.

Hey that's me! :)

</comment><comment><USER3> Coreboot is a great project, it's unfortunate that more devices don't use it. OEM machines from the big names like Dell or Lenovo can't/won't support it due to Boot Guard as far as I'm aware

Some of the smaller niche venders like GPD or 51nb who make much more exotic gear though would be great to see support for

Alternatively I'd love to see the range of "old" motherboards supported. A retro machine with Coreboot would definitely open up a lot of interesting possibilities compared to clunky, buggy old OEM BIOS's of the era

<comment><USER4> I went to considerable trouble to evaluate and obtain a small stockpile of some well-supported Coreboot-friendly hardware, while it was still easily available on the used market. (For example, in the past, old ThinkPad models tended to dry up, as the used pipeline emptied of corporate fleet e-cyclers.)

I'm thrilled to see more new and old boards possibly being well-supported by Coreboot, though I'm not assuming that's going to be a thing.

[https://www.neilvandyke.org/coreboot/](https://www.neilvandyke.org/coreboot/)</comment></comment>


MVC is dead, it's time to MOVE on (2012) - <AUTHOR> https://cirw.in/blog/time-to-move-on <comment><USER2> Everyone who has done MVC long enough would also know that the controller is the very thin layer where services are injected and models are passes to.

The controller should have and only have logic which absolutely cannot be moved to a service layer.

Too many developers use controllers as part of their logic layer, instead of simply using it as a router for where models should be directed on a service level.

<comment><USER3> "Everyone who has done MVC long enough... The controller should have and only have logic which absolutely cannot be moved to a service layer."

Sorry, which letter in MVC is the "service layer"?

One of the reasons I don't buy into MVC is that MVC doesn't mean _anything_ any more, and hasn't ever since the web people got their hands on it. If you ask ten developers what MVC is and get 13 different answers (see half the sibling replies to this comment), well, that's not itself a problem, but it does mean that running around telling people that they should or should not do "MVC" has been pointless for a long time.

I still like MVC for its original purpose: Multiple views in a CAD/CAM program. Makes perfect sense there. I don't think I've yet seen a place where it belongs other than that, though.

<comment><USER4> > Sorry, which letter in MVC is the "service layer"?

Your question, sarcasm and all, makes no sense and either reflects bad faith or ignorance. The model in MVC is the model, even if it depends on the service layer or not. Design patterns describe components with respect to their roles, and the fact that the concept of service is not necessary to explain the design pattern that does not mean it should be in the acronym. In fact, models are quite obviously wrappers around repositories/gateways/services/etc etc etc. The reason behind this, obviously, is that if your goal is to simply provide a UI then it makes absolutely no sense to drag or leak the application or service layer into the interface. You just add an adapter to the repositories/gateways/services and then use that adapter to input and output the data you need to be in the UI.

> One of the reasons I don't buy into MVC is that MVC doesn't mean anything > any more,

That cop-out doesn't cut it. MVC is well documented, and objectively defined. Just because some people either ignore its meaning or get a bit "creative" with their personal definition (I'm looking at you, Qt) it doesn't mean there is no concrete definition, or that you have any excuse to criticise something you don't know.

<comment><USER5> Re: _MVC is well documented, and objectively defined._

I'm skeptical. Do you have a link or quote of the "official" definition so we can critique it?

<comment><USER4> For example:

[http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf](http://www.math.sfedu.ru/smalltalk/gui/mvc.pdf)

The pattern is known for having been made popular by Smalltalk. In the 1980s. It makes no sense to assume that a design pattern that has been widely used for, say, 40 years is somehow not described.

<comment><USER5> I still haven't found anything that makes a clear distinction between "controller" and "model". The best explanation I've ever heard is that a controller's job is to map UI activity to the proper model and view. That's a start, but there is a lot of grey area there also as determining such can sometimes be complex in itself, which leaves the door open to "fat" controllers.

<comment><USER6> I think the biggest distinction to me is that the controller is the entry- point into an action/routine. It takes external inputs and returns an output to be sent back downstream.

<comment><USER5> That's pretty much true of any function or method.

<comment><USER6> Yes, but I'm talking about into the overall system, not into a method.

<comment><USER7> In many frameworks the controller isn't even the entrypoint anymore though. Laravel for example has a separate router layer, which is the entrypoint that then passes things into a controller.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> MVC is fine. After years experience in mobile development, my main takeaway is that application architecture acronyms in general are over-rated.

The most important thing is to separate concerns, and to agree on _some_ sensible structure for managing views and state, and communicating between them. Usually the details of that should arise from the needs of the application, not come top-down from some idea about "the perfect application architecture". Aside from that, everything should just be kept as simple as possible.

IMO it actually adds a lot of unnecessary pain and complication to a project when a team is too rigid about which letter of an acronym each piece of code must fit into. VIPER would be an extreme example of this. It should not take five+ separate code files to execute an HTTP request and display the results in a list view.

</comment><comment> GuB-42 To be honest, the real pattern is MVW (Model View Whatever).

The third thing can be a controller (true MVC), a presenter, a view-model, or, in the case of the article, operations and events.

The big deal with all this is that we have a view, usually provided by a UI framework, a model, usually provided by the app developer, and some kind of loose coupling. That's it, the good old idea of separating data from its representation.

What you stick between the model and the view is just an implementation detail of your particular framework, optimized for your particular use case.

<comment><USER9> > The third thing can be a controller (true MVC), a presenter, a view-model, > or, in the case of the article, operations and events.

Well the article introduces weird new lingo which I don't think is all that great, but whatever.

"operations+events" can be equaled to "business logic". Let's keep that separated from the controllers. I want to create a new user via an http request, but I also want to do the same via a console command and since I want to do both things with the same code but one of these shouldn't be returning http status codes, it makes sense this should live in a different layer.

The whole events & operations separation in the article don't make sense to me. A "login attempt" as described in the article with a "login attempt" event being triggered by the view and that being picked by a decoupled "operation"? I don't see the value. If the operation needs to check privileges does it trigger an "check privileges" event, wait for another operation to complete? does that operation trigger another event to report the result? Wait a second... this sounds a lot like a convoluted Redux clone. Then you realize the only reason we are not doing Redux in the backend is because we are used to mutable state databases.

</comment></comment><comment><USER10> MVC is understood to be the primary partition of an application's architecture. It does not obviate the need for further code organization, which is done in all parts, Model, View and Controller. When the author says "controllers are nice self-contained bit of...[what I don't know?]", and they use that as the justification to throw away the paradigm in favor of another with Model-View-Operations+Events they show they don't understand this. Worse the proposed paradigm does not then collect all the controller code in one place, so the overall lifecycle of the application would be harder to piece together from Operations+Events modules without an overarching Controller to govern the two of them.

<comment><USER11> +1 so much.

In my opinion, the mistake the OP makes is in not realizing that the dogmatic application of a design pattern is the fundamental issue to begin with.

So then the solution offered is another design pattern that can be dogmatically followed.

If we know that you need a UI (view), and we know that you need to represent your data in an expressive manner (model), and you need something to pull those things together for a user, a router and controller does not automatically come to mean "put all your logic here!" Instead, it means something more like "here's where you can tie things together in whatever way makes the most sense for your application", which lets you e.g., use AOP to handle auth (like Django decorators or middleware), delegation to a service like a REST API (e.g., Django REST Framework), or basic one-off views for simple tasks.

If something like this MOVE was to become the next big thing, I think there's a good chance we'll be rewriting a lot of projects to use MVC in 10 years.

Don't blame bad code on a proven and very flexible design pattern that solves a very real problem. Blame bad code on bad coders.

<comment><USER10> Personally I see this design pattern simply as an application of Dijkstra's Separation Of Concerns. That MVC is the best (most orthogonal and balanced) division of concerns in a gui based app.

</comment></comment></comment><comment><USER12> Events are how MVC was used before the web world came around. The whole point was your controller listens to model and view events so everything is updated real time as the model changes and the user interacts with the UI. The web is a bastardized version of MVC due to the lack of interactivity and state when compared to a desktop GUI application.

That aside, lots of people in the web world have a sort of "Operation" layer in MVC but call them a "service". Deciding to use events is another architectural decision some people make even in web MVC.

But you can take or leave any piece of this stuff and I feel like you don't need a new acronym for every combination of architectural decisions.

<comment><USER13> BILASM!

But I Like Acronyms So Much.

Web "MVC" rarely was really MVC. Except that it changed the meaning of the term.

[https://wiki.c2.com/?ModelViewControllerHistory](https://wiki.c2.com/?ModelViewControllerHistory) [https://wiki.c2.com/?WhatsaControllerAnyway](https://wiki.c2.com/?WhatsaControllerAnyway)

</comment></comment><comment><USER14> Turns out Conrad Irwin was right, but didn't take it far enough. Merge together "Events" and "Operations" into one thing, call "Models" just "state" and you've got Reactive Programming, which appears to have proven itself as the best known way to manage UI state complexity.

<comment><USER15> Proven in what way? After almost 4 decades in this business, nothing is ever proven. For anything one person says is beyond discussion obvious, another person does something completely different, and gets the same benefits. Every generation comes up with new ways to do things, but nothing has even been clearly better to everyone all the time in all circumstances. You constantly have to evaluate everything that comes along, and see if it's better for you, your team, project, company or industry. Silver bullets are for vampires and the Lone Ranger.

<comment><USER16> It is "proven", not in a mathematical sense, nor a scientific sense, nor an engineering sense or even a legal sense. It is proven in a javascript sense.

</comment></comment></comment><comment><USER17> Nearly all UI frameworks use MVC. That includes iOS, ASP.NET Core, JSP and JSF (both Java), Ruby on Rails, and Django (Python).

In fact, it is easier to list UI frameworks that are _not_ MVC-based: WPF, which is based on MVVM and React+ReactRouter+Redux, which is based on Flux.

MVVM was invented in order to support 2-way data binding. Inspired by WPF, many early JavaScript frameworks supported 2-way data binding. These days 2-way data binding is widely acknowledged as a poor design as it makes it hard to keep track of how data is flowing through your application. For more on that see [1].

React was originally introduced as the "V in MVC" [2]. Since then it drifted away from MVC in an ad-hoc manner. In part this is because of ReactRouter, which made router a view component (!), and in part this is because of Flux/Redux. The facebook engineer who came up with Flux famously declared that MVC doesn't scale (!!). This assertion was widely challenged, and later she acknowledged that it is bidirectional data flow that doesn't scale [3]. She had assumed that MVC automatically implies 2-way data binding. Redux, an implementation of the Flux architecture then became popular, and became closely associated to React, so much so that many developers believe using React implies using Redux. This is unfortunate because Redux requires tons of boilerplate ("so much throat clearing", as one developer put it), which MVC does not require.

[1] [https://changelog.com/131/](https://changelog.com/131/) (starting around 0:43)

[2] [https://github.com/facebook/react/tree/015833e5942ce55cf31ae...](https://github.com/facebook/react/tree/015833e5942ce55cf31aefd0a5c2be8a65ec2daa)

[3] [https://www.infoq.com/news/2014/05/facebook-mvc- flux/](https://www.infoq.com/news/2014/05/facebook-mvc-flux/)

<comment><USER18> "That includes iOS, ASP.NET Core, JSP and JSF (both Java), Ruby on Rails, and Django (Python)."

If all of those are MVC, does MVC even mean anything?

What are the core commonalities across all those development frameworks that make them "MVC"?

<comment><USER19> The Models are all the code that define your business logic. They have no idea how they get represented in the UI, and they have no idea what calls their operations.

The Views accept data and generate a UI of some kind. They have no idea where the data comes from, or what their requests actually do.

The Controller knows about both the Model and the View. It maps request from the View to operations in the Model, and then uses data from the Model to update the View.

M <= C => V

That is the broad structure behind how all those things works. They aren't all the same, but that's not the point of a design pattern.

</comment></comment></comment><comment><USER20> Maybe at 2012 to the title.. And I can say for sure it's not dead! Even in 2020 ! :) But I do like the extension with MOVE.

</comment><comment><USER21> I don't see anything wrong with MOVE... but why does MVC need to be dead?

It's such a perfect representation of the coder trope of loudly proclaiming that this new thing I found makes everything else obsolete. Eight years later, MVC is still miraculously not dead!

<comment><USER22> What does this mean for waterfall? Is it alive again?

It's kind of an insult to death.

<comment><USER23> Waterfall is a myth.

<comment><USER24> My cousin's boyfriend's sister went up to the waterfall, and when they found her body 12 months later--after delivery phase--she had been _completely burned out_ from the inside. And there was this _thing_... that nobody wanted, that didn't work right, just sitting there next to her. Nobody wanted to touch it. So some guys from the federal government came and picked it up with tongs, and said they'd put it in the Source Control Repository facility out in New Mexico, so it couldn't hurt anybody else.

<comment><USER25> Nice to get some commentary from GPT-2.

<comment><USER26> Wouldn't gpt-2 be much harder to detect. This could just be markov chains which were trained with all their comments from the past. Still pretty cool

<comment><USER24> You mentioned markov chains which were trained earlier. Tell me more about that.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> Where can I find a good resource to learn these patterns well for web use?

I've never gotten into any of these patterns in 20 years but can get the job done efficiently as I don't put codes all over the place but at where it's easy to find for easier debugging.

Usually average people try to put their codes into these patterns without truly understanding and their logic is also not efficient, turning codes into very unreadable state instead of just dropping the pattern and write as you please (with at least minimal separation of views and consolidate identical codes).

Have these patterns really helped you in the web?

<comment><USER28> I would recommend Architecture of complex web applications [https://leanpub.com/architecture-of-complex-web- applications](https://leanpub.com/architecture-of-complex-web-applications)

</comment></comment><comment><USER29> A thread from 2013: [https://news.ycombinator.com/item?id=6370343](https://news.ycombinator.com/item?id=6370343)

Discussed at the time: [https://news.ycombinator.com/item?id=4189811](https://news.ycombinator.com/item?id=4189811)

(Links are for the curious; reposts are ok after a year or so: [https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html))

</comment><comment><USER30> These are all minor variations of the same ideas.

</comment><comment><USER31> I've always had a very loose view of MVC. It feels like all the MVC/MVVM/MV(whatever) concepts really are about separating the model from the view, and having something to connect the parts. I've never gotten hung up on the specifics beyond that, but it seems like framework after framework is built on exactly worrying about those details.

It's been 20 years - have I been missing out on a crucial details?

</comment><comment><USER32> Ummm maybe folks are just using MVC when they shouldn't?

I don't really think most people understand how to do MVC. A LOT of people mostly pick a framework that incidentally has it slapped on the side and that's about it...

People seem to assume "view" has to mean template, "model" has to mean "database access," and controller means "anything else." When in reality, they're far simpler and more abstract and has nothing to do with the web or services:

Model - Data View - Output Controller - Takes input, fetches data for input(s), gives output

Do you have a part of your application that takes input and gives output? Well then MVC is probably great for that part of your application, maybe not.

I have not ever had anyone say "the adapter pattern is dead, don't use dat shit, my dear, brometheus" because most people, quite accurately, don't think it's some sort of philosophical statement it's just way to organize some shit to make your life easier when it applies.

/shrug

Use the right tool for the job; you can waste a ton of time trying to use a screwdriver on nail, or you could just get a hammer...

</comment><comment><USER33> I like this a lot, not as an alternative to MVC but as a kind of conceptual refactoring of the same ideas behind good MVC implementations that's very easy to explain and doesn't have as much ambiguity.

I've posted a version of this comment before, but my main problem with MVC isn't that it's a bad architecture, just that in practice there's a huge amount of disagreement about what MVC (or MV* more generally) actually _is_, which can lead to confusion or weird/bad hybrid implementations.

I tend to use the "model" and "view" concepts a lot when discussing architecture, but in my experience it's almost always a mistake to try and reference any specific MV* pattern for explanatory purposes - it does not have the effect of making the discussion clearer.

The issue is that there isn't actually a consensus about what constitutes the definitional features of these patterns, especially when it comes to how the concepts involved actually translate into code. For any sufficiently notable discussion of an MV* pattern, you're going to find an argument in the comments about whether the author actually understands the pattern or is talking about something else, and typically the commenters will be talking past one another.

Note that I'm NOT claiming that there's anything wrong with MV* as an architecture, or your favorite explanation of MV* - it may be perfectly well defined and concrete and useful once you understand it. The issue is a feature of the community: lots of other people have a different (and possibly worse) understanding of what MV* means, so when you start talking about it and your understandings don't align, confusion arises. Getting those understandings back in alignment is more trouble than the acronyms are worth.

I've seen enough conversations about concrete development issues suddenly turn into disagreements about the meaning of words to realize that nothing useful is conveyed by mentioning MV* and assuming anyone knows what you're talking about - it's better to spell out exactly what you mean in reference to the code you're actually talking about, even if you have to use more words.

I like this MOVE scheme because it seems to me to divide up the conceptual space at the joints in a way that's relatively hard to misunderstand, and it seems a little easier to see how to directly relate those division back to code.

<comment><USER34> I feel the same way about most design patterns. They're useful to provide vocabulary, but too generic to provide any actual guidance.

</comment></comment><comment><USER35> One thing seems true about MVC or any other similar pattern/acronym: people seem hostile-certain that their interpretation/implementation is correct and everyone else is doing it wrong. Even in this thread are a bunch of comments like "everyone knows" followed by a personal opinion and then a thread of confused support/dissent. People then insist their interpretation from Wikipedia, Smalltalk, Ruby or wherever is actually the one everyone agrees on as some well-defined thing despite clearly no one in this very thread agreeing.

Every platform has it's own challenges to work around. Trying to take a pattern you used in Qt and applying it precisely the same way to a Javascript/HTML application would be unwise. Things like the DOM, CSS and even the quirks/strengths of Javascript mean you should approach the problem differently. This can mean you are forced to structure your code differently. The same is true if you are dealing with iOS and Swift.

IMO, MVC should mean something different in a way that supports the context it is being applied within.

<comment><USER36> The only implementation that I can outright say is "wrong" is the Apple's iOS ViewController, which people mistakenly call MVC...and then promptly throw the kitchen sink into that layer without a casual thought, growing that single file to thousands of lines of code, with state, business logic, display logic, and everything else all wound together...and thinking everything is well and good because they are following the MVC pattern.

The ViewController isn't bad all by itself, but calling it MVC is just not it.

</comment></comment><comment><USER37> Needs a (2012) label

</comment><comment><USER38> Controller = Operations + Events

Ben Jaffe of Udacity cally is MVO where O = Octopus. Basically, as the author points out, Models and Views are relatively well defined, but the Controller can be anything. Octopus, ViewModel, or in this case Operations and Events.

I do think Operations and Events are clear, but

1\. are they comprehensive and

2\. do they organize the code more intuitively?

It seems like you would want to put them in the same place since Events will trigger operations that operate on the model and the view. Sort of like a controller... oh, wait.

</comment><comment><USER39> I'm a big fan of the "fire and motion" concept of dev social paradigm.

The idea is that devs and large companies have a tendency to constantly move away from tried and tested concepts not because the juice is genuinely worth the squeeze, but because doing so forces the devs "in their dust" back into learning mode and out of productivity mode, thereby maintaining or creating leadership over them (i.e. you force them into playing catchup -- catchup to your new "hot" thing).

Case in point with this article: an attempt to declare that a tried and tested and widely used concept is now outdated, and they know the "right way" we should be doing it.

This paradigm is important from a dev management perspective, in that there must be an element of actively suppressing this in a dev organisation.

E.g. having approved tech lists so you don't have another half dozen js frameworks inserted over the next 12 months, requiring permission to stray outside standard paradigms, and compartmentalizing experimental time from production time.

Otherwise your dev output drops through the floor.

MVC is fine. Its a basic concept that aligns with the underlying hardware: model - memory, view - screen, controller - cpu. It ain't broke, don't let your devs fix it.

</comment><comment><USER40> This is an interesting idea, particularly if you couple it with other ideas or tools. The one primary issue I have with event driven systems is that it is very difficult to look at code and intuitively know what's going on.

If you're having to search your entire code base to see what happens when a user logs in, and then what happens if that user is marked as "blocked", it can get very complicated quickly.

Even worse, trying to backtrack events can be more complicated. What caused the "add to cart" event that added this special product type that is actually a digital download, but that wasn't a UI event? It could have happened in one of 10 places, debugging is difficult because you have to start somewhere in the middle and work your way backwards.

This is the issue I've had with wordpress development, actions and filters can make intuitively understanding what's going on under the hood very very difficult. Of course they give a lot of flexibility with plugins, extension points, etc, but when multiple plugins are interacting it can get very confusing.

Compare that with a more imperative controller where you branch based on conditions and you can generally follow the logic flow. Of course, there are ways to make that complex too like Form classes, validation, ORMs, etc. But I still find the more imperative paradigm of MVC easier to follow, such as in a Django case.

Where I say this can get interesting is in a use case like React. In a way, events are propagated through a tree and can be kicked off by data changes, such as in redux. If you design it right, there might be more promise in an event-based system, but introducing both server side and client side tends to complicate things.

</comment><comment><USER41> > MVC is a phenomenal idea. You have models, which are nice self-contained > bits of state, views which are nice self-contained bits of UI, and > controllers which are nice self-contained bits of … What?

The implication is that what goes into controllers is not well-defined. But if what goes into models and views is well-defined, as the author agrees, then defining what goes into controllers as everything else is actually a precise definition.

<comment><USER42> Trouble is what goes into the models is not well defined at all.

</comment></comment><comment><USER43> It looks like he just clarified some of the smaller moving parts in MVC but hilariously, he still ends up drawing a triangle for his diagram.

It looks like E (events) is simply to illustrate oh yeah some communication is happening between these layers. I think that is pretty obvious?

I'm not necessarily putting down what he was saying, but I don't think this is something revolutionary. I think he just dove deeper and expanded.

</comment><comment><USER44> I feel like his answer to what goes in the controller is answered by his acronym MOVE. Operations and Events go in the controller. It initiates the state changes in the model and the view. As an aside it's cool to see something like MVC staying relevant, it alludes to there being design patterns that are simple and fundamentally useful in some areas.

</comment><comment><USER45> FIFY

Operations ^H^H^H Functions A common function for applications is logging a user in. It's actually two sub-functions composed together: first get the email address and password from the user, second load the "user" model from the database and check whether the password matches.

Functions are the doers of the MFVE world. They are responsible for making changes to your models, for showing the right views at the right time, and for responding to events triggered by user interactions. In a well factored application, each sub-function can be run independently of its parent; which is why in the diagram events flow upwards, and changes are pushed downwards.

What's exciting about using functions in this way is that your entire application can itself be treated as an function that starts when the program boots. It spawns as many sub-functions as it needs, where each concurrently existing sub-function is run in parallel, and exits the program when they are all complete.

<comment><USER45> "What's exciting about using functions in this way is that your entire application can itself be treated as an function that starts when the program boots."

HN, rediscovering main()

</comment></comment><comment><USER46> A bit off-topic but I like out the page is responsive to browser width. It auto-magically creates columns as space available

<comment><USER47> I really really like that part. Three columns on a widescreen monitor is really really comfortable! Nice site!

</comment></comment><comment><USER48> Given that this article is 8 years old, did MOVE catch on?

<comment><USER49> I still see MVC in $dayjob, but it looks like React/Redux have helped a lot. A central module manages state and takes operations on that state. The desired view hierarchy is computed as a pure function of state. A library uses diffing to apply changes to the concrete implementation of the views (say, the DOM, or a native windowing framework).

<comment><USER50> MVC is still heavily used for instance in ruby on rails.

</comment></comment></comment><comment><USER51> > _the problem with MVC as given is that you end up stuffing too much code > into your controllers_

> _[Under MOVE, e]vents are used to join all these components together > safely._

The problem with events is that you put all interactions into events, creating a labyrinth of _ad-hoc_ protocols.

Events are messages, and messages are just methods in disguise: worse ones, that don't have a call stack you can inspect.

Under this MOVE, someone will sooner or later hit the problem of wanting the V to manipulate the M in some way that O doesn't support, and will just end up creating some hack whereby a whole chunk of the M state (perhaps all of it) is downloaded via some stream of events, edited, and sent back via another stream of events.

</comment><comment><USER52> I spent just enough time with MVC to experience that there's so many flavours and opinions and confusion and uncertainty. All of that was a smell that:

1\. this is a complicated domain.

2\. the lack of a very clear coherent "right answer" tells me not to dwell too much on it. I'll see more gains by getting my UIs into production and initiating the feedback loop than trying to get the architecture right.

As for item 2, I have absolutely iterated on underlying architecture, non- stop. But I feel I've been immensely successful in never letting that get in the way of shipping early and often and learning the 90% of stuff you can't learn without shipping.

</comment><comment><USER53> So it seems that anyone can make up their favorite "architecture" even if it's not well defined. (Is MVC actually well defined?) My favorite was MVPC (Model- View-Player-Controller) as I was mostly developing an app for blind users, where a good speech/audio interface is the top priority. The "Player" here is much like an OS scheduler where you can post various tasks (speeches/sound effects) in a queue and get a notification when it's finished. This greatly simplified the event handling part as it eliminates the needs of individual timers, counters and flags.

</comment><comment><USER54> My biggest issue with MVC is that in my experience it always ends up having the C being glue between fat Ms and fat Vs, with multiple views ocasionally growing tendrils between one another.

As in, not the pattern, but the real-world usage of it. Development constraints always end up corrupting the pretty pattern in ways that make the current problem at hand easier to solve, and this de facto architecture IMO never ends up looking like proper MVC for me.

I want to say I like Action-Domain-Responder better, but I haven't seen any real-world implementations of a ROA with it yet.

</comment><comment><USER55> Now what are operations then? And how are they tied to events.

Let us assume a concrete architecture where views are html documents and events are put into some distributed queue. Is an operation a process that consumes events from that queue or is it something more tangible? Are operations data? In other words, are they interpreted? By what interpreter?

I think the idea of describing your business system as some giant, distributed, parallel DSL interpreter has some merits. But has it ever been implemented as such somewhere?

</comment><comment><USER56> The creator of MVC ([https://en.wikipedia.org/wiki/Trygve_Reenskaug](https://en.wikipedia.org/wiki/Trygve_Reenskaug)) has since supplemented it with DCI. ([https://en.wikipedia.org/wiki/Data,_context_and_interaction](https://en.wikipedia.org/wiki/Data,_context_and_interaction))

DCI is better thought out than MOVE.

</comment><comment><USER57> MVC implemented properly is actually fine.

Sometimes it doesn't matter what the rules are just that there are rules because the rules bring order and consistency that allow for quick comprehension of the written code.

Heres a modern iOS dev defending MVC:

[https://www.dotconferences.com/2020/02/guilherme-rambo- mvc-m...](https://www.dotconferences.com/2020/02/guilherme-rambo-mvc-many- view-controllers)

<comment><USER58> Everything is fine if it's done properly.

</comment></comment><comment><USER59> MVC certainly isn't dead. My current team supports a system implementing MVC attributed over $65MM a year and is in still active feature development.

Sensational title at best.

</comment><comment> debug-desperado Hilariously, this is basically the pattern everyone figured out long ago with Windows Forms apps. Model View Presenter with decoupled events that are fired off to any subscribed listeners. Multiple screens and models can be updated as needed. Very easy to do in a C# app thanks to uncluttered syntax for events.

Go check out the "Microsoft Patterns and Practices" frameworks from decades ago to see many examples of this.

</comment><comment><USER60> > Since it was invented however, new programming techniques have become > popular. Without closures (or anonymous blocks) event binding can be very > tedious; and without deferrables (also known as deferreds or promises) the > idea of treating individual operations as objects in their own right doesn't > make much sense.

Didn't the Smalltalk team invent MVC? Because I believe Smalltalk in the 70s supported both.

</comment><comment><USER61> I'll never understand the obsession to have one architecture to rule them all. mVC isn't dead. I set up MVC patterns all the time for small projects where I need CRUD with a sprinkling of custom code on top. It's a great pattern.

If it's not meeting your needs that just means it's not a good abstraction of your problem. And yeah, you should probably look for something else.

</comment><comment><USER62> It's very rare to give any credence to any breathless "X is dead". Do what makes sense for you to solve the problem in front of you. There's anti- patterns but bike shedding over architecture patterns is a waste of time for a large majority of most CRUD webapps with low traffic requirements I'd wager.

</comment><comment><USER63> What's the point of this? No way of architecting software is dead. Just use the model that works best for the task at hand, including the competencies and preferences of the development team. Everything has its place. Besides, software architecture is not a religion, just a technique.

</comment><comment><USER5> I've found MVC annoying, but everyone goes "everyone else is doing it so we have to do it also". Lemming Syndrome. In team environments it's usually good to standardize "slots" for certain activities. But MVC doesn't fit our work- structure well (Conway's Law).

What's good for websites is not necessarily good for data-centric CRUD. MVC tries to cater to both, and does neither well because it has to compromise to make both camps happy.

I'd like to see, first, the file/folder location be flexible. If a team wants to store the view together with the model (or view-model) in entity folders, they can. Make the file look-up mechanism more flexible, or at least have a few templates to choose from. Our shop would prefer something like this:

              Models
               - model01.code   // friendlier names not shown
               - model02.code
               - etc...
              AreaX
               - EntityY (folder)
               - - ViewModel.code
               - - View.code

Second, navigation (menus, URL's, and breadcrumbs) should probably be table- lized in the RDBMS so analysts and project managers can change paths and titles and perhaps even role assignments without re-coding. The "path math" of controllers is confusing and hard to debug. Put the damned tree(s) in tables instead so we can do nice reports and analysis of them without digging through verbose code. There was an anti-DB movement in the early 2010's that was wrong-headed in my opinion, so everything was shoved into app code instead. It's time to embrace DB's and use them again for what they are good at. We then wouldn't need controllers, at least not in everyday work.

Note: If I say something bad or wrong, please explain in a reply instead of give a hit-and-run negative score. I get better with _clear_ feedback. Thank You.

<comment><USER64> Pyramid's resource trees solve the "path math" problem quite nicely, there are some caveats to that kind of design as well, of course (mostly related to enumerability).

<comment><USER5> What's wrong with them being in the database? Analysts and project managers can then re-arrange things with fewer coding changes, using CRUD editing screens. One may have to re-project some URL's for the end-user's sake, but that's doable. "Pretty" URL's are not that useful for CRUD anyhow, but since customers expect them (because everyone else has them), they can be managed as an aesthetic wrapper.

I should note I'm a fan of the CASE idea of the 90's. It was just that the products were proprietary and too expensive. 90% of most CRUD apps can be attribute-driven. Menus, navigation, page titles, field attributes, etc. can largely be stored as meta-data in RDBMS where they are readily change-able and query-able. Buried in code makes them harder to work with. Over-focus on OOP killed the CASE dream, but I suspect it will come back. RDBMS are good at storing and managing masses of related attributes, code just isn't. (Dynamic Relational would help with attributes that are different or custom per UI widget etc. I wish it would take off.)

<comment><USER64> > I should note I'm a fan of the CASE idea of the 90's.

What's CASE?

<comment><USER5> Computer-Aided Software Engineering. It has different interpretations, but in my usage it means most of the application is controlled by meta-data that defines navigation, data relationships, field info, screen names, role associations, etc.

It's essentially a glorified integrated ERD + IDE. If you think about it, most of the info that goes into a typical CRUD application can come from tables. Related: "Data Dictionary". When I first saw them, I went, "Wow! This is the future!", similar to my first Macintosh visit. (One tricky part is dealing with the 15% or so that still needs custom adjustments. I have some ideas about that, but that's another long topic.)

</comment></comment></comment></comment></comment><comment><USER65> I have to confess it's the first time I read about MOVE but MVC seemed old news for almost a decade to me. MOVE seems to englobe concepts I work with like DDD, read/write segregation, event source, etc which can all live under its umbrella

</comment><comment><USER66> State (sometimes loaded externally through APIs/network calls) modified through events (typically user input) presented to the user (typically visually). How is MVC dead? That's the majority of coding I do when I do frontend...

<comment><USER67> I think the problem going on here is that the intent of what MVC means in theory is being conflated with its alleged implementations in practice. As you said here, this is the most pure and academic view of MVC. Few would disagree that the general flow of events and state is just as you described.

The _implementations_ of MVC are generally terrible, because the "C" is extremely subjective and you cannot find consistent patterns to follow universally. One developer's MVC app is going to look a lot different from another's unless they work on the same team or follow the same policies.

MVC (in practice) ultimately says "ok here's 80% of the puzzle I cannot figure out, good luck dealing with it". We can mostly agree on what our various businesses need or want (models+views) as well as what the browser API standards are (mostly views). The tricky bit is synchronizing those worlds in the middle. I personally find that pulling as much of the front-end into the back-end as is feasible is the most productive path to go down. It might not be the most scalable, but there is something really magical about being able to inject a business service you wrote 5 years ago into a .NET Core 3.1 Blazor component, write a small in-line LINQ mapper, and have it directly populate a table marked-up with BS4 (which then updates in real time via basic CLR event subscription). Is that MVC? I don't know. I don't really care either. It gets the job done, is easy to maintain, and makes me look good when it "just works".

</comment></comment><comment><USER68> Action Domain Responder, anyone? [https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93...](https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93responder)

</comment><comment><USER69> Well, MOVE, as described in the article, is exactly the same as MVC, since views are notified for state changes via events, and controllers are notified by views via events as well.

</comment><comment><USER70> MVC: Model View Controller

[https://en.wikipedia.org/wiki/Model–view–controller](https://en.wikipedia.org/wiki/Model–view–controller)

</comment><comment><USER71> Previous discussion: [https://news.ycombinator.com/item?id=4189811](https://news.ycombinator.com/item?id=4189811)

</comment><comment><USER72> Ah, another "forget <framework>, use mine instead" shtpost. Nice job.

</comment><comment><USER73> If you find this interesting, read up on event-sourced architecture.

</comment><comment><USER74> I prefer Django's Model View Template.

</comment><comment><USER75> Massive View Controllers never say die.

</comment><comment><USER76> Step 1: Call thing that people use dead

Step 2: ?

Step 3: Profit

</comment><comment><USER77> (2012)

</comment><comment><USER78> JupyterLab... with a model

</comment><comment><USER79> Event sourcing should kill MVC, we just need better frameworks to make it easier to do.

</comment><comment><USER80> Lol no

</comment><comment><USER81> I think that ecs is the thing that will kill oop.

[https://en.wikipedia.org/wiki/Entity_component_system](https://en.wikipedia.org/wiki/Entity_component_system)

<comment><USER82> I took a very dogmatic approach to ECS on a project[1][2] but I'm not sure it ended up easier to read or write as a result.

[1] [https://github.com/EamonnMR/Flythrough.Space/blob/master/src...](https://github.com/EamonnMR/Flythrough.Space/blob/master/src/ecs.js) [2] [https://github.com/EamonnMR/Flythrough.Space/blob/master/src...](https://github.com/EamonnMR/Flythrough.Space/blob/master/src/gameplay.js)

<comment><USER81> I think that js me not be the best language for it.</comment></comment></comment>