I have a love hate relationship with Typescript. I have come to see it as a tool and to use it when it makes sense and avoid it when it doesn't.
I like the language at a conceptual level and find what it does very useful. The syntax I find less than desirable (especially nested generics).
For smaller projects I tend to use just JS because it's faster if I just want to prototype an idea and I'm not planning on keeping the code around for long.
Where Typescript shines is when working with a team on longer term projects.
The generic syntax gets derives from C++ which I don't think is a very good syntax. When dealing with more complex generic type declarations with nested generics / types your eye is scanning back and forth trying to match angle brackets and it is really hard to parse visually. Other languages like Haskell allow you to just read the "generics" left to right. Aliasing the type helps to some degree.
The other thing I don't like is when you are experimenting and fleshing out an idea you want to take a try it and see approach but with Typescript you have to really commit even though you just want to experiment. When you want to change something there is so much more code that you have to change.
The pros are when dealing with code you wrote in the past and forgot about what the types / parameters are or when dealing with code written by other people. Having the IDE suggest what you need to pass it is amazing.
The contrast to that is having to jump to a function to see what POJO style object it will return, what the exact spelling of the property / key are, and things like that. Having static typing saves so much time when dealing with other code.
If your project involves you working with others' code or code you wrote in the past and don't remember well then this is Typescript's sweet spot and it is a huge win.
One of the things I find most lacking in Typescript is pattern matching. If you have strong static typing like Typescript does then pattern matching pairs really well with that. It makes your code much more declarative and easier to read / write.
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.
People want to develop their tech on an open platform without vendor lock-in. If they pushed an open source platform on top of Kubernetes I know I would be more interested and comfortable using them. Right now I just don't see a strong benefit over others.
They can make the string part optional. Variables and symbol tables have been staples of programming languages and compilers for ages now. It's a very standard pattern. Nothing Rube-Goldberg about it.
But React has deviated so far from both the OOP, FP, and traditional programming paradigms that now it kind of feels like hacks are needed to compensate for hacks.
Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved.
But hooks creates abstractions the developer needs to deal with that never existed before.
Hooks are not functional because they break referential transparency of functions.
You have to track dependencies manually and hooks are more difficult than they need to be for the "componentDidMount" equivalent. If you don't get the dependencies just right you end up with things not firing or in infinite loops.
You have to wrap your functions in "useCallback" or "useRef" just so the reference doesn't change and cause infinite loops.
You can't create abstractions where a hook calls another hook. So you end up having to inline a bunch more code into your function rather than outsourcing it into a helper function.
The positional order seems like it would be easy to work around if they allowed you to pass in a key. Not sure why that isn't available.
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.
I like the language at a conceptual level and find what it does very useful. The syntax I find less than desirable (especially nested generics).
For smaller projects I tend to use just JS because it's faster if I just want to prototype an idea and I'm not planning on keeping the code around for long.
Where Typescript shines is when working with a team on longer term projects.
The generic syntax gets derives from C++ which I don't think is a very good syntax. When dealing with more complex generic type declarations with nested generics / types your eye is scanning back and forth trying to match angle brackets and it is really hard to parse visually. Other languages like Haskell allow you to just read the "generics" left to right. Aliasing the type helps to some degree.
The other thing I don't like is when you are experimenting and fleshing out an idea you want to take a try it and see approach but with Typescript you have to really commit even though you just want to experiment. When you want to change something there is so much more code that you have to change.
The pros are when dealing with code you wrote in the past and forgot about what the types / parameters are or when dealing with code written by other people. Having the IDE suggest what you need to pass it is amazing.
The contrast to that is having to jump to a function to see what POJO style object it will return, what the exact spelling of the property / key are, and things like that. Having static typing saves so much time when dealing with other code.
If your project involves you working with others' code or code you wrote in the past and don't remember well then this is Typescript's sweet spot and it is a huge win.
One of the things I find most lacking in Typescript is pattern matching. If you have strong static typing like Typescript does then pattern matching pairs really well with that. It makes your code much more declarative and easier to read / write.