Show HN: Codewich – A live-updating TypeScript/CSS/HTML playground | Hacker News Reader

HTML playground

codewich.com

114 pointscalebegg50 comments

I've found that there's almost no "first class" support for TypeScript in similar apps like JSFiddle, Codepen, Plunker, etc. If they do support it, it's only the syntax, not the autocomplete and error highlighting (the cool parts!). So I decided to try making my own.

Here are a few quick things I've written with it so far: https://goo.gl/zZy697 ("Flocking" behavior in a simple particle system) https://goo.gl/1q2kmr (Draw tiling patterns on a canvas) https://goo.gl/aio1rm (CSS-only card flip animation)

This is a neat project. One thing that might make it more immediately clear would be an "show example" button that randomly loads one of those three links.

I probably would have just left the blank page and forgotten about it if I hadn't seen your comment, but after seeing the examples, I won't forget the site for quite a while.

It was really fun to change some values in your Flocking script and see how the particles react.

I agree that it's a great example, and would be cool to have a similar example when you first load the site. Being able to play with code that exists is much more engaging than having a blank slate.

I wish Facebook would drop FlowTypw at this point. It's been a nice contribution and spurred some competition. But there is no real vision for how it's going to add a lot of value above and beyond TS.

One immediate benefit would be better support for react. Yes it works but not always as seamlessly as Angular/TypeScript.

I wish the same. Unfortunately not many devs are trying out TypeScript.

I've used React+TS for a year now. It works perfectly. The decorators in TS are great to use with the react-redux implementations - makes the code look less verbose

The only problems I have faced is when type definitions are not available for certain libs. The workaround is simple - using "require(...)" instead of "import .. from ..." statements

With type definitions available from npm and @types, its pretty easy compared to the TSD and Typings I had to use earlier.

TypeScript is the 9th most used language on the StackOverflow survey - ahead of languages like Ruby, Swift, and Objective-C - so I wouldn't say that "not many devs" are trying it out. :)

> Unfortunately not many devs are trying out TypeScript.

Really? I've seen so much hype for typescript (though not as much recently). How much is enough?

You should try the "allowJs" tsconfig option, it should allow to use the JS libraries without types with normal syntax (if you do that already with require trick, you are basically doing that anyhow).

Yeah, using Flow with React is painful. Which is weird, considering they're both from Facebook. Want to add a propType for 'children'? Sorry, nope. Want to use the equivalent of PropTypes.node? Good luck with that.

The biggest thing that I see as a barrier to entry for TS (and someone please correct me if this is no longer a problem) is integration with build tools from the rest of the ecosystem. Webpack with fancy loaders, third party language tools (linters, etc.), top-tier non-VS Code editor support, and so on.

TypeScript's strong part is the IDE support. It worked great with Eclipse years ago (using the same language server), it worked with Atom years ago. It has Sublime plugin that also uses the language server (not tried this myself). This is because the whole language is build with IDE tooling in mind. It's also approachable, as more language servers are being built the same way, like the PHP language server that is now gathering steam and will be used in several IDE's also besides VS Code.

Webpack and fancy loaders could be issue if you want type checking on really fancy syntax plugins. (Not sure what they are, since JSX is part of TS) These days you need one Webpack loader anyway for new ES features. It's really great that you can just remove Babel and use ts-loader in place as many of the ES features are already in TS.

The IDE support I yearn for is the really nice autocomplete support you see in tools designed specifically for TS. Last I used it, it was very flimsy in Sublime and Atom--very little in the way of helpful suggestions. Perhaps that's been improved, which I would welcome.

The loaders I use in webpack are mostly around asset loading. Style loaders, integration with other languages (coffeescript...ugh) for some weird legacy code, etc.

Flow is JavaScript (with type annotations) while Typescript is an entirely different language that needs to compile to JavaScript. You do not need any source maps for Flow as it just replace the type annotations with spaces. So you get to eat the cookie and keep it, while with Typescript you eat the cookie and lock yourself in.

This is completely untrue. If you follow the progress of TS, you'll see they are completely committed to only adding features that will end up in JS proper. Time and time again they have refused to add features because they aren't part of Ecmascript.

Making Typescript work in pure js files with commented types is a requested feature.

I have absolutely no doubt that it will get implemented sooner or later. Typescript + vscode team pay great attention to the community.

If you want to see it happen, this is the issue to vote on: https://github.com/Microsoft/TypeScript/issues/9694

No, this is hyperbole and misleading.

Follow their roadmap and stated direction. They have always been committed to aligning with standards and whenever ES adopts new functionality they gravitate to it's lead.

They will never drift off to some mutation that isolates you from the JS ecosystem or its benefits.

If you look up "embrace, extend and extinguish" in the textbook, you will see Microsoft mentioned in the first sentence [1]. If you are old enough to remember Internet Explorer, you've already seen how this works. Consider then that static types do in fact extend JS and perhaps you'll see why this is not so reassuring after all.

