5 ms·

>Instead I can make a terminal that's significantly more efficient and responsive ...and that runs on exactly one OS, and doesn't support the 250k+ Node module

>Instead I can make a terminal that's significantly more efficient and responsive ...and that runs on exactly one OS, and doesn't support the 250k+ Node modules, and that doesn't support standardized plugins, and that can't open web pages locally... JavaScript hate is so 2010.

tatterdemalion 10y ago
I don't have any skin in this but I don't understand what it means for a terminal to "support the 250k+ Node modules," or any of the features you listed, honestly
- SomeCallMeTim 10y ago
  The modules are there so you can add features and you have the entire Node toolbox at your disposal.
jackmott 10y ago
I don't know what imaginary language you are imagining that only runs on 1 os and doesn't have libraries in it's ecosystem.
dleslie 10y ago
Ooh, 250,000+ modules with an average of less than one active user, little to no documentation or tests, and which may or may not be trivial one-liners. Above all, any given module has at least one other module that provides that same functionality. Meanwhile, plenty of other languages run on many operating systems, have standardized library behaviour, and can trivially ask the operating system to open a file:// uri.
- tracker1 10y ago
  https://www.npmjs.com/package/open https://www.npmjs.com/package/open
  - lhnz 10y ago
    https://www.npmjs.com/package/opn https://www.npmjs.com/package/opn
    - SomeCallMeTim 10y ago
      52,477 downloads in the last day 335,554 downloads in the last week 1,448,740 downloads in the last month Not bad.
- SomeCallMeTim 10y ago
  >Above all, any given module has at least one other module that provides that same functionality. In practice this means that you can often find a module that does exactly what you want. I find that most modules have great test coverage, and I've found it easy to contribute to several high profile projects in the Node ecosystem. The concept of trying to contribute to, say, Boost, makes me cringe. I would just assume that anything I suggested would be killed or mangled in committee discussion, and this despite the fact that I have a friend on the committee. [1] 95% of the modules I'm using are either relatively high profile build tools or they have TypeScript definitions in DefinitelyTyped, which has a much more modest ~1800 modules. Still I've occasionally needed obscure functionality and have been able to find appropriate libraries for it. [1] Actually, don't know if he still is, but when I was in closer touch with him it seemed like an unapproachable task.
  - dleslie 10y ago
    It reads like Javascript development is largely a process of cementing together small rocks; in contrast to development elsewhere, which is largely a process of mortaring together large bricks and/or building new framework. At some point you reach a maximum load and the structure becomes too brittle; the materials and process chosen dictate what that maximum load is. Corollary, they dictate how difficult it is to quickly throw together a simple walk path.
wrl 10y ago
Hey, I have a few issues with your attitude. Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. The hard part isn't drawing characters to the screen (which is what HTML and CSS would help with), it's the VT100 parsing and logic, which can be written in...well, anything, really. I would first like to point out that the HyperTerm OSX zip is 43mb, and the unzipped HyperTerm.app is 123mb. Supporting exactly one OS: again, the OS specific bits aren't the hard part. Blitting characters to the screen is easy, and platform independence certainly isn't worth 123mb of overhead. 250k+ Node modules: The number of packages in a package repository is a poor metric for determining anything except the number of packages in the package repository. npm has tons of redundant or ill-maintained packages, and that's even before we discuss whether having a bunch of available packages makes a terminal better at all. In my opinion, it doesn't, and this circles back around to the fact that a terminal needs to be secure. I sure as hell don't want random unaudited code running in the same application that I use to administer systems. Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here. Can't open web pages locally: Why should a terminal do that? As a party trick? I don't want to stand in the way of improvement, here, but I also have no problem opening a separate web browser to browse the web. Javascript hate: It's not hate when people bring up salient points. Just because the web platform is open and everybody is using it right now doesn't mean that it's perfect or above criticism.
- zingermc 10y ago
  I tend to agree with all of your points. How do you feel about the 'eshell' mode in emacs? I think it's neat because it's basically a normal shell plus an elisp REPL. I imagine a terminal emulator with access to a large library of functions (such as a trusted subset of npm modules) could be useful.
- deleted 10y ago
  [deleted]
- SomeCallMeTim 10y ago
  >Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. So you prefer one written in ... C? Because C is secure by design? <rim shot> Coding a terminal in Rust or even Go would be awesome, I admit... >Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here. See the demo animation for a (silly yet awesome) example. >250k+ Node modules Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well. >It's not hate when people bring up salient points. >>>without having to write any JavaScript, which is its own achievement. The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. What salient points do you actually refer to? I'm not really disagreeing with you about the terminal: Honestly I will keep my lighter terminal with tabs and good UI for most real uses. But I love to see people innovating; providing extendable architecture is the way we get great new features. Maybe there's no killer feature in this one to justify the extra weight, but neither do I see the need to pile hate on it because JavaScript; even less because they had a bad experience in school writing a JavaScript project that was similar.

tatterdemalion 10y ago

