8 ms·

It’s possible that native graphical editors will increase in popularity at some point. There’s probably a niche of people who don’t like the potentially poor pe

by snazz 7y ago

It’s possible that native graphical editors will increase in popularity at some point. There’s probably a niche of people who don’t like the potentially poor performance of Electron-based editors but don’t want to learn (or find that they dislike) terminal-based editors like Vim and Emacs. Who knows? Google Trends isn’t an accurate way to tell the popularity of programming languages either.

TylerE 7y ago
Sublime Text, is native, isn't? Sure, much of the API and all the plugin stuff is in Python, but the core is all native C++ AFAIK.
- snazz 7y ago
  It’s also declining according to the chart, but you’re right that it’s both native and way more popular than TextMate.
  - cies 7y ago
    I found that ggl trends graphs for tech topics usually decline over time and I attribute it to more non-technical crowd becoming netizens and thus technical topics will usually seem declining.
- statictype 7y ago
  Its native but cross platform so many Mac purists don’t consider it as “native” as TextMate, which is built specifically for the Mac and doesn't compromise on standard Mac UI idioms. Having said that, if they had known all the modern alternatives were going to be even less “native” amd run in a browser engine, they'd probably have been less nitpicky.
  - arghwhat 7y ago
    Eh, as a macOS user until recently, I found Sublime Text to be a very integrated application. Appearance and behavior was exactly as I'd expect from modern macOS applications. It may not be heavy on archaic Mac features such as AppleScript integration, but I hope we can all agree to ignore those technologies. TextMate just brings memories of the 10.4 Tiger days.
    - statictype 7y ago
      Right. I’m referring to 5 to 7 years ago when Sublime 2 was still young. I personally liked ST2 but I know that some people held their nose.
    - chipotle_coyote 7y ago
      TextMate never had AppleScript integration, AFAIK. Also, I'm not convinced we should ignore those "archaic" technologies, at least in the abstract. Applications can provide "dictionaries" of commands that, when implemented well, provide GUI applications with the kind of "snap together for amazing effect" you get with shell scripts and a host of well-written CLI tools. You arguably can't script the AppleScript-intensive BBEdit to the same level that you could, say, Emacs or Vim, but imagine the possibilities of a suite of apps from different makers that all had complete scripting dictionaries that could all be woven together with a deep system-wide scripting language. I actually think it's a shame that AppleScript has been kicked to the curb. I don't think we have a "modern" replacement yet -- certainly not in the Apple ecosystem, and I'm not sure anywhere else. (Shortcuts on iOS is trying, but it's not on the Mac yet, and it gets pretty clunky if you start doing overly complicated automation bits with it.)
      - shp0ngle 7y ago
        AppleScript is a great idea in how everything is scriptable. Unfortunately, the language itself is a horrible abomination from the wild 1990s days of Mac OS... sorry, now macOS... and writing absolutely anything in it is painful. I feel like Apple introduced Automator to overcome the pain of AppleScript, but it never really caught on (I don't even know if Automator is still on macOS.... yep it is, still with the cute Aquaesque icon) Nowadays everything is Electron anyway and those are not that well AppleScript-able, but what to do, that's life
        Gaelan 7y ago
        "AppleScript" can do JS now, but it's so clunky and badly documented that it's barely worth it.
  - setpatchaddress 7y ago
    TextMate is native and modern.
- setpatchaddress 7y ago
  Depends on what you mean by "native". The core is compiled to a native binary. But it doesn't use macOS native text editing or UI idioms beyond the level of windows and menus. If you don't want to use TextMate, you might as well use Visual Studio Code instead, which is closer in spirit to the native Mac idioms and is easier to configure.
  - dictum 7y ago
    I'm not well versed on the specific implementation details of ST, but whatever the ST team does on macOS yields a result that is much closer to a native application than VSCode does through embedded Chromium. The difference in text rendering is particularly noticeable on a non-hidpi display.
- stunt 7y ago
  Sublime Text is C++ expect for the plugins part. And they have put years to optimize it. It beats everything when it comes to performance, memory, and power consumption. The only fight it can't win over VSCode is the extensions and ecosystem.
armitron 7y ago
Emacs is not by any stretch terminal-based. It can work in a terminal, but it also fully supports graphical environments. In fact, I dare say that most Emacs users use the graphical rather than the terminal version. Example: https://www.youtube.com/watch?v=FWQB_9QcGI0 https://www.youtube.com/watch?v=FWQB_9QcGI0
- snazz 7y ago
  I would consider myself an Emacs user and I use the graphical version too. With the exception of the menu bar and toolbar, Emacs seems to be graphical but not a graphical user interface, if that makes sense. It is still primarily a text-based application controlled through the keyboard. There’s certainly nothing wrong with that approach, but my litmus test is if you lose a significant amount of functionality by using the terminal version instead of the graphical version, it’s graphical. I don’t really lose anything (and I don’t think most people do) when running emacs -nw.
  - armitron 7y ago
    Actually you lose quite a lot, which is of course everything that requires a graphical environment. Examples include smooth pixel-based scrolling (see my other reply below), extensive image support everywhere (e.g. EWW/elfeed/GNUS/Org) which includes animations, PDF viewing (native on macOS), true color / SRGB, SVG rendering, better font support including emojis on macOS and multiple frames. Maybe you don't care about any of these but don't tell me you don't really lose anything.
- s17n 7y ago
  No smooth scrolling is a deal breaker for a lot of people I'm guessing
  - armitron 7y ago
    It does have smooth scrolling. On macOS (Emacs mac port), it's the same inertia-based scrolling that every other system app is using and on Linux pixel-based smooth scrolling was added for Emacs 26.
ViViDboarder 7y ago
Yea, I try VSCode every so often, but I keep coming back to Vim in my terminal for the majority of my editing, but I actually have been using TextMate 2 (before release) as my GUI editor of choice. It’s simple, fast, and gets the job done. If I wasn’t writing so much Python, I’d say I have a type.
jimmcslim 7y ago
> It’s possible that native graphical editors will increase in popularity at some point Panic seems prepared to take that bet, with their development of Nova [1], a replacement for Coda. [1] https://www.panic.com/nova/ https://www.panic.com/nova/
- selectodude 7y ago
  It better be way, way better than Sublime Text is the plan is to charge Panic prices. Their apps are best of breed but this is a crowded space and they’re competing with free.
  - Gaelan 7y ago
    I mean, Sublime costs Panic prices. It just doesn't care that much if you abuse its trial. (Wait, maybe I'm misreading your comment. Are you trying to say "Sublime is free, so Nova will have to be way better to compete with Sublime" or "Sublime wasn't good enough to justify its price, so Nova will have to be way better than that to justify its price"?)
    - JohnBooty 7y ago
      Not the parent poster, but I'd agree that Nova would have to be pretty close to revolutionary to even get me to consider it. People invest a lot of time into their existing text editors. For many people (myself included) a potential replacement would have to be more than a little better, because otherwise it's not worth the somewhat large cost (in terms of time spent on setup+mastery) of switching.
  - coldtea 7y ago
    Panic also has a tendency to create something, and then neglect it for ages, which includes their previous editor... They just have too many products than what they can focus on...
