15 ms·
TypeScript support in Electron
- cies 9y agoNext up: BuckleScript/ReasonML support :)
- ch4s3 9y agoIt would be cool to see a lot of the Electron app crowd taking up ReasonML. I like BuckleScript, but I think Reason might be easier to teach to JS devs. I'd love to replace my react frontend with ReasonML.
- akhilcacharya 9y agoI think what OP means is Reason compiled via JS.
- cies 9y agoYeah. BS bindings for OCaml-to-JS interop. Then using the Reason tools, as they provide a really nice workflow.
- tpetricek 9y agoOr F#: https://github.com/ionide/ionide-atom-fsharp/blob/develop/src/Components/Autocomplete.fs https://github.com/ionide/ionide-atom-fsharp/blob/develop/sr... This project has not been super active recently (because most of the people involved are working more on VS Code version of Ionide), but doing an Atom plugin with F# was quite nice :-). I linked the above file, because using nice `async` support and agent-based programming works really nicely in the editor context.
- deleted 9y ago[deleted]
- nahtnam 9y agoAnyone know what editor and theme they used in the screenshots? It looks like VS Code.
- plexicle 9y agoIt is VS Code. Same as the demo they posted: https://www.youtube.com/watch?v=PJRag0rYQt8 https://www.youtube.com/watch?v=PJRag0rYQt8.
- logiclabs 9y agoIt is VS Code (it shows this in the video). Looks like Light or Light+ theme
- MaxArt2501 9y agoIt's definitely VS Code and it's quite mind-blowing thinking that they're the guys behind Atom, and the blog's domain is electron.atom.io.
- jamesgeck0 9y agoAtom doesn't have built-in support for TypeScript annotations. I've gotten the impression that VSCode is somewhat more popular with the TypeScript crowd.
- glitcher 9y agoSince MS develops TypeScript they have a big advantage in making TypeScript a first class citizen in VSCode. I see many developers who would prefer a different IDE normally, but decide on VSCode because it seems to be ahead of everyone else on TypeScript currently.
- whatever_dude 9y agoNot sure that applies like that. Typescript support is based on the Typescript language server, which uses their open source language server protocol, which is open for other editors to use (and indeed adopted by a bunch of them). So in theory other IDEs could support TS with the same level of VSC as long as they adopted the protocol, without the need for discussion TS functionality.
- z3t4 9y agodoes typescript know if a parameter is undefined (misspelled) or does it only find errors like 1+'1' ?
- rcchen 9y agoit'll throw an error if a parameter is undefined, and https://github.com/Microsoft/TypeScript/issues/15333 https://github.com/Microsoft/TypeScript/issues/15333 which lands in the next version auto-suggests spelling corrections as well
- 0xcoffee 9y agoIt is a full static checking system, so it will find obvious errors like mistyping something, but it also infers alot of information from the context. I made a small simple demo here: https://www.typescriptlang.org/play/index.html#src=const%20example1%20%3D%20%22Hello%22%3B%0D%0Aexample1.length%3B%0D%0A%0D%0Aconst%20example2%20%3D%20Math.random()%20%3E%200.5%20%3F%20null%20%3A%20%22Hello%22%3B%0D%0A%0D%0A%2F%2F%20Error%20-%3E%20Object%20is%20possibly%20'null'.%0D%0Aexample2.length%3B%0D%0A%0D%0Aif%20(example2%20!%3D%3D%20null)%20%7B%0D%0A%20%20%20%20example2.length%3B%0D%0A%7D%0D%0A%0D%0Aconst%20example3%20%3D%201%3B%0D%0A%0D%0A%2F%2F%20Have%20fun%0D%0Aconst%20example4%20%3D%20Math.random()%20%3E%200.5%20%3F%20example2%20%3A%20example3%3B https://www.typescriptlang.org/play/index.html#src=const%20e... Note: Click Options and enable all the settings. Typescript works best in strict mode, but it seems options arn't including in sharing via url.
- z3t4 9y agoIt seems it can only find properties if they are defined as foo = {bar: 1}; and not foo={};foo.bar=1;
- koolba 9y agoOf course. That's table stakes for any static type checking. In fact to set a global value (ex: window.Foo) requires a bit of extra work to instruct the type check that your new property is not errant.
- fdsfsafasfdas 9y ago
- supernintendo 9y agoThis is exactly what I've been looking for! The only available type definitions for Electron I could find (up until now) were outdated. I'll be making good use of this. Thanks.
- habitue 9y agoFlowtype is seeming more and more like the Mercurial to Typescript's git. (That is, in terms of inertia, it seems like the community has decided on a winner)
- swsieber 9y agoIndeed. And I really wish Flowtype was winning because Typescript isn't sound (sound being a real technical term when referring to static tupe systems), and Flowtype is. On the other hand, I'll take ts over js any day.
- seanmcdirmid 9y agoType soundness is overblown. A type system doesn't need to be sound to be useful, and the pragmatic approach taken by TS has turned out to be really useful. (In the old days, type systems were just purely about correctness, so soundness was key, but those days are long past us, we depend on type systems for many different things now)
- raquo 9y agoIn my experience with TS, its unsoundness was very frustrating. If you use it as a replacement for JSDoc where type ascriptions are more like recommendations, sure, but I like to have more confidence than that in a type system. FlowType is much better in that regard. Scala.js has been the best for me so far.
- seanmcdirmid 9y agoI'm much more bothered by TS's lack of separate compilation (errors tend to cascade, but this is to be expected from a structural rather than nominal type system). The killer app for type systems has always been code completion.
- mafribe 9y agohas always been code completion. I disagree. Code completion is overrated and only of marginal importance in the production of high-quality code. The key advantages of types are: - Enabling ahead-of-time compilation resulting in efficient code. - Guarantees on the absence of specific classes of bugs. (This requires soundness.) - Aiding verification. Types provide a rough classification of program behaviour which drastically simplifies verification. If you don't have types, your program logic needs to make typing information explicit in assertions.
- dgreensp 9y agoResources for getting started with Electron+TypeScript are still not great, contrary to the tone of this article. I'm working on getting electron-compile up and running, and I currently have compilation but no type-checking. I don't expect it will be too hard to figure out, but it's not a five-minute task where you just start with a repo or follow a tutorial. There are various quick-start repos but they appear old. Someone let me know if I'm looking in the wrong place. This article and the accompanying video talk exclusively about the experience of editing code, not compiling it.
- deleted 9y ago[deleted]
- sillysaurus3 9y agoIt looks like there's a walkthrough video here, where they successfully get TypeScript working with Electron: https://youtu.be/PJRag0rYQt8?t=455 https://youtu.be/PJRag0rYQt8?t=455
- deleted 9y ago[deleted]
- donatj 9y agoFrom the video "Use --save-exact because […] we don't follow Semver"
- vorpalhex 9y agoWhy should I be cursed with the weight of your type system when I chose a language without types? If I wanted a typed language, I would use a typed language. JS has a lot of benefits. Being able to use JS to make native-ish apps has it's place. Being able to use typed JS to make native-ish apps probably means you should be using a different language.
- SpikeMeister 9y agoIf you continue to use Electron from JavaScript this changes nothing for you. You might get more helpful intellisense if you use vscode, that's all.
- jsight 9y agoYou aren't "cursed with the weight" of a type system if you choose not to use it. You can even still reap benefits from this without using Typescript.
- simplify 9y agoYou're complaining in ignorance. Type systems – especially TypeScript's – does not weigh you down as one might remember Java's does. It's there to help you prevent mistakes and ease refactoring. You're free to ignore as much as you want to.
- tootie 9y agoThis is for people choosing Electron in spite of JavaScript.
- vorpalhex 9y agoThen why use electron? Electron's entire purpose to let you use JS to build native-ish apps. If you want to use a typed system, then use a typed language that supports apps.
- StevePerkins 9y ago> If I wanted a typed language, I would use a typed language. If you're doing server-side development, then you have a million languages to choose from. If you're developing within the context of a browser engine, then the choice was made for you over 20 years ago. If you like that choice, then great. If you don't, then you transpile. Either way, it's silly to act as if there's a contradiction here.
- mohamedmansour 9y agoBest thing I done in my spare time 5 years ago was converting the entire JavaScript code base in Bing to TypeScript, that improved agility 10000x
- moron4hire 9y agoWith nodemon and live-reload, why is this an issue? I've been able to do TypeScript apps in Electron for months. Both adding TypeScript and Electron to my build process were afternoon projects. No, I'm not running TypeScript natively. But where else do we ever run TypeScript natively? Retranspiling on file changes works pretty well.
- charrondev 9y agoDid you read the article? It’s running typescript without a transpiler in electron (although I think there is a community project for that). It is about electron shipping their own officially maintained type definitions in the`electron` npm package for typescript users.
- pfooti 9y agoMy only wish for TS (which I use on the daily and love) is for some way to export type annotations at runtime. Like I'd love to inspect a class property and see if it is annotated as "this is a date" (in particular for deserializing JSON, which is a constant bugaboo for me). Right now, I just generate two parallel schema definitions, one that typescript uses to provide compile-time type safety, and another that's just a pojo to access at runtime to get more data.
- styfle 9y agoMaybe something like this? https://github.com/YousefED/typescript-json-schema https://github.com/YousefED/typescript-json-schema