TypeScript is a great improvement over JS, still held back by the horrible state of the JS module system in browsers. You write your code and it does what you want, then you spend a month figuring out amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack vs god knows what else.
And then when you find the solution that works.. two weeks later it is deprecated, the docs are gone, there is no clear migration path, and there are only conflicting blog posts full of misinformation by people that only know what worked for them and don’t actually understand what it is that their steps actually do or how they work.
(Yes, as you can tell I did not start off life as a JS web developer. TypeScript made the development part palatable to me, but the deployment remains a nightmare as far as I can tell.)
I wonder if the TS team has explored using webasm to at least get around the compilation/translation issues.
Edit: I actually know the difference between the technologies I mashed into a single list (they’re not arcane concepts in low level development, it would be akin to confusing make with clang++ with gdb with Linux with ARM). I didn’t bother spelling it out because it’s not the point (I don’t have a specific question) and because to too many people that is what it seems like.
I love that there are currently two replies to you, both implying you're an idiot for not knowing how to do this, and both presenting different solutions.
I never called him an idiot, I just called him out for not researching at all before posting. His understanding of Javascript has not been updated in at least 3 years based on the fact that he called ES6 ESNext, even though ES6 has been released for almost 3 yars.
There's also two different compilers for C, but it's not considered complicated to get started running a C program.
I wasn’t referring specifically to ES6 when I said ESNext, I was referring to the ever-evolving “this willl be addressed in the next ES release, just add ESxxx as a flag to the zillion build systems and you’ll be good to go,” as well as simultaneously referencing the ES module system.
My post was not intended to be taken literally. It was a rant, I’m sorry for the lack of precision and effort. (Not being sarcastic.)
Do you count the number of vendor DLLs when you develop .NET applications using third party libraries? Of course libraries will have dependencies.
You are only "blindy mashing" three libraries here. Gulp to manage your workflows, Typescript (because that's the goal of your workflow) and Babel to allow older browsers to read modern Javascript. You can cut Babel out of it if you develop something for a modern browser (internal apps, mostly).
That's three widely used dependencies. There is nothing obscure about them at all. The only questionable choice in that tooling chain is Gulp. The reason I used gulp here is that it's very easy to use it to output simple Typescript. Something such as Webpack and Browserify would be for bundling modules and that's an advanced topic.
Right, I forgot to mention the duplication of build systems between TypeScript’s own, webpack, npm, gulp, and others.
Ironic that you speak of "blindly mashing things together" - how many different build systems did you mash together there, hidden behind a meta npm package?
The web needs CMake or meson more than C/C++ ever did.
Don't be act like an idiot simply to make a point. You simply come across as some elitist programmer who can't be bothered to learn frontend tooling.
All of those technologies are simply Javascript running serverside (or developer clientside during the development).
I sent you a gulp example because gulp it's very easy to use and you can quickly build customized build processes with it.
"gulp-typescript-babel" is simply a wrapper for "gulp-babel" and "gulp-typescript" which are both simply Javascript libraries. Read their source, there's nothing complicated going on in there.
"gulp-typescript" simply wraps around "Microsoft/TypeScript" and make it easy to pipe into gulp.
"gulp-babel" simply wraps around babeljs and make it easy to pipe into gulp.
"babel" is simply a lib that polyfills and rewrite your next generation JavaScript into code that older browsers can understand.
You originally said "then you spend a month figuring out amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack vs god knows what else.". I sent you this snippet to show how simply it is to build TypeScript.
Oh look, I explained to you a "month worth of research" in a simple HN comment... ! You could have googled it and read a blogpost about it instead.
Sorry for being harsh but if you need a month to figure out how to run Javascript on your computer you need to consider a new career.
You've crossed into incivility in this thread. We ban accounts that do that, so please read https://news.ycombinator.com/newsguidelines.html and use the site as intended—i.e. posting civilly and substantively, or not at all—regardless of how annoying another comment might be. We all get bitten by the annoyance bug sometimes.
I apologize (that goes for both you and mainly for ComputerGuru), this was not my purpose here. Please do delete this comment thread as it clearly goes against what HN stands for. Negativity isn't one of my values and I'm sorry for it. As you said, the annoyance bug bit me hard.
First of all you probably shouldn't complain about the JS ecosystem if you barely know anything about the JS ecosystem. This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable. Babel is a compiler, ESNext is a language specification (now ES6 since after being been finalized more than 2 years ago). amd, systemjs, requirejs, and browserify are all still supported and have not been "deprecated" as you say. However for the last 2 years Webpack has been the dominant module bundling system since it's incredibly powerful and extendable.
The standard for about 2 years now has been to use Babel + ES6 imports with Webpack. Babel lets you write ES6 code that compiles back to ES5, which means older browsers can run it. This means you can write modern code with patterns that will never get deprecated that works in older browsers. Webpack takes some configuration to fine tune it for large apps but getting it set up for a small app is pretty painless these days, and it continues to improve.
I'm honestly kind of sick of there being someone in every comment thread bursting through the door to tell everyone about all the bloat in the JS ecosystem. It's largely been solved and there's a lot of maturity in the libraries in use now. I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated.
However a lot of guides (even some officially sanctioned ones iirc) use Babel to transpile typescript in the browser, forgoing the precompilation to JavaScript entirely.
I don’t know if that’s just an artifact of days gone by, an attempt to bypass tsc before it gained on-the-fly watch-and-compile support, or for another reason entirely.
I think you're getting Babel and SystemJS confused - the latter allows you to use TypeScript files as the source attribute in script tags and have it transpiled within the browser, which is sometimes used in examples and tutorials because it avoids any need to use the command line or configure a new TS project.
>This is evidenced by you bundling several things in your "amd vs esnext vs systemjs and Babel vs browserify vs requireJS vs webpack" which aren't directly comparable.
"amd vs esnext vs systemjs" is about module formats.
"Babel vs browserify vs requireJS vs webpack" is about transpilers and loaders.
Thanks for taking the time to write out this reply - my initial comment sort of took on a life of its own, it wasn't originally supposed to turn into a rant and was never intended to be taken literally or to imply that it had been precisely crafted. I appreciate your responding to it nevertheless.
I am actually very aware of the differences between the various components, but I am appalled at just how many cogs it takes to get things working _with 3rd party libraries involved_. It seems as soon as you bring in a single dependency, Pandora's Box is opened and you suddenly have to bring in 12 different build systems along with it.
> I think a lot of the frustration came from people who liked just pasting a script tag to add new libraries to their frontend, and any system which requires them to actually think and configure before pushing to production is considered too complicated.
In my case, it's the other way around. I don't think you understand how much of a breath of fresh air being able to "just paste a script into your html" was for people that came from complicated build systems that required you to locally download, build, and install each dependency your code relied on because there was no module system and there were no URLs or CDNs or whatnot. What is sad is that JS, after seeing how horrible of a mess the C "module" system was, went down the same road when they could have embraced better alternatives and iterated html/browsers in-step with JavaScript to come up with something that wasn't such a mess.
I confess to not being a JS history expert, but as I understand it, require came from node running locally before people tried taking that to the web, and thus requireJS was born. Only it needed a mess of other components to get it to work with existing libraries. And then those 3rd party components were deprecated or replaced by newer iterations, sometimes by the same developers or sometimes by newcomers to the scene. And no one bothered with compatibility with existing systems, except people that drew up a type of "super standard" that encompassed n other types by simply multiplying their complexity instead of reducing it.
We went from being able to get a web app up and running with an HTML file and a single JS file, optionally combined into a single document, to requiring a dozen different build systems, separate compilers and transpilers, many layers of abstraction, required preprocessors and optional in-browser on-the-fly compilers, OS-specific tools, library-specific module systems, and a million different ways that a single statement ("export") could be translated into code, or the dozen different gotchas that you need to consider when you type in that one word ("import") because you'll have to dig up the documentation for the library you want to use to find out just how it exports its interface.. and then you need to make it play nice with the framework you already have in place.
We went from writing every line that of code that appeared in the browser to writing a simple "hello world" that require an insane 10x or 100x payload to run it... and only after studying the various build systems and trying to figure out which was old enough to be supported but new enough to still be around for longer than it took to learn JS itself.
With regards to deprecation, I personally (though not even a web developer by trade) ran into the official deprecation of both bower and typings; and while requireJS and co may not be deprecated per se, if they're not the "right" way of starting a new app today then they are deprecated because your time is better spent learning skills that will still matter tomorrow and sooner or later for a living app you will need to replace them with something else to be able to use the latest version of dependencies and libraries.
You can still write simple apps by just putting in a script tag, that never stopped working. However, if you want to write a complicated app, then you've already accepted that you need complexity and thus you should be taking the time to evaluate different build systems, pick the right one, and settle on it. Like I said, there are multiple mature solutions to do that.
The fundemental problem is that you are either trying to write Hello Worlds with enterprise-grade build tools or that you're trying to write web apps with single script tags. Your hello world with React + Babel + Webpack is going to be big. That's the point, you're importing an library that is built to make extremely large complex web apps simple to make, therefore by definition that library has to be big and complex. But the joy is that you can then build out an entire web page with significant reactive functionality in a matter of hours.
I get that looking at a lot of options makes things look scary, but you only need to look at those options once you're ready to build something big. And big is going to be scary regardless. Until then, you will have no issues just importing a script into your web page for the little things.
And then when you find the solution that works.. two weeks later it is deprecated, the docs are gone, there is no clear migration path, and there are only conflicting blog posts full of misinformation by people that only know what worked for them and don’t actually understand what it is that their steps actually do or how they work.
(Yes, as you can tell I did not start off life as a JS web developer. TypeScript made the development part palatable to me, but the deployment remains a nightmare as far as I can tell.)
I wonder if the TS team has explored using webasm to at least get around the compilation/translation issues.
Edit: I actually know the difference between the technologies I mashed into a single list (they’re not arcane concepts in low level development, it would be akin to confusing make with clang++ with gdb with Linux with ARM). I didn’t bother spelling it out because it’s not the point (I don’t have a specific question) and because to too many people that is what it seems like.
Edit 2: Please see my reply to @coltonv below: https://news.ycombinator.com/item?id=16278062