- Wowfunhappy 7y ago
  They seem to be doing okay with Coda already?
jordwalke 7y ago
You might like to follow OniVim2: https://onivim.io https://onivim.io It is native, cross platform, and not based on Electron. It also uses Vim as the core editing engine.
- grok2 7y ago
  If not Electron, is it native or does it use some other web engine?
  - nxrabl 7y ago
    It uses the authors' own Revery [0] framework, based on ReasonML and GLFW. So there's Javascript in the stack, but no Chromium. [0] https://github.com/revery-ui/revery https://github.com/revery-ui/revery
    - jordwalke 7y ago
      ReasonML does not imply JavaScript - it can compile natively using the OCaml native compilers - and that's exactly what Revery does. GLFW is also native/C.
- pcr910303 7y ago
  > It is native It isn’t native in this context; As a sibling comment mentioned, OniVim2 uses revery[0], which uses it’s own widgets (not native ones) like flutter[1]. Quoting from my old comment[2]: > We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. > Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. [0] https://github.com/revery-ui/revery https://github.com/revery-ui/revery [1] https://github.com/revery-ui/revery/blob/master/README.md#design-decisions https://github.com/revery-ui/revery/blob/master/README.md#de... [2] https://news.ycombinator.com/item?id=20612195 https://news.ycombinator.com/item?id=20612195
  - jordwalke 7y ago