[1] https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

I appreciate you standing up to bad behavior of companies. The thing is that was a long time ago in a industry where things change very quickly.

MS has for a while now been opening more of its own systems, embracing linux, following standards instead going proprietary etc.

I'm not saying they've found Jesus, it's mostly pragmatic. A few new leaders have found that this approach simply works better and is less douchey at the same time.

So I would say let go of the EEE era. There is lots of bad behavior still going on that is a greater threat. They could benefit from your energy.

In 2017 blurting out EEE every time MS does something good is spreading FUD.

Typescript is an open language anyways, there is nothing to extinguish

As an employee, I can tell you that the company culture has completely changed. I came in to MS a few months before Windows 7 released. I was just about to quit, when Nadella took over. I decided to wait it out and see. I am glad I did.

EEE died a long time ago. It was pretty much gone under Balmer, although we still didn't really play nice with others. Nadella on the other hand came in, started mending fences with other companies that we had previously ignored, or even had some hostility towards. Let me contrast some differences.

Balmer -> Gave all employees a Windows Phone and got pissed if he saw an employee with a competitors phone. I even saw him pretend he was stomping on an iphone at a Company Meeting. Nadella -> Put out a video from himself stating "Unless you work on certain parts of the Windows team, use whatever device want.

Balmer -> Had Office for IOS and Android mostly feature complete and wouldn't release it. Nadella -> Released it quickly after becoming CEO.

You are insane if you think EEE is still going on. That was over like 10. I'm going to skip Balmer as I am sure you can imagine, these are not things he would have done.

Right now Visual Studio for Mac is in preview. We purchased Xamarin and as far as I know it is now free for everyone except Enterprise.

In the last release of Visual Studio, we shipped Chrome as an optional addon.

Released Visual Studio code which is open source, built on open source products from GitHub and Google Chromium.

Open sourced .NET and made it cross platform. This also enabled us to release PowerShell as open source.

Added Bash on Ubuntu on Windows to Windows 10 by collaborating with Canonical. Seriously? Let that sink in @wiredearp. You can now run native command line tools in REAL linux running on Windows.

Invited the Angular team from Google to get a sneak peek at future plans for TypeScript. After the saw it they dropped AtScript and used TypeScript to build Angular (formally known as Angular 2). It is now the preferred language to consume it as well.

SharePoint, the product I work on will soon open source our new app model which now runs on a standard open source web stack. Webpack, gulp, React, all accounted for.

The static types in TypeScript add value, they weren't added as part of some scheme so later we can... what? I can't even imagine a nefarious end game.

No disrespect intended at all, but if you think this is the Microsoft of the Netscape era, you seriously haven't been paying attention.

What's an example of a TypeScript program where erasing the type information won't produce valid ES6? I had thought Flow and TypeScript were the same in this regard, but I am not an expert.

TypeScript supports ES7 features, for example. It also has a few language-local quirks (like parameter properties, described https://www.typescriptlang.org/docs/handbook/classes.html ).

I find the grandparent argument pretty unconvincing though. People writing Flow are generally using JSX or ES modules (the Flow docs recommend the latter, for example), both of which require a transpiler like Babel to be used in a browser anyway.

I believe that one area where TS could stand some improvement are multi-package projects. https://github.com/Microsoft/TypeScript/issues/3469

Couldn't the same be said about TypeScript? "I wish Microsoft would drop TypeScript at this point. It's been a nice contribution and spurred some competition. But there is no real vision for how it's going to add a lot of value above and beyond Flow."

This is a bit meta, but both of you stated a position without providing a concrete rationale.

Something to consider is that people can gloss over an explanation for convenience. For example: in the previous sentence, I didn't provide any proof that it's accurate. You could make the argument that nobody glosses over explanations for convenience.

I don't think it's necessarily worth proving every statement, because that'd be extremely time-consuming. But if you provide an opposing viewpoint, back it up with clear reasons (this helps filter out positions that are undefendable), and I'm interested in defending my position or continuing the discussion, then we can have a meaningful discussion from that.

> This is a bit meta, but both of you stated a position without providing a concrete rationale.

The primary difference being that "my position" was not actually my position, it was just an attempt to point out exactly what you're trying to say.

I guess I failed ;)

So you disagree or just were wanting to understand the backstory? I would try to help you but the sarcasm makes it unclear the best way to do that.

Neither. I think Flow and TypeScript are both great solutions, and neither is clearly better at this point.

This is quite possibly the coolest thing I've seen so far.

I would be quite happy if you added some collaboration controls (give read access without giving write access) because I could use this for a lot of our training.

I just put together a websocket demo for anyone who wants some live documentation on how to integrate actioncable-js with their non-actioncable enabled application for client-side updates ->

