5 ms·
In one of our projects the largest JS file is 12k lines. In eclipse I can work with it no problems. In WebStorm/other JetBrains IDE it runs like a dog with that
by davidjgraph 13y ago
In one of our projects the largest JS file is 12k lines. In eclipse I can work with it no problems. In WebStorm/other JetBrains IDE it runs like a dog with that file open, I ran away screaming after 15 seconds.
Inability to be able to effective edit my files is a major problem, though I'm interested if anyone knows how to speed WebStorm up for JS files. If that were resolved I'd be very happy to switch to flee Eclipse's git functionality.
Before someone says it "reduce the size of the file" is not an answer. In answer to split the file and re-make it in a build step, why on Earth should I have to get around a shortcoming in a tool? Tools are there to make me more productive, not dance when the music starts.
- geetee 13y agoGotta ask. Why do you have a 12K line JS file?
- davidjgraph 13y agoBecause it's a relatively large JavaScript library. Total line count is in the several hundreds of thousands. The file in question is for this class http://jgraph.github.io/mxgraph/docs/js-api/files/view/mxGraph-js.html http://jgraph.github.io/mxgraph/docs/js-api/files/view/mxGra.... 1) It's the main public API to the the library, there's no logical way to split it. 2) We'd have a couple of thousand, very-annoyed-cos-they-paid-quite-a-lot-for-it customers, frankly, go apeshit if we split the file and broke their app on the next update because we wanted to switch IDE...
- Touche 13y agoThis is a third party library or your own? Why can't you break it into multiple files and concat them with a build step?
- philliphaydon 13y agoHe could if he wanted to, but he doesn't want to have a maintainable library.
- nickdoesdesign 13y agoEven if it isnt a part of the normal build, a separate one that does that would help immensely. AMD makes this ridiculously easy, and grunt etc will help him even further.
- jmduke 13y agoTo clarify, you feel that using Eclipse is more work than breaking a file into multiple shards and setting up a build process to recombine them? (I'm not trying to be snarky and I apologize if the above comes off that way.)
- WalterSear 13y agoContemporary javascript development without a build step?
- Touche 13y agoWell yeah, if you have to use one specific editor because the file is larger than most can handle that should be a signal that the file is the problem. I for one think that developing a project in multiple files that can all be understood on their own is the only sane way to develop at all, regardless of editor choice.
- hawleyal 13y agoYou need modules
- deleted 13y ago[deleted]
- Joeri 13y agoIt's slow because of the code quality inspections. You can override these per file by clicking the Sherlock Holmes icon in the statusbar.
- sesm 13y agoHis name is Hector the Inspector.
- mcormier 13y agoIt's also slow the first time you use it because it pre-indexes a lot of things. Once it is finished indexing it is generally quite snappy.
- teawrecks 13y agoI was working with a 50k line JS file the other day (compiled ember project) and opened it in Sublime. The difference in time between opening a 50k line file and a 5 line file is a little less than half a second. Otherwise, performance is identical.
- pan69 13y agoBut Sublime is not an IDE, it's a text editor.
- shousper 13y agoThis is probably abundantly clear, but someone has to say it. You need to refactor that beast and split it out into separate files for development. Add a build process to smash it all together for you. End of story.