rosybox 7y ago
> There’s probably a niche of people who don’t like the potentially poor performance of Electron-based editors Haven't noticed any performance problems with VS Code, since I started using it everyday maybe 3 years ago. I switched from Intellij based editors to VS Code and before that I used vim for a decade.
- jmnicolas 7y ago
  600 MB memory usage with just one small text file open IS a performance problem imo (but I agree the app doesn't feel slow). Especially on MACs were RAM is priced at a premium. On Windows I developed a small program that sums the ram usage of my browsers and Electron apps I use. Between Firefox, Chromium and VSCode it's frequently around 4 GB of ram ! That's insane just to basically browse text.
coldtea 7y ago
A niche? Tons of people use non-Electron/web based graphical editors. Visual Studio, Sublime Text, TextMate, BBEdit, SlickEdit, Notepad++, XCode, Vim, Emacs, heck, one could add IntelliJ into the mix...

by snazz 7y ago

TylerE 7y ago

Sublime Text, is native, isn't? Sure, much of the API and all the plugin stuff is in Python, but the core is all native C++ AFAIK.

snazz 7y ago
It’s also declining according to the chart, but you’re right that it’s both native and way more popular than TextMate.
- cies 7y ago
  I found that ggl trends graphs for tech topics usually decline over time and I attribute it to more non-technical crowd becoming netizens and thus technical topics will usually seem declining.
statictype 7y ago
Its native but cross platform so many Mac purists don’t consider it as “native” as TextMate, which is built specifically for the Mac and doesn't compromise on standard Mac UI idioms. Having said that, if they had known all the modern alternatives were going to be even less “native” amd run in a browser engine, they'd probably have been less nitpicky.
- arghwhat 7y ago
  Eh, as a macOS user until recently, I found Sublime Text to be a very integrated application. Appearance and behavior was exactly as I'd expect from modern macOS applications. It may not be heavy on archaic Mac features such as AppleScript integration, but I hope we can all agree to ignore those technologies. TextMate just brings memories of the 10.4 Tiger days.
  - statictype 7y ago
    Right. I’m referring to 5 to 7 years ago when Sublime 2 was still young. I personally liked ST2 but I know that some people held their nose.
  - chipotle_coyote 7y ago
    TextMate never had AppleScript integration, AFAIK. Also, I'm not convinced we should ignore those "archaic" technologies, at least in the abstract. Applications can provide "dictionaries" of commands that, when implemented well, provide GUI applications with the kind of "snap together for amazing effect" you get with shell scripts and a host of well-written CLI tools. You arguably can't script the AppleScript-intensive BBEdit to the same level that you could, say, Emacs or Vim, but imagine the possibilities of a suite of apps from different makers that all had complete scripting dictionaries that could all be woven together with a deep system-wide scripting language. I actually think it's a shame that AppleScript has been kicked to the curb. I don't think we have a "modern" replacement yet -- certainly not in the Apple ecosystem, and I'm not sure anywhere else. (Shortcuts on iOS is trying, but it's not on the Mac yet, and it gets pretty clunky if you start doing overly complicated automation bits with it.)
    - shp0ngle 7y ago
      AppleScript is a great idea in how everything is scriptable. Unfortunately, the language itself is a horrible abomination from the wild 1990s days of Mac OS... sorry, now macOS... and writing absolutely anything in it is painful. I feel like Apple introduced Automator to overcome the pain of AppleScript, but it never really caught on (I don't even know if Automator is still on macOS.... yep it is, still with the cute Aquaesque icon) Nowadays everything is Electron anyway and those are not that well AppleScript-able, but what to do, that's life
      - Gaelan 7y ago
        "AppleScript" can do JS now, but it's so clunky and badly documented that it's barely worth it.
- setpatchaddress 7y ago
  TextMate is native and modern.
setpatchaddress 7y ago
Depends on what you mean by "native". The core is compiled to a native binary. But it doesn't use macOS native text editing or UI idioms beyond the level of windows and menus. If you don't want to use TextMate, you might as well use Visual Studio Code instead, which is closer in spirit to the native Mac idioms and is easier to configure.
- dictum 7y ago
  I'm not well versed on the specific implementation details of ST, but whatever the ST team does on macOS yields a result that is much closer to a native application than VSCode does through embedded Chromium. The difference in text rendering is particularly noticeable on a non-hidpi display.
stunt 7y ago
Sublime Text is C++ expect for the plugins part. And they have put years to optimize it. It beats everything when it comes to performance, memory, and power consumption. The only fight it can't win over VSCode is the extensions and ecosystem.

armitron 7y ago

Emacs is not by any stretch terminal-based. It can work in a terminal, but it also fully supports graphical environments. In fact, I dare say that most Emacs users use the graphical rather than the terminal version. Example: https://www.youtube.com/watch?v=FWQB_9QcGI0 https://www.youtube.com/watch?v=FWQB_9QcGI0

snazz 7y ago
I would consider myself an Emacs user and I use the graphical version too. With the exception of the menu bar and toolbar, Emacs seems to be graphical but not a graphical user interface, if that makes sense. It is still primarily a text-based application controlled through the keyboard. There’s certainly nothing wrong with that approach, but my litmus test is if you lose a significant amount of functionality by using the terminal version instead of the graphical version, it’s graphical. I don’t really lose anything (and I don’t think most people do) when running emacs -nw.
- armitron 7y ago
  Actually you lose quite a lot, which is of course everything that requires a graphical environment. Examples include smooth pixel-based scrolling (see my other reply below), extensive image support everywhere (e.g. EWW/elfeed/GNUS/Org) which includes animations, PDF viewing (native on macOS), true color / SRGB, SVG rendering, better font support including emojis on macOS and multiple frames. Maybe you don't care about any of these but don't tell me you don't really lose anything.
s17n 7y ago
No smooth scrolling is a deal breaker for a lot of people I'm guessing
- armitron 7y ago
  It does have smooth scrolling. On macOS (Emacs mac port), it's the same inertia-based scrolling that every other system app is using and on Linux pixel-based smooth scrolling was added for Emacs 26.

ViViDboarder 7y ago

Yea, I try VSCode every so often, but I keep coming back to Vim in my terminal for the majority of my editing, but I actually have been using TextMate 2 (before release) as my GUI editor of choice. It’s simple, fast, and gets the job done. If I wasn’t writing so much Python, I’d say I have a type.

jimmcslim 7y ago

> It’s possible that native graphical editors will increase in popularity at some point Panic seems prepared to take that bet, with their development of Nova [1], a replacement for Coda. [1] https://www.panic.com/nova/ https://www.panic.com/nova/

selectodude 7y ago
It better be way, way better than Sublime Text is the plan is to charge Panic prices. Their apps are best of breed but this is a crowded space and they’re competing with free.
- Gaelan 7y ago
  I mean, Sublime costs Panic prices. It just doesn't care that much if you abuse its trial. (Wait, maybe I'm misreading your comment. Are you trying to say "Sublime is free, so Nova will have to be way better to compete with Sublime" or "Sublime wasn't good enough to justify its price, so Nova will have to be way better than that to justify its price"?)
  - JohnBooty 7y ago
    Not the parent poster, but I'd agree that Nova would have to be pretty close to revolutionary to even get me to consider it. People invest a lot of time into their existing text editors. For many people (myself included) a potential replacement would have to be more than a little better, because otherwise it's not worth the somewhat large cost (in terms of time spent on setup+mastery) of switching.
