3 ms·
> Without looking at the behind the scenes memory allocation/speed — the real world speed of the application surpassed my expectations Agreed, I too was positi
by rjzzleep 13y ago
> Without looking at the behind the scenes memory allocation/speed — the real world speed of the application surpassed my expectations
Agreed, I too was positively surprised about it's speed.
>Anyway, this is a good write up and good look at the negatives of a web based editor, but I would argue the drawbacks of the DOM outlined are outweighed by the ability talk to it (and also the entire API) via the webkit inspector.
Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you?
I can't really think of a good reason why this would be true. It would seem to me that an elaborate API for manipulating, and annotating the text store while being more complicated to design would be much better to create high quality plugins. This solution opens the door to lots of hard to debug memory leaks, and conflicts that can easily destroy the text your editing.
You could argue that bad plugin developers don't warrant closing off the api, and i would be with you. I'm just not sure what exactly you need the DOM for.
EDIT: actually I can. when dealing with web technologies, i have to admit it would be sometimes cool when you can instant preview code in the editor. this is possible with both brackets and atom. but atom has been much smarter about marketing a finished product. so this can turn into a sort of wysiwyg for the web
- kingnight 13y ago> Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you? No, I am not. Ha! I guess I am exposing my own ignorance of _the right way_ to do things like this along with what my comfort zone is. If I want to going to write a package to insert the current date at the cursor point, for example, I am likely going to just open up the webkit console and write code in their until it works (I did this) — instead of going to atom.io and finding their API documentation. One cop out too I was thinking about is that one could easily write a plugin to 'edit in' and assign a keyboard shortcut to handle the big files in their robust editor de jour.