VSCode + TypeScript is an amazing experience for us poor JavaScript developers that never enjoyed proper autocomplete and refactoring in our editors. Writing JavaScript feels like writing random bash scripts with no help now. TypeScript is freaking awesome and you should start using it! :)
Try WebStorm. I'm surprised at how few people use it, given the quality of the autocomplete and code assistance (and the fact that it works just as well with ES6 as it does with TypeScript!)
> On this day and age many don't want to pay for tools.
Strange logic: if everyone followed that train of thought, we'd all settle for whatever quality tools are available so long as the price is $0. I'd much rather pay for a valuable tool than use a subpar free tool.
It's a common fallacy to associate quality with price. Generally yes, but not always. Sublime Text certainly isn't 70 dollars better than Atom or VS Code.
For me, it is. Some of the main points that makes it worth money to me are the plugin ecosystem is huge, the editor is fast, its layout management (panes in columns/rows) is incredible, and it was the first editor I had that gave me multi-cursors. I like where VS Code is going and I try to use it when I can, but most of the keybindings and shortcuts I have memorized are for Sublime and IntelliJ based IDEs.
Eh but it existed for long before Atom and VS code. (disclaimer I paid the $70 and felt it was well worth the money at the time, these days yeah maybe I wouldn't but I still do find myself using it a lot)
Edit:
To expand, sublime is still by far my favorite TEXT editor. I just don't find doing everyday text editing tasks in VSCode to be pleasant at all, its an amazing IDE though!. Atom is much better for the task but the responsiveness and large file handling capabilities of sublime makes it the clear winner. If you already paid the $70 for a licence back when atom didn't exist anyways...
I wasn't only associating quality with price, but also pointing out that many of the 2016's Emacs and vi users would not use them if they were only available as commercial software.
Regardless of their quality, because the actual IT generation wants to earn money with tools they got for free (beer), while other professions people do pay for their tools.
> Regardless of their quality, because the actual IT generation wants to earn money with tools they got for free (beer), while other professions people do pay for their tools.
You seem to feel strongly enough about this to repeat it nearly word-for-word in multiple comments. Trust me, every profession wants to pay less for its tools. And no one, in IT or out, is choosing their tools "regardless of quality".
I feel strongly about it because this mentality reduced the market of selling software tools to a niche, to the point that to earn money selling tools, we have to sell them to enterprise customers, the only ones willing to pay for software.
This is why most companies selling such software tools have switched their basic versions from "trial during X days/trial license" to free (beer), while trying to seduce developers to eventually pay for the full version.
I think it depends on how much you treasure battery life. Electron based apps suffer from poor battery life due to the Chromium unpinning. JS is resource intensive compared to C++. You can probably get an extra 20-35% battery life out of Sublime vs Atom. If you don't have the ability to plugin while out, it might be worth the piece of mind.
Are you working on a project that makes money? Will a productivity tool increase your productivity by half a percent? Then that tool is worth hundreds of dollars. If not thousands.
It is not a strange logic and I am not talking only about quality.
I am talking about IT being one of the few professions in 2016, with individuals that expect to earn money while using tools produced with the effort of others for free (beer), while not giving anything back (not even bug reports, unless their own customers press them against the wall).
So the question isn't about the quality, rather how many Emacs and vi users would have actually payed for them, if they were only available as commercial software?
Vim is charity ware actually or at least that's how it was qualified when I started using it. Most of the long time vim users I know have donated several times. Vim and Emacs also have shit loads of plugins, which can make them behave just like Atom or VSCode so as usual I think it's just a matter of preference.
Intuitiveness is honestly a relative problem. I've been using vi for a long time. What's intuitive to me? Moving my cursor with hjkl is intuitive to me. Using `C-w h` to move my cursor to NERDTree, then searching for my file with `/filename` and opening it with enter makes taking my hand off the keyboard to move my mouse to double-click on a file seem absolutely barbaric.
Not to mention that VS6 had one IDE per language instead of having it all integrated into one, so when you used both VB and C++ you'd have to put up with a drastically different UI for each language.
I had one of those aha moments last week. I started to write to complain to Microsoft that VSCode didn't remember my previous searches when I remembered that I could just hack it in myself, which I did. Most programmers like me like that kind of control.
Honest question as I'm not really part of the open source world:
1. What happens to your change when an update comes out? (Or, do you keep up with updates)
2. Having just merged my first ever pull request, how does a project stay coherent with possibly hundreds or thousands of people submitting their 'hacks'?
My fix is just a quick hack and not polished enough to submit, so I'll just reapply it. I'm guessing that the vscode programmers will add a search history and I won't have to keep doing this.
Pull requests and forks, you can fork a project and keep it up to date with the master. People's hacks are not included in the source code, they're free to fork the project and implement their own hacks and submit a pull request to get their solution included as part of the master if it is approved
Well, not everything. Language support cannot be implemented by relying on an external service (like the typescript service), it has to be implemented in a very specific way.
The TypeScript service is not from Jetbrains, but coding assistance like type inference and auto-completion options have thus far always been this IDEs own implementation [0]:
> This assistance can be provided either by IntelliJ IDEA itself, or based on the data from
> the built-in TypeScript compiler, or through integration with the TypeScript Language Service.
They bundle whatever latest TS is available when the product is created or let you point to your own installation. "Use TypScript Service" is marked "experimental", so letting the IDE use the external service for things it traditionally figured out on its own to provide coding assistance is being worked on.
WebStorm and PyCharm are both (more or less) repackaged versions of IntelliJ with specific plugins. WebStorm is cheaper and just includes the JavaScript support (and other related languages/tools) and PyCharm includes both JavaScript and Python support. So everything in WebStorm is also in PyCharm.
I think people find it a little overwhelming, if they aren't familiar with other IntelliJ editors already. I did. Of course Visual Studio is just as overwhelming, but more people are forced to be used to that.
120 is for businesses. For individual developers its way cheaper: € 59.00 /1st year, € 47.00 /2nd year, € 35.00 /3rd yr onwards. And you can cancel your subscription if you are OK with 1 year old version that you will fallback to.
In fact, you are paying $120 for a license and then getting a year's worth of free upgrades. After your subscription ends, you're still allowed to use that version.
I use both, well not so much Webstorm, but IntelliJ for Java/GWT application stack and Visual Studio Code for almost everything else (Python, JS, etc).
Works pretty well, although I think I could increase productivity if I align the keybinding for both of them (i.e. quick open, find, etc)
I pay for a IntelliJ Ultimate license. I am so happy about it. It supports all I want. PHP? Java? Python? Ruby? all you want baby. Consistent UI across all your environment. Solid. Pretty fast. Good Vim plugin. I have absolutely 0 complains. An essential asset.
When I'm on OSX I'm exclusively on Webstorm.
When I switch for my personal work to Windows I mostly use VS Code. Webstorm just doesn't render the font, the IDE frame correctly. I find it either too small or big.
Webstorm also doesn't use "ctr+w" to close tabs on Windows & linux while does that on OSX.
Does WebStorm still maintain their own version of TypeScript language tools? Back in the 1.0 days they did, and it was a mess. Stuff that would work in Visual Studio and with tsc at the command line wouldn't work in WebStorm.
That said, love Jetbrains. Have a Ultimate license for Java.
The default option is to use the bundled typescript compiler, but you can now also point it to a folder that contains a typescript compiler and it will call out to that. It works very well for me so far.
When was the last time you tried? They are very quick at reacting to (good) bug reports. I've filed almost a hundred by now and I decided to pay them because of my experience in their reaction to bug reports. With each new EAP (early access) and release TypeScript always has a lot of fixes, so it's obvious to me TS has a high priority to them.
You'd be fine. Webstorm will create a .idea directory in your project, which will contain all the Webstorm specific project settings and configuration. But anything else is stored in regular ol' files you could edit with anything. I use Webstorm and my other teammates use VS Code or Sublime.
The only thing that might "break" is if you rely on Webstorm's tools for things like test runners, compiling, minifying and bundling code, etc, instead of learning how to do it on your own. You'd then need to learn how to set it up yourself with the command line tools instead of a nice GUI.
I create a project. There are two things they could do:
1. Make an ant/maven/gradle repo, and have the build command run gradle build or something.
2. Create a commandline (open source) tool called "intellibuild" or something, which reads the project files and does whatever the "build" button does.
Unfortunately, they don't do either, so if I don't have a license (or I want to give my code to others who don't use IntelliJ), my J2EE is not buildable.
For neovim users, you can get something almost comparable with deoplete [1], tern_for_vim [2], and ternjs-deoplete [3]. I set this up recently and have been very happy with the results. This also supports ES6 and JSX in case you use either of those.
I've been using YCM for autocomplete so far. How does deoplete compare with YCM if you have used that in the past. I did install term_for_vim recently but haven't really configured it much.
Typescript is great and is "natively" included in Angular2, however it's not the case for react and vue.js ecosystems.
Tried to use/learn typescript, in the meantime I wonder if there is a document showing how to use certain "safe" javascript along with its strict mode to make javascript secure enough so that I don't need use Typescript? i.e. how about using a subset of native javascript with certain rules that can achieve what typescript provides, is this enough? is 'strict-mode' the answer?
If there is a book/blog stating "using javascript the way as your typescript" I will buy it right away. :)
React may not have "native" support for TypeScript, but in combination with TypeScript using React is so much more fun, if only for the fact that your props can actually be typed and checked at compile time.
The standard recommendation seems to be to use PropTypes. And also in general, to use Babel with React programs. Would be interested to hear experiences of using Typescript with React.
Using React, Redux, JSPM, TypeScript work great together in VS.NET, it compiles on save so you don't need to run any additional watchers and JSPM's bundle feature means you also don't need Babel. Since ES6 support is VS.NET is very weak, using TypeScript is the best way to use the latest ES6/TypeScript features today:
In my opinion React support is progressing quickly but is not fully there yet (definitely more documentation is needed), so for the JSX part the pain is greater than the gain (especially given PropType checking already in React).
As an example, to see what I mean, try to figure out how to write a properly typed Higher Order Component function. Last time I looked at it, this had no direct mention in documentation and only workarounds on StackOverflow.
It seems a little strange but you can import the propTypes of the wrapped component (argument to the HOC) into the wrapper and incorporate them into your type checking there.
If you think learning Typescript is too much hassle for JavaScript "safety" you gonna have a heart attack when you find out about Elm[1] (hint: pure functional programming)