- coldtea 7y ago
  Panic also has a tendency to create something, and then neglect it for ages, which includes their previous editor... They just have too many products than what they can focus on...
Wowfunhappy 7y ago
They seem to be doing okay with Coda already?

jordwalke 7y ago

You might like to follow OniVim2: https://onivim.io https://onivim.io It is native, cross platform, and not based on Electron. It also uses Vim as the core editing engine.

grok2 7y ago
If not Electron, is it native or does it use some other web engine?
- nxrabl 7y ago
  It uses the authors' own Revery [0] framework, based on ReasonML and GLFW. So there's Javascript in the stack, but no Chromium. [0] https://github.com/revery-ui/revery https://github.com/revery-ui/revery
  - jordwalke 7y ago
    ReasonML does not imply JavaScript - it can compile natively using the OCaml native compilers - and that's exactly what Revery does. GLFW is also native/C.
pcr910303 7y ago
> It is native It isn’t native in this context; As a sibling comment mentioned, OniVim2 uses revery[0], which uses it’s own widgets (not native ones) like flutter[1]. Quoting from my old comment[2]: > We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. > Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. [0] https://github.com/revery-ui/revery https://github.com/revery-ui/revery [1] https://github.com/revery-ui/revery/blob/master/README.md#design-decisions https://github.com/revery-ui/revery/blob/master/README.md#de... [2] https://news.ycombinator.com/item?id=20612195 https://news.ycombinator.com/item?id=20612195
- jordwalke 7y ago

rosybox 7y ago

> There’s probably a niche of people who don’t like the potentially poor performance of Electron-based editors Haven't noticed any performance problems with VS Code, since I started using it everyday maybe 3 years ago. I switched from Intellij based editors to VS Code and before that I used vim for a decade.

jmnicolas 7y ago
600 MB memory usage with just one small text file open IS a performance problem imo (but I agree the app doesn't feel slow). Especially on MACs were RAM is priced at a premium. On Windows I developed a small program that sums the ram usage of my browsers and Electron apps I use. Between Firefox, Chromium and VSCode it's frequently around 4 GB of ram ! That's insane just to basically browse text.

coldtea 7y ago

A niche? Tons of people use non-Electron/web based graphical editors. Visual Studio, Sublime Text, TextMate, BBEdit, SlickEdit, Notepad++, XCode, Vim, Emacs, heck, one could add IntelliJ into the mix...