I don't have any skin in this but I don't understand what it means for a terminal to "support the 250k+ Node modules," or any of the features you listed, honestly

SomeCallMeTim 10y ago
The modules are there so you can add features and you have the entire Node toolbox at your disposal.

jackmott 10y ago

I don't know what imaginary language you are imagining that only runs on 1 os and doesn't have libraries in it's ecosystem.

dleslie 10y ago

Ooh, 250,000+ modules with an average of less than one active user, little to no documentation or tests, and which may or may not be trivial one-liners. Above all, any given module has at least one other module that provides that same functionality. Meanwhile, plenty of other languages run on many operating systems, have standardized library behaviour, and can trivially ask the operating system to open a file:// uri.

tracker1 10y ago
https://www.npmjs.com/package/open https://www.npmjs.com/package/open
- lhnz 10y ago
  https://www.npmjs.com/package/opn https://www.npmjs.com/package/opn
  - SomeCallMeTim 10y ago
    52,477 downloads in the last day 335,554 downloads in the last week 1,448,740 downloads in the last month Not bad.
SomeCallMeTim 10y ago
>Above all, any given module has at least one other module that provides that same functionality. In practice this means that you can often find a module that does exactly what you want. I find that most modules have great test coverage, and I've found it easy to contribute to several high profile projects in the Node ecosystem. The concept of trying to contribute to, say, Boost, makes me cringe. I would just assume that anything I suggested would be killed or mangled in committee discussion, and this despite the fact that I have a friend on the committee. [1] 95% of the modules I'm using are either relatively high profile build tools or they have TypeScript definitions in DefinitelyTyped, which has a much more modest ~1800 modules. Still I've occasionally needed obscure functionality and have been able to find appropriate libraries for it. [1] Actually, don't know if he still is, but when I was in closer touch with him it seemed like an unapproachable task.
- dleslie 10y ago
  It reads like Javascript development is largely a process of cementing together small rocks; in contrast to development elsewhere, which is largely a process of mortaring together large bricks and/or building new framework. At some point you reach a maximum load and the structure becomes too brittle; the materials and process chosen dictate what that maximum load is. Corollary, they dictate how difficult it is to quickly throw together a simple walk path.

wrl 10y ago

Hey, I have a few issues with your attitude. Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. The hard part isn't drawing characters to the screen (which is what HTML and CSS would help with), it's the VT100 parsing and logic, which can be written in...well, anything, really. I would first like to point out that the HyperTerm OSX zip is 43mb, and the unzipped HyperTerm.app is 123mb. Supporting exactly one OS: again, the OS specific bits aren't the hard part. Blitting characters to the screen is easy, and platform independence certainly isn't worth 123mb of overhead. 250k+ Node modules: The number of packages in a package repository is a poor metric for determining anything except the number of packages in the package repository. npm has tons of redundant or ill-maintained packages, and that's even before we discuss whether having a bunch of available packages makes a terminal better at all. In my opinion, it doesn't, and this circles back around to the fact that a terminal needs to be secure. I sure as hell don't want random unaudited code running in the same application that I use to administer systems. Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here. Can't open web pages locally: Why should a terminal do that? As a party trick? I don't want to stand in the way of improvement, here, but I also have no problem opening a separate web browser to browse the web. Javascript hate: It's not hate when people bring up salient points. Just because the web platform is open and everybody is using it right now doesn't mean that it's perfect or above criticism.

zingermc 10y ago
I tend to agree with all of your points. How do you feel about the 'eshell' mode in emacs? I think it's neat because it's basically a normal shell plus an elisp REPL. I imagine a terminal emulator with access to a large library of functions (such as a trusted subset of npm modules) could be useful.
deleted 10y ago
[deleted]
SomeCallMeTim 10y ago
>Firstly, if there is one piece of software that I want to be fast, lightweight, and most importantly secure, it's my terminal emulator. So you prefer one written in ... C? Because C is secure by design? <rim shot> Coding a terminal in Rust or even Go would be awesome, I admit... >Standardised plugins: what standardised plugins? npm modules? Not sure what you mean here. See the demo animation for a (silly yet awesome) example. >250k+ Node modules Point is to use them to do other cool things client-side. It's a Really Big Toolbox. The CSS/HTML part can potentially provide interesting options as well. >It's not hate when people bring up salient points. >>>without having to write any JavaScript, which is its own achievement. The latter quote is from the comment I was replying to. It is not a "salient point," but simple JavaScript hate. His other points were that, in the past, he had written a JavaScript terminal as a school project that he ended up hating, it took him thousands of lines of code, and he'd done it before Node existed to provide the batteries. What salient points do you actually refer to? I'm not really disagreeing with you about the terminal: Honestly I will keep my lighter terminal with tabs and good UI for most real uses. But I love to see people innovating; providing extendable architecture is the way we get great new features. Maybe there's no killer feature in this one to justify the extra weight, but neither do I see the need to pile hate on it because JavaScript; even less because they had a bad experience in school writing a JavaScript project that was similar.