Why not simply use Javascript? Today it's a fine language. You may complain about fatigue etc which I can buy, but Rescript is simply not solving that.
I Switched from TypeScript to ReScript
31–40 of 49 posts
Re: I Switched from TypeScript to ReScript
#32Earlier quoted context omitted.
* no compile time I've been using vanilla JS when not using Reason and it is pretty nice. I hate that safari does not support arrow function methods though (as they allow you to not have to bind `this` in the constructor). concerning you post scriptum in brackets, what I like with types is: 1. refactoring becomes simpler 2. understanding APIs becomes simpler
Which version of Safari are you using? According to caniuse[0], arrow functions are supported in Safari starting with version 10, which is over four years old at this point. [0] https://www.caniuse.com/arrow-functions
[1]: https://caniuse.com/mdn-javascript_classes_public_class_fiel...
Re: I Switched from TypeScript to ReScript
#33Earlier quoted context omitted.
Which version of Safari are you using? According to caniuse[0], arrow functions are supported in Safari starting with version 10, which is over four years old at this point. [0] https://www.caniuse.com/arrow-functions
They said "arrow function methods", so I assume they're looking for public class fields support [1], not only arrow functions support per se. Public class fields (apart from static fields) are also supported in Safari though since September. [1]: https://caniuse.com/mdn-javascript_classes_public_class_fiel...
Re: I Switched from TypeScript to ReScript
#34Earlier quoted context omitted.
typescript is liteally a superset of js. what are your benefits
The biggest practical benefits of plain JS over TS are that: * code is terser * the JS standard is more stable/standardised * code can be distributed uncompiled * code has broader tooling support * code can be reasoned about and debugged directly and natively in web browsers without the need for sourcemaps/plugins/etc. * file sizes are generally smaller * there are fewer config files * there are fewer moving parts an…
And our code is setup to compile to ES2015, I believe.
The reason is simple. Typescript's compilation to JS is really straightforward. You can predict the code that will be generated trivially, because the vast majority of the time it does nothing more than stripping away types.
Since we compile down to ES2015, there are a few additional trivial transformations to handle unsupported features like "let" correctly, but they are also trivial to understand.
Re: I Switched from TypeScript to ReScript
#35Re: I Switched from TypeScript to ReScript
#36> Simply renaming the file extension won’t work, as the compiler stops completely at type errors. Why did the author think that this would work exactly?
Re: I Switched from TypeScript to ReScript
#37Re: I Switched from TypeScript to ReScript
#38Earlier quoted context omitted.
It's a common challenge with any kind of software; as a company, you want to avoid adding more to your stack, even if it means using a suboptimal or boring technology. Every new technology adds complexity and difficulty. Actually I'll just link it, it explains the concept much better (and with pictures!) than I can: http://boringtechnology.club/
TBH I'd stray from using TypeScript in your company stack as well, but I guess I'm just boring.
Re: I Switched from TypeScript to ReScript
#39Earlier quoted context omitted.
typescript is liteally a superset of js. what are your benefits
I'm not op, but here's my opinion: I'm willing to accept the basic hypothesis that's static typing makes for less runtime errors. The type system in well thought out languages like elm or rust makes coding in them pretty simple. I don't think that typescript's type system is good enough to actually deliver on this promise. It's very easy, in my experience, to spend 5 minutes writing a function that I am 100% sure wil…
I can only share my experience in multiple companies and products that it does deliver and it can result in a dramatic decrease of defects.
> I'm sure that this is partly due to my own lack of understanding. Typing is basically a huge add-on to the cognitive load when using this superset. [...] Of course, it could just be that I'm not very good at typescript. But it's a new technology, and it's very possible to find yourself on a project with people who aren't that experienced with it.
Tools don't come for free. You need to understand TypeScript in order to use it effectively. In my experience having at least a couple senior or principal developers with TypeScript proficiency makes a huge difference, not just because they can assist and guide you, but because with TypeScript they can create a well typed ecosystem that results in it being easier for developers to code safely and following a well thought-out architecture (or rather, make it harder to not do it right), and set up linters & autofixers and other tooling to make things even easier.
> Additionally, I think the type system really pushes you towards object oriented programming. This is fundamentally at odds with the way most people write ReactJS.
I'm curious what gives you this impression. The codebases I've worked with are heavily functional, with very little OO code —sometimes it makes sense— and if anything TS helps us do FP better.
Re: I Switched from TypeScript to ReScript
#40Earlier quoted context omitted.
It's a common challenge with any kind of software; as a company, you want to avoid adding more to your stack, even if it means using a suboptimal or boring technology. Every new technology adds complexity and difficulty. Actually I'll just link it, it explains the concept much better (and with pictures!) than I can: http://boringtechnology.club/
TBH I'd stray from using TypeScript in your company stack as well, but I guess I'm just boring.
Practically all major libraries provide a Typescript definition. Especially React, which has become the boring choice for a lot of client side programming. And you were going to end up using some sort of cross-compiler and packager for significant browser code anyway, just to wrap up all that risk about multiple browsers.
That's a bit less clear on the server side, where you have more control. But two things are going for you: if you're going to use Node you might as well use the same language on both sides, and you can cleanly escape to plain Javascript if you feel compelled.
(Personally I'd prefer a less sucky language, but honestly, TS makes JS pretty good. Not great, especially with all the legacy warts, but decent, and at least you get to share code with the browser.)
TS has survived long enough and become endemic enough that it doesn't look like much risk any more, and it's a vastly better language than plain Javascript -- especially for reducing the risks that come with long-term boring projects. If you're writing JS and like boring, Typescript is looking increasingly like the good, boring choice.