Putting multi-language support on hold

Hi,

In order to focus on community-building features and a smarter editor, we’ve decided to take multi-language support off of our current roadmap. We won’t be adding editor support for other dynamic languages (e.g. Ruby, GO, Python, etc.) in 2017.

We’re not deprecating or removing anything. Your existing Python projects will continue to work.

Transpiled JS/CSS/template-based languages (Coffee, Typescript, Elm, SASS etc.) are still supported.

Why we’re doing this

  • We want to focus on community-building features, like profile pages and teams that make coding more social, productive and fun. We’ve seen a lot of interest from educators and hackathon organizers and we want to help them out.
  • Having a consistent language allows us to build a more approachable Gomix community for new developers.
  • We can make a way better editing experience if we’re opinionated about what we build. This includes better collaboration tools, smarter debugging, and helpful intellisense-like features that tackle the frustrating parts of coding.
  • At the rate Gomix is growing, we won’t be able to provide customer support for multiple languages at a quality level we’d be happy with.

Some extra context

In the past, we’ve promised multi-language support because that was our plan. As developers ourselves, a lot of us have other favorite languages as well. What’s changed since then is that we realized that by doing less, we could do more for Gomix’s mission of making real web development enjoyable and accessible to more people.

Today, we have the architecture in place to support arbitrary build environments (i.e. Python). This unofficial support isn’t going away, and we’re totally down with anyone who wants to hack in runtime support for any language.

Hopefully why we’re doing this makes sense now, and please let us know if you have opinions, thoughts, feelings or dreams.

2 Likes

I wholeheartedly approve of this. Not just because I’ve become a fan of Node. I’m a huge fan of opinionated software and your opinions tend to be excellent. :slight_smile:

Language-wise, my big request is to double down on ES6 / ES2015. Like not having the editor complain about missing semicolons, for example. Maybe including Babel by default.

Amazing work on Gomix, y’all!

2 Likes

Good idea! I do happen to like Node, but at a slightly deeper level, I like using one language for the full stack: Node, JavaScript, JSON, CouchDB/CloudAnt.

I think you can achieve a lot if if you make more choices like this, steering towards certain preferred build tools, browser frameworks etc. By far the hardest thing about working in the web world is dealing with the sheer variety of tools, frameworks etc.

3 Likes

In general, I would agree with the idea of focusing. Support a bunch of different kinds of servers, workflows, etc., is an endless rathole in the world of webdev. :slight_smile:

I do wonder if there is a middle ground to allow support for languages like Typescript that output .js files, which are mapped 1-1 to the input .ts files. Especially since Typescript supports a tsconfig.json file that controls how it runs.

If “tsc” was simply running in the background, and configured to “watch” and incrementally recompile, any edits of the .ts files would be converted to .js automatically.

I so hate using vanilla javascript, and when I teach classes using javascript, I hate it even more, if only because Typescript provides type safety at compile time, which is super important for novices.

1 Like

Hi blairmacintyre,

yes, we do support this middle ground! :slight_smile: In general, any language that compiles to JS and that uses a package.json should be included - broadly speaking. Of course TypeScript is one of them!

You can write a custom watch.json file in which you can add your own watch rule, for example for TypeScript. In package.json, you can customize the start and install command in order to run what you need.

Unfortunately, I don’t know TypeScript well enough to write a good base project that can then be remixed as a starting point for TypeScript applications. If you are interested, you can do it :slight_smile:

I’ve created a very basic TypeScript project that has the custom watch rules and that calls tsc, you can remix and customise it: https://glitch.com/edit/#!/todo-typescript

It is taken and adapted from the TypeScript samples repository

2 Likes

@etamponi excellent! I’ll use this as a guide and see if I can get something working!

1 Like

Ok, next problem: I thought the samples weren’t recompiling, because if I change a .ts file (in my project, or a remix of yours) the compiler runs, the .js file doesn’t appear to change.

I thought it was because I was trying to use the directive "outDir": "public/build", in my tsconfig.json file to control where the .js file ends up, but it wasn’t working in yours either.

Turns out it’s just not reloading .js files in the editor that change “behind the scenes” … not sure how hard that is going to be to fix, but it would be great if it noticed a file has changed and reloaded.

1 Like

currently the editor does not have any logic in place to do that.

Do you actually need to see the .js files to make things work, or it is just for debugging purposes?

1 Like

I guess I don’t need to see them, you’re right. :slight_smile:

I just worry this is the kind of thing others would freak out at (change my .ts, check the .js to see what the results are, “OMG IT DIDN’T CHANGE, THE SKY IS FALLING!”)

2 Likes

possibly, but the way most people validate that their changes have worked, even locally, is by refreshing their built app. As long as we make sure not to break that contract (make a change, see the change) I think it’ll be the better direction to go for most people because it’s the same flow you’ll use for validating all kinds of edits (css etc.)

1 Like

I tend to agree, especially if they keep their build files (.js, etc) in a separate directory. I guess we’ll see! :slight_smile:

2 Likes