Hacker News Reader

Comment by venomsnake | Hacker News Reader

Also known as the paste minified javascript in Jetbrains ide effect.

IntelliJ forks handle pasting large volumes of text much better than vim or sublime text in my opinion. IntelliJ will be able to maintain performant syntax highlighting because it builds an ast and does not use regular expressions.

I'm a hue PyCharm fan, but if this is true then vim and Sublime must be barely usable. Python, it's great at...but open a big JS file and it...will...take...forever...to do the JS syntax highlighting, if it ever finishes. CoffeeScript is even worse, and almost always crashes.

It's always a little weird, because I have no performance issues anywhere else in it, and it's got ~7GB of RAM it could use.

I use PyCharm every day and IntelliJ and I have never had this problem. Maybe it's a resource issue with your hardware though and your version of Java. I use the new versions that bundle OpenJDK on a newer Macbook Pro.

The problem is not volume but extremely long lines. Minified js is one veeery long line. I think that they have some O(n^2) in their line algorithm. You can paste 60-70 thousand lines and it will highlight instantly. The same code minified will hang the IDE.

On a side note, you should preserve some new lines in your minified js as it makes dealing with production JavaScript errors much easier, assuming you have some kind of onerror hook that sends you js errors. The new lines don't add much to the overall size of your js but they make debugging much easier.

Tell that to the people that pack jQuery ...

You should use source maps

Thats what I do, too. It makes debugging so much easier, and you can safe yourself the pain of source maps. A few bytes I gladly spend on keeping my sanity.

I've always wondered why minifiers don't take advantage of ASI to this effect. Your files come out the exact same size as cramming it onto a line with semicolons...

We have been meaning to get around to looking into this on my current project but haven't yet: I believe the browser's error event will return a column number.

> Column numbers in Firefox. Firefox is the only browser that doesn't support column numbers for exceptions. This makes debugging minified javascript essentially impossible. I've sent one patch but there's a lot more to do.

https://bugsnag.com/blog/js-stacktraces/

- written in 2014

but MDN now says:

> Column number for the line where the error occurred (number) - Requires Gecko 31.0

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEvent...

If anybody has live experience with this, I'm eager to hear about it.

Yes you get column numbers and that really helps as well, but as mentioned new lines don't really hurt that much and I'd rather have some new lines than none. In response to others about using source maps, I'm talking about production errors received from users in the wild who may or may not have source maps enabled in their browser.

I've never thought about it that way. This makes web dev in Eclipse suddenly make so much more sense.

It's amazing how true this is, huge files work fine, but one long line... I wish I knew more about editors to help fix it.

Yeah, I actually looked at atom sometime back. They have a problem with long lines because their regex engine runs in O(n^2). I suggested that they switch to a regex engine that runs in O(n). https://github.com/atom/atom/issues/979#issuecomment-7770371...

I don't know what happened after that. Maybe they will act on this. The only problem with the O(n) engine was that a lot of TextMate grammars for languages wouldn't work with atom but that was easily resolvable by writing them anew.

Reply on news.ycombinator.com