Question about an alternative architecture without plugin-typescript

[nahuel]

What if:

1- You don't use plugin-typescript at all, avoiding any kind of in-browser .ts transpiling. 2- The development tsconfig.json is configured to emit system/ES5 modules to the dist/myapp folder:

    "compilerOptions": {
        "module": "system", 
        "target": "es5",
        "outDir": "../dist/myapp",
    },
    "compileOnSave": true

3- The dist/myapp package is marked in the SystemJS config as having "format" : "system", so it doesn't tries to transpile them.

Then, you compile TS from your IDE or using tsc --watch in another console, and the compilation output will be generated on dist/myapp in system/ES5 format ready for the browser SystemJS consumption.

Is this approach better / faster than in-browser transpiling using plugin-typescript? What do you think? I was thinking of going in this direction until I found this project, as I don't like to transpile in the browser if my IDE is already incrementally compiling it. This approach seems simpler to me, but maybe I'm not seeing some disadvantage.

[piotrwitek]

Hello, The main problem I think could be with single file emit, which was achievable only in https://github.com/TypeStrong/atom-typescript in Atom in time I was starting this project.

It wasn't even possible with compiler, basically it was some custom implementation patching typescript language server.

plugin-typescript achieve the same feature while loading in browser, and otherwise with tsc/editors other than Atom you'll have to emit all files always, which will always be slower than this approach, and also not scaling, because you'll get even slower with each new module added to your dep chain

[nahuel]

Isn't tsc --outFile single file emit? Besides that, I wasn't talking about using tsc to compile all the .ts codebase to a single file, but to make tsc generate a .js file (system/ES5 module format) for each .ts one. Then in development mode tsc --watch will be run manually or by the IDE, so when you change a .ts file his related .js file will be updated, and systemjs-hot-loader will be notified to update it at the browser. This is an incremental workflow, only the changed file is compiled and loaded. And in production mode you simply do a jspm build of all. So generating many system modules will be not detrimental to performance. Besides hot-reloading, I can't see how having many .ts files and making plugin-typescript load them and transpiling them in the browser can be faster than having the same number of system .js modules precompiled from .ts and making SystemJS load them in the browser without transpiling. Also note in this approach the TS compilation output is persisted on disk, and not transient in browser memory as with plugin-typescript.

[piotrwitek]

I'm not talking about concatenate outFile, with single file emit what I mean is to emit only modified module without emitting all the other in dependency tree. You cannot do this with tsc, it will always reemit all modules, please try that in some very simple scenario and check modify date of emitted JS files. And because of this issue your hot-reload will stop working correctly as it will always reload all the files.

[nahuel]

good point, I think tsc should re-compile the dependencies only if the signatures exported changed on the updated module. But given the current tsc behavior, I'm not really sure is slower than plugin-typescript for practical use cases. Usually tsc sits on background and is very fast, having the compilation results persisted on disk seems to be an advantage, and for many projects you usually don't change core modules with many dependents. Will experiment. Thanks.

[piotrwitek]

no problem, you might also search in TypeScript repo issues something more about this behaviour, maybe something changed in this matter, wish you luck :)