https://codewich.com/#v1,,,bVHLTuMwFGWNxD9YHiQSiTriMSwKqdTpA...

This is not related to the typescript aspect which, I realize, is the point of this contribution.

I really like these code playgrounds but my main issue almost always comes down to flexibility regarding which code I can keep private, which I can make public, and so on.

Just something to keep in mind as you decide to take this ahead.

Now to play with some typescript.

https://github.com/calebegg/codewich#features:

>>> Code snippets you write are automatically saved in a compressed form in the URL. This has a few benefits:

- Your code never leaves your machine unless you decide to share your URL. Since the snippet is stored in the URL fragment (the part after the #), the CodeWich web server doesn't even log your code snippets.

- You don't have to rely on CodeWich's availability. You can download your own copy and run it locally, or host it somewhere you control, and you'll always be able to decode your CodeWich URLs to get the original code.

Oh wow, so is that why someone can paste an example and when I click on it, I can see the code?

Codewich reproduced it from the URL?

p.s.: the more I think about it, the more I like it but is there any fear that some programs can't be compressed into a url?

p.p.s maybe not: http://stackoverflow.com/questions/417142/what-is-the-maximu...

I agree completely. One of my goals with this was to make it entirely client-side. Your code is never sent to my server. It's stored in the URL after the #. You can share it by sharing the URL, but otherwise it's yours.

I've also provided a standalone version on Github which you can download and run locally or install somewhere in your company's intranet for internal use. It has no analytics and no outside communication.

https://github.com/calebegg/codewich/releases

If there are other ways to support this use case, let me know. I'm open to suggestions.

I saw that solution in the other reply.

Really smart and (to me) original.

This is the cleanest layout I've seen for one of these playgrounds. 95% of my screen estate is the editor and preview - you shot the UI off the side and kept it out of my way. Thank you for that! The only thing missing for me are transpilers for CSS/HTML. I'm a bit spoiled in being able to use SCSS and Pug over at Codepen. Between choosing between autocomplete/error highlighting for .ts or SCSS/Pug support I sadly will pick the former.

I'm totally understanding if the only goal is to support .ts and there are no future plans to add scss/pug support, but I'd switch to using this in an instant over using Codepen if it ever gets added!

I'll play around with it and let you know my thoughts after I use it a bit. :)

Glad you like the simple layout!

One of my goals for this is to avoid anything that requires a backend and do everything in the browser. This lets you keep your code private and makes Codewich basically maintenance-free (hopefully). Looks like sass can run in the browser with emscripten, so that should be possible, but seemingly not pug?: https://github.com/pugjs/pug/issues/2655.

Feel free to file an issue for SASS if you'd like to track the progress. https://github.com/calebegg/codewich

Good idea to encode the code in the url.

Unfortunately I think Chrome has a limit on the length of url you can paste into it. I tried copying the url of a slightly longer code into text editor and a new Chrome tab, the latter failed with a audio signal.

Am I missing something or are there no example projects? I'm a typescript dev but it would still be helpful to see a few working examples when I hit the site.

This looks interesting. I've been wanting to mess about with TypeScript, but had only gone so far as scanning through the tutorials/intros. Nice to have a sandbox setup from the start.

Also, really enjoying your "Flocking" script. Well done.

I use TypeScript in my startup - it's great and provides a lot more code stability over raw JavaScript but as you build up your type definitions you will likely hit a "roof" where TS doesn't support the next feature you would logically want. There's also no reflection on interfaces (as they're a purely compile-time construct like C macros) which sucks if you want no-noise DI. But overall it's really awesome and getting better with every release.

What do you mean by "the next feature you would logically want"?

well in my experience, and this has happened a few times with different requirements which is why I was generic, what happens is you try to use more and more of TypeScript's features to get strict typing (keyof, mapped types, discriminated unions etc) and they work great for 80% of cases. Then you push the feature too far and it falls down. For example, I managed to get tsc to hit a "stack depth exceeded" error by adding a minor variation on an existing complex type that I'd created. I find with TS types, less is very often more unfortunately. I'm trying to use TS like Haskell and it just doesn't play ball.

Yes, TS does have limits. Its still very expressive compared to most mainstream type systems.

Cool, is this using the Monaco editor from VSCode?

If you take a look at the Sources it looks like it does use Monaco.

> It's similar to JSFiddle, JSBin, CodePen, and others

So then what's the benefit? Doesn't codepen support TS?

Codepen supports TS but not inline error highlighting or autocomplete, which I think are some of the more worthwhile features of TS.

https://news.ycombinator.com/item?id=13950079

I like the way you did intellisense, it's flawless.

I can't really take credit for that; it's pretty much provided out of the box with Monaco (the editor used in VS Code): https://github.com/Microsoft/monaco-editor

ha :) good to know!

Reply on news.ycombinator.com