hknd

GME fundamentals haven't changed (much) - it's not worth much on paper, maybe $10, $20, $30?

Market behaves irrational rn, but at some point it will become rational again. And then GME stock will crash.

TL;DR: - "almost fast as native code for web browsers” - in case you wanna do some expensive computing without a server - "Compiling Existing Applications for the Browser" - port existing code into the browser (eg cpp apps)

The current store holding most of the displayed data stays alive (while not switching to a different route), but everything else resets or gets recreated when needed. (no need to keep stores alive if they are not required or used)

Stores for specific "sub" views (think dialogs, tabs, collapsibles, ...) are getting created/destroyed ad-hoc.

Main Store for a specific view holds the current data (which receives updates via gql subscriptions ~every second), the current filter which is applied to it's children (only show Apple related securities) and currently visible/hidden state of any children.

User/App/Global related attributes which don't change often are stored in a globally available object (and is easy for us as users don't log out or anything)

But we also have multiple smaller stores which are not connected to the root store. Think: multiple not-connected trees where each node is a store.

I must agree that both approaches have pros and cons, e.g. passing down data down a long path of stores is annoying.

Each widget can have a store, each section can have a store, each view can have a store, etc. You decicde what works for you.

(I use mobx in a large and complex trading application)

The on-caller for the specific service decides on how to produce.

The status dashboard is something which will be (manually, yes by hand) updated by an operations employee, who is a couple of layers behind the actual SWE/SRE who gets the page.

Can't think of going back tbh, really like it. One think I'm doing is checking emails quite a lot instead of just once/twice a day tho.

https://jamboard.google.com/

I think it's because I usually touch SQL like once a month and by the time I need it I already forgot everything :shrug:

If you know how latest react works you don't need redux or rxjs as hooks can solve most problems in a reusable way.

Example: https://github.com/oldboyxx/jira_clone

(╯°□°）╯

Give them a high level overview of architecture and best practices.

Let them work on very small features/bugs (update text, fix small issues, ...) s.t. they learn the process end-to-end without spending much time on code.

[^ everything until here could be done without human explanation if you have solid documentation and codelabs]

Give them small features to work on s.t. they can own part of the codebase.

[business travel] We are not allowed to do any business travel which means I had to cancel several NYC trips, which I was really looking forward too.

[travel] I had multiple flights booked for a variety of short holidays for the next weeks. Many of my flights have been cancelled or rebooked.

I live in London.

Their whole web developer advocate team is behind open web standards, and pushes it forward everyday. The engineering team actually working on Chrome is behind those standards, and pushes it forward. They work closely with other browser vendors. and try to make everything work everywhere.

Then there is the Chrome marketing team which has to goal (OKR) to increase the reach of Chrome. They might still support the open web, but their goal is to get more users using chrome.

But sending 1.3MB over the wire for a super simple website :D

Maybe the lower bound might be higher, but from my experience working in FAANG/IB/HedgeFunds the pay for normal SWEs (web frontend+backend, fullstack, whatever you wanna call it) was always higher than iOS devs. (most of the time much higher).