What does HackerNews think of DefinitelyTyped?
The repository for high quality TypeScript type definitions.
Mostly in typings either provided by the library itself or via the 3rd party DefinitelyTyped project. Some typings have been made so complex, that it is hard to follow what kind of concrete type is exactly expected or allowed.
Can you elaborate a bit more on this part, please? Or show us a mockup... doesn't have to be anything fancy, just like a pen and paper sketch or a simple Figma.
I'm asking because it kinda sounds like you're wanting to do something like an online IDE or Google Docs, where you're manipulating a body of text in the style of a rich text editor. If that's the case, it's possible the HTML DOM model isn't quite the right fit for you... you may find it better to abstract over a Canvas or WebGL object instead of trying to shoehorn that experience into the raw DOM. That way you have full control over rendering, outside of the normal layout/styling/rendering loop. It might also make a good case for a single-page app (at least the majority of the editor itself would be, and the other stuff -- marketing, blog, etc. -- can be routed to individual pages).
In that case, it wouldn't be so much a question of "framework" in the sense of React, Vue, etc., which traditionally work on the DOM. It might be more a question of "engine", like whether to use something like PixiJS to manipulate the graphics layer vs rolling your own. State management can be done with something like Redux (even without React), or if you choose to use a frontend framework for the rest of it, you can maybe use their state solution with your rendering engine.
In addition to choosing a low-level graphics lib, you can also look at some existing rich text markup solutions. A CMS I used had a good blog post on this: https://www.datocms.com/docs/structured-text/dast (especially the parts of about "abstract syntax trees"), along with their open-source editor: https://github.com/datocms/structured-text
That's one possible to way to deal with complex annotated text.
A more widespread one is the toast UI editor: https://ui.toast.com/tui-editor
I know you're not just working in Markdown, but these give you an idea of what it's like to work with complex text trees in JS.
Once you have the actual text editor part figured out, choosing the wrapper around it (again, just for marketing pages, etc.) is relatively trivial compared to the difficulty of your editor app. I really like Next.js myself (if you choose React), but I don't think you could really go wrong with any of the major choices today... React/Vue/Svelte/etc. And it looks to me like the complexity of your site wouldn't really be around that anyway, but the editor portion.
Lastly: I don't think ANY JS tool or package is going to be maintained in 10 years. Frankly, 2 years is a long time in the JS ecosystem :( I'm not defending this phenomenon, I hate it too, but that's the reality of it. If long-term maintenance is a goal of yours, you might want to consider writing abstraction layers over third-party tools you use, so you can easily swap them out when future things come out (because they will). The web itself is changing too fast for libraries to keep up; instead, people just write new ones every few years. An example of this is the pathway from the Canvas to WebGL to workers to WASM (and how to juggle heavy computational vs rendering loops around)... a lot of the old Canvas-based renderers, which were super powerful in their time, are now too slow vs the modern alternatives. Nobody is going to port the old stuff over, they just make new libs. It's likely that trend will continue in the JS world (that whatever you write today will be obsoleted by a new web API in a few years).
Lastly, as an aside, TypeScript is a superset of JS... if you find a JS project/lib/plugin that you want to use, there will often be types for it made by the community (https://github.com/DefinitelyTyped/DefinitelyTyped) , or you can write your own types for it. I don't really have an opinion about TypeScript vs writing in some other language and compiling to JS, but it would probably be easier to find help (especially frontend) in the future if you stick with TypeScript instead of convoluting your stack with multiple languages. Sounds like most of your app will be clientside anyway with limited backend needs.
---------
Tech aside... have you considered partnering with a frontend dev for this? I know you said "alone", but just having someone set up the basic skeleton of such an app with you for the first month or two could be super helpful. Or a UX person to help you with some of the interactions before you start serious coding. They don't have to be with you the whole journey, but maybe they can help jumpstart your project so you can then work on adding features & polish in your spare time, instead of figuring out basic architecture? Unless, of course, that's the part you actually enjoy. In that case, don't let anyone rob of you that :)
Have fun! Sounds like a cool project.
Linux:
$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ du -h linux/.git
...
2.8G linux/.git
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ du -h git/.git
...
120M git/.git
$ git clone https://github.com/DefinitelyTyped/DefinitelyTyped
$ du -h DefinitelyTyped/.git
850M DefinitelyTyped/.git
$ git clone https://github.com/home-assistant/core
$ du -h DefinitelyTyped/.git
380M core/.git
------
Nice! Thanks for sharing that link. I've done a bit of digging into that project before and it's definitely a very promising idea.
It has a lot of the same pitfalls as Dyno, imo, in that it would require somebody to define a "security policy" for every module to whitelist permissions.
But, it's also something that could maybe be attached similarly to how TypeScript types are "retroactively" added for existing vanilla JS NPM packages. Ie, packages that have never added their own type declarations (like `express`) can have their types added to DefinitelyTyped[0] and published as a separate NPM package (`@types/express`).
It works fairly well and something like `@endo-policies/express` wouldn't be crazy to add in later. Obviously it's going to be super painful, but fixing tech debt is always going to hurt.
vm2[1] is another Node project with some semi-similar goals that's worth mentioning. It's not designed to be "applied" in the same way as Endo, but it does give you a way to "sandbox" dependencies.
As a security person, I am weary to trust something like vm2 because it is much harder to "get right" than a "sandboxed-by-default" approach like Endo or Dyno. Look at this[2] CVE on vm2 from a few months ago for some evidence about _why_ this approach isn't ideal.
I'm optimistic for the future but we still have a long way to go before we get to it!
0: https://github.com/DefinitelyTyped/DefinitelyTyped
1: https://www.npmjs.com/package/vm2
A community repository would be super nice for those. Something along the lines of DefinitelyTyped[1], all managed through git, easily integrates with other stuff (like shown on npmjs.org when the @types package exists), allows maintainers to "own" the adapters they contribute by making a PR. It's really the N adapters * T time per adapter that really makes it hard for one person to do. That plus monitoring API changes/flakiness of each adapter to make sure the data is still solid.
npm install --save-dev @types/node
in general, typescript is optimized for cooperating with other javascript code, to make it easy to drop it into a javascript-based project, and also, it does not really have it's own "runtime". typescript is javascript plus types. in fact, if you want to convert from typescript to javascript, you can take a typescript-file, and just delete all the type-definitions and you get a working javascript file (there are some exceptions to this, but it generally is true). this approach has it's downsides of course, for example,when you need to interface with a javascript (not typescript) module, you can easily, but you have to know what types it expects and returns,otherwise you might get invalid structures in your code. there are things that can help you there (https://github.com/DefinitelyTyped/DefinitelyTyped), and it works quite well in practice, but there is no 100% guarantee that the types will be correct.
>> STRICT TYPING (in typescript) For example, the data might contain additional fields or even incorrect values for declared types.
- typescript is structurally typed most of time, so if you have a function that needs an `{a:string, b:string}`, and you send it an `{a:string, b:string, c:string}`, it will accept it. it's a different trade off,sometimes better, sometimes worse, compared to nominal-typing (https://en.wikipedia.org/wiki/Nominal_type_system).
- the part "even incorrect values", it should not happen in your own code. as i wrote above, i can imagine it happening when interfacing with other non-typescript code.
>> DATA VALIDATION: You have to write data validation code to ensure that you’re operating on correct data in TypeScript. You get this for free in Rust...
in typescript if you want to read,let's say JSON data,and map it to a typescript-structure, and return an error if it does not have the correct structure, you can use libraries like IO-TS (https://github.com/gcanti/io-ts/blob/master/index.md) to make that happen. i do not know how you get this "for free" in Rust, i know there are libraries like Serde (https://serde.rs/) that do it.
With Python + PyCharm, the default mode is to allow developers to exclude and ignore types and code will still run, no matter how many orange/red markers are in PyCharms gutter. To change that mode, you need to consciously decide to add something to your workflow that will impede you if something is wrong e.g. git hooks to run linters, flake8, black etc.
With TypeScript, the default mode is to stop the developer in their tracks - the TS compiler will fail, and you can't run code (generated JS) that doesn't exist. Types are not optional, unless you make them explicitly so (which is still providing a type).
> I don't see how types can work if no type information is provided.
TS can still import native JS code... given that it has a TypeScript declaration file [0]. Many popular libraries offer one now, but many more do not. The community came together and created DefinitelyTyped [1], where 10k contributors have made 65k commits to provide TS declaration files for over 5,200 libraries spanning countless versions/releases.
This means a TS developer can import JS code that doesn't have 1st-party TS support, but does have 3rd-party through DefinitelyTyped.
[0] https://www.typescriptlang.org/docs/handbook/declaration-fil...
A declaration file(s) could be included. There they could just declare types for all classes, methods, constants, etc. Similar to C header files.
(This is how the DefinitelyTyped repository handles typings for untyped source repositories: https://github.com/DefinitelyTyped/DefinitelyTyped)
Ex:
JavaScript: app.js
function app(arg1, arg2, arg3) {
// does something
return {
key1: someStringValue,
key2: someNumberValue,
};
}
declare type AppReturnValue = { key1: string, key2: number };
declare function app(arg1: string, arg2: string[], arg3: boolean): AppReturnValue;So I would say if you're interested pick one and dive in.
Right now typescript has a lot of community momentum: https://github.com/DefinitelyTyped/DefinitelyTyped
And an extremely fast, open sourced, plugin enabled editor, vs-code ftw! I am a convert after being a longtime diehard vim user. (vs-code has the best vim binding emulation I have ever used in a free open sourced editor)
Facebook is deprecating their flow atom editor plugin; nuclide - https://twitter.com/fbopensource/status/1072928679695548416?...
This is all why I would choose typescript over flow if it were up to me. maybe a flow user can chime in.
I see. Do you see this being a mono-repo of types that's under a Sorbet org or something Sorbet looks for in a gem if provided? Opening issues for a project's types with Typescript has been somewhat painful since many live in one repo [1].
Also, for those who get caught up rewriting types for existing libraries, I recommend you check this library first:
DT is "DefinitelyTyped", a github repo that consolidates type declaration files for open-source packages on npm.
Ironically, given the above comment, its tagline is:
> The repository for high quality TypeScript type definitions. (emphasis theirs)
Looking forward to more details.
Microsoft publishes a list of known good declaration files for popular npm packages to npm, under the scope @types: https://www.npmjs.com/~types
The 1.7 release of VSCode helpfully tries to automatically load type declarations for any npm package you use by requesting the equivalent declaration package under @types. When the package exists this is fine, because it's cached in our CDN.
What they forgot to consider is that most CDNs don't cache 404 responses, and since there are 350,000 packages and less than 5000 type declarations, the overwhelming majority of requests from VSCode to the registry were 404s. This hammered the hell out of our servers until we put caching in place for 404s under the @types scope.
We didn't start caching 404s for every package, and don't plan to, because that creates annoying race conditions for fresh publishes, which is why most CDNs don't cache 404s in the first place.
There are any number of ways to fix this, and we'll work with Microsoft to find the best one, but fundamentally you just need a more network-efficient way of finding out which type declarations exist. At the moment there are few enough that they could fetch a list of all of them and cache it (the public registry lacks a documented API for doing that right now, but we can certainly provide one).
If you're using a library and can't find bindings then I've found it's worth the time creating them yourself for any reasonably sized project. This is annoying and time consuming up front, but the benefits you get down-stream easily repay this initial investment.
For a few reasons, we chose Xamarin to build the Kato mobile apps. The end result was pretty good—great, even, considering the ridiculously tight timeline. We had a pretty elaborate common core with all the hard stuff (networking, caching, protocol, presence, etc), and custom UI code for Android and iOS.
In the end, since Kato was to be no more, the real benefit was seeing how much sense it makes to use a strongly-typed, object-oriented language for building complex user interfaces.
Many years ago, and for many years, we were C#/C++ programmers, so it wasn't exactly a revelation. But, we'd been working for quite some time with dynamically-typed Erlang and dynamically-typed Javascript (the Kato UI was built with Knockout.js).
Our server code was fairly straightforward and didn't change very much, so Erlang was an excellent choice there. With JavaScript, we'd programmed our way into some serious debt.
When deciding on a stack for Sameroom, we embarked on a quest to replicate the Xamarin experience for the web. We eventually narrowed in on Flux, React, and TypeScript.
After some experimentation, we got a development workflow working with gulp, shrinkwrap, make, and no particular IDE (we use Atom, Sublime, and Vim).
The biggest crutch was lack of JSX support in TypeScript, so splicing together HTML elements was pretty cumbersome. We viewed this as a temporarly incovenience, which was a good decision—TypeScript 1.6 got React/JSX in September 2015 [2].
We're pretty conservative about adding dependencies, but the overwhelming majority of libraries we do use have TS support available from the DefinitelyTyped project [3]. The few libraries that weren't supported (Stripe checkout and Intercom, if memory serves), we TypeScriptified ourselves.
As a result, working on the Sameroom UI is absolute joy.
It's a little ironic that, unlike Kato, Sameroom basically doesn't need a UI, since it's just marketing copy and an administrative dashboard.
[1] https://sameroom.io/blog/from-pivot-to-140-paying-customers-...
[2] http://blogs.msdn.com/b/typescript/archive/2015/09/16/announ...
I find it way, way, way more productive than plain old JS development without an IDE.
[1] https://github.com/DefinitelyTyped/DefinitelyTyped
EDIT: I always turn off optional any types, so everything has to be type annotated, even if that means I simply cast to an explicit . I find that non trivial problems in JS become so much easier in TS due to the compiler and built-in refactoring tools. I can't think of anything negative to say about TS at all!!!