wasp-lang
Generate codebase in TypeScript
Right now we are generating codebase in Javascript. It might make more sense to generate it in TypeScript instead, to get extra type safety. On the other hand, Javascript might be easier to work with and make adoption of Wasp simpler.
To make introduction of TypeScript closer to becoming a reality, I think best first step is figuring out exactly how much work is this and what does it mean for the end user.
Some questions I have right now (my experience with TypeScript is very basic):
- Let's say we generate codebase in Typescript. Would users still be able to write React components and Queries/Actions in Javascript? I guess they would, since JS is subset of TS from what I remember reading some time ago? But could they do this without even knowing that the generated code is TS, or would they need to care about that? TLDR: If we switch to TS from JS, and there is user who is using Wasp via JS, will the change affect them?
- How much work would it be to do this change? From what I remember, migration to TS can be done gradually, right? So we can introduce TS compiler, all will work with existing JS, and then we can just modify part by part when we have time?
- Could this affect people to not want to use Wasp? Might somebody say -> hey, I don't want it to eject TS code, that is not for me, I use JS? I am sure that could be a problem for some, same as for some others problem will be that ejects code is JS and not TS. But what is better then, JS or TS? Hard to say I think. Maybe TS is better. It certainly is for larger projects.
- You can totally have a codebase with mixed JS/TS, it doesn't prevent you from doing anything in TS or JS. Users that would want to stick with JS or integrate generated TS files in their manual JS files could do it. The really interesting thing here is even if they decide to stick with JS, they would benefit from IDE autocompletion thanks to TS, even in their JS files.
- You would have multiple solutions :
- Rewrite everything now to generate only TS, since the project is very early stage, it's kind of still realistic.
- Migrate core features one-by-one to TS, could be a good solution, also it would allow to rethink the structure gradually, not all at once.
- Just generate .d.ts files on top of your JS generated code. Some libraries do that, but more because they were started more than 4 years ago and TS wasn't a clear pick at the time. I won't recommend it for a project starting in 2020 since plain TS will really help you throughout the development process of this framework.
- TS, hands down, it's better in anyway since one could use the generated TS functions and classes in their JS code, the opposite is not true. Also think of a CTO or an intermediate/experienced dev thinking about using your framework, nowadays, not having TS, at least typings, in a framework or lib is a red flag, I could name a plethora of framework I use everyday, from small to massive : Luxon, Amplify SDK, Apollo, Redux, Recoil, React... All major companies now provide nice typing for theirs frameworks. I can also see that every "cool" new lib/framework is rarely in pure JS now. I'm not a huge fan of the hype argument, but this time the hype meets a very very very good pattern (static typing), so it would be a shame not to follow it.
Also consider that the generated code could be better with TS types, because it would be more structured. Just look at what graphql-codegen generates from GraphQL queries to TS React hooks, it's very readable for generated code. https://graphql-code-generator.com/
Migration from JS to TS isn't going to take too much time at any scale. The sooner it's done, the better. Any larger company using JS instead of TS has a lot of problems due to lack of good maintainability.
Thanks @lucasbordeau and @bashovski , this sounds convincing, I am in :D! But seriously, that makes complete sense and I do agree we should do the complete migration relatively soon. I think it is not the top priority, since right now it is more important for us to make the current version of Wasp more full/rounded/complete, but after that (in a month or two?) it would be good to take a little bit of time to do a rewrite to TS.
I will leave this issue open and we can continue from here when the time comes!
I would use this as an opportunity to build a flexible system from the start. Don't get me wrong, I use TypeScript for everything but having the option to generate a codebase that is vanilla has its merits, especially when working with smaller web apps with very limited data types. In those cases you basically use no perks of Typescript at all. To pick the output type would be something quite powerful to behold.
Then perhaps one day the system could be accessible and flexible enough so that it could be compiling out nextjs, rails, laravel, kotlin, go or whatever other language or framework the community could imagine.
@krazyjakee that is exactly our "big vision" :)! What we really want to do is make Wasp in big part agnostic of the underlying technology, so that you can use React, or Vue, or Nodejs, or go, or any of the supported languages, and it will integrate with those and generate codebase in them. We are already keeping this in mind while designing and implementing Wasp. However, there is so much work even for just one stack, that we decided to focus on a specific one for some time, and once we get that stable and running, we will be looking into expanding into other stacks. For now that is React/Node/Prisma, all on JS. Main question for now is: if it had to be on just one stack, because it will be for some time, what is the best one, to drive adoption and help Wasp grow? We thing React/Node/Prisma is a good combo, but JS vs TS -> it is hard to say. We thought JS is better start for the simplicity, but static typing that TS gives is really nice and we heard multiple people asking if we support TS. Plus, people can still write JS even if we generate project as TS. So decision is slightly tricky here. I think we will be smarter when more people start using Wasp, we should have more information then.
not sure if it belongs here, but trpc's types are insane. typescript's types being turing complete (and the lack of principled design patterns for writing types) have put so much work on the IDE to communicate the contract of a type. The problem is that the types are not in code, they are generated dynamically which requires too much thought for someone to reason about.
Also, a note on graphql. I am still in the process of figuring out if graphql should be a technology that is exposed to the frontend, but my gut is currently tell me no. I have built a number of sites with the frontend querying graphql and there are a lot of things that it does really well, but I think it fails for a similar problem as with trpc; the types are too complicated.
I haven't built with RPC in a while, but I think the frontend and backend communicating with an RPC (with simple types) is correct. The backend can do whatever crazy data retrieval it needs to, but the frontend should only ever see the data that it was intended to access.
I believe that intentionally hiding data you can access on the frontend (and exposing simpler, more "agreed upon" types) is the best way to create a more future-proof application. This is why I am such a big fan of grpc. They have absolutely nailed the simplicity of a type system you interface with. Where grpc currently fails is a sane build toolchain, and hence why it is not used outside of big tech.
So, 1) I don't like trpc, the types are insanely complicated, and partially defeat the purpose of having types in code in the first place 2) graphql is really useful, but not always. it will get you going faster than an RPC, but in the long term might lead to confusing code since you can do everything and people will do everything 3) grpc has an ok type system, simple, but expressive types.
@breadchris oh interesting, thanks for this! I have to try them in more details, but this certainly motivates me to check grpc in more details.
So just to conclude, you think the grpc is the best solution, but it is hard to set up. That means that it might be a good choice for Wasp then, since Wasp can nicely set it up for people and they don't have to worry about that?