What are the pros and cons of this technique? Seems like this pushes a lot of the rendering compute power from the client to the server. I guess that is good for low power devices but now you need more powerful servers?
People working remote in other locations will have higher salaries from SV companies since they are used to paying those salaries.
People moving from SV to other locations should expect moderate drops (10-20%). In my own experience moving to a 0% state income tax state, it effectively canceled out the savings from CA tax but the cheaper housing more than made up for it.
Longer term:
Tech salaries will come down as employers hire from a larger talent pool that is cheaper on average. This will make it hard for people in SV to work remote as they won't be as competitive. This probably means SV will become more affordable.
> be compensated the same as those in SV?
Generally speaking no, compensation has an aspect of location. Companies are going to have a harder time paying SV rates if they know you are in a cheaper area.
Love how the probability distributions are presented. I wish those diagrams were in the material when I was first learning probability. Would have communicated the concepts so much faster and easier.
I think this is spot on. The problem lies in the incompatible interfaces.
I've been studying category theory recently and it is amazing how well things compose when interfaces follow monoidal / monad design patterns. They are so generalized that they can be used in so many different places. Unfortunately it is so rarely used outside of more academic environments.
If libraries/frameworks were structured to follow these kind of well defined "interfaces" I think we would have a very different experience than the one we have now.
We are doing this for simple data where we can but unfortunately having state in multiple locations (backend, memory, localStorage) means lots of cache complexity. How do you refresh and invalidate when the data are in so many places? We've opted to keep data in only 1 place as much as possible due to this exponential complexity.
We also have to be careful what we store in localStorage since it is relatively insecure.
I've had similar thoughts after learning category theory. I'm trying to develop a conceptual model where each different category (JSX, data layer, data fetching, validation, 2-way binding) cleanly composes.
With arcane nature of category theory not being common knowledge, frameworks, libraries, standards, etc, are unfortunately being created in ways that actually prevent patterns of composition.
It's almost to the point that I'm wanting to reinvent things from the ground up based on solid patterns of composition.
Have you done any work or discovered any patterns to make things behave more like the monoidal "<>" that you mentioned?
I'd be curious to hear stories of how people are integrating multiple different frameworks and build processes together. The article doesn't mention any details in that regard.
Anyone have experience with combining legacy Angular 1.x and modern React? My current work involves porting from Angular to React and we try to style each app to look consistent and just link back and forth between 2 apps depending on the feature. It has a lot of issues like the long reload times and having to fetch data from the API's again. It would be nice if styling and some of the code could be shared between the apps.
Anyone have some use cases or insights they can share in this regard?
In theory, yes, but in the case of GraphQL, I found it was very difficult to generate schemas dynamically. Factoring out common fields was not possible. Common fields in schemas had to be duplicated and there was no concept of an include/mixin/extends/etc. Best technique was generating plaintext strings of GraphQL programmatically (losing any editor or type checking support). Dropping down to the AST layer of GraphQL is a bit more programmatic but not really an ideal level of abstraction to work at. It was too verbose and low level.
REST integrates well with native JS constructs (it's just data) so it's much easier to compose and use metaprogramming techniques.
Can people share their experience and success stories with gRPC and/or GraphQL?
I've tried both in the past and found that APIs are rarely as static as typed API systems require. Many APIs have fields that are required conditionally based on the value of other fields. Other times the schema is dynamic and workarounds are required like stuffing things into a JSON object and making it a "string" in the API. This added a bunch of work to marshall it in and out of a custom workaround format.
In both cases (gRPC and GraphQL) we've run into so many issues that the technology was abandoned and we fell back to plain JSON REST.
Also loved the nand2tetris course.