GitHub Atom
-
-
So is there anything that makes Javascript worse for desktop applications than other languages like Python?
-
Less maturity of third-party libraries. If you like playing around with stuff for fun, that might not matter. For people who want to Get Shit Done, having to develop the support libraries is a big downer.
-
So is there anything that makes Javascript worse for desktop applications than other languages like Python?
The lack-of-namespace thing is really the killer there.
Other than that, I don't see any particular reason JavaScript is unsuited for desktop applications.
-
Javascript has definitely become one of the "universal" programming languages (since everything has a web browser, and web browsers need javascript). If lack of libraries is the main reason not to write desktop apps with it, we better get used to javascript software because it will only get bigger from here.
On a completely unrelated note, calling it Atom seems like a great way to confuse people. Let's make a chat app and call it "XHTML", or a video player and call it "TLS 1.3".
-
Scaffolding should quickly create the rote boilerplate code to help you get started. But it SHOULDN'T create dangerous WTF code you need to manually remove.
Yeah, the app should stop providing that functionality as soon assails lift --prod
is called, but apparently they expect you to manually disable it in the configuration. No clue why that is, I wouldn't be surprised if there are a ton of apps with those features enabled by default floating about on the web
-
So is there anything that makes Javascript worse for desktop applications than other languages like Python?
The main difference is javascript doesn't really have threads. That means all api-s you use that do anything remotely complicated must take callback and work asynchronously outside the run loop that powers your code. That worked well for servers. But now you have two separate environments you have to synchronize (browser's GUI and node's backend).
Are they even the same js engine? The same run loop? How do they share data? A lot of dicey technical details. So far things seem to be working out, but there could still be deal-breakers ahead.
-
The lack-of-namespace thing is really the killer there.
Other than that, I don't see any particular reason JavaScript is unsuited for desktop applications.
IMO node solves that completely. The path to the file is your namespace. The require system is very powerful and easy to use. In fact, I would say it's one of the secrets behind node's success.
-
Yes but the question was about JavaScript and not Node.js.
You can definitely simulate namespace support into JavaScript environments with clever-enough scripting. Or JavaScript-like languages which compile to JavaScript, like TypeScript.
But JavaScript itself has no namespace support, and so I stand by my answer.
-
Well the theory of nosql is the developer enforces the schema
Probably invented by the sort of cunts that think MySQL is a database.
-
Probably invented by the sort of cunts that think MySQL is a database.
It is. It might not be especially good at the more complex stuff but it's fine for simpler stuff. And, you know, Oracle.
-
Yeah, that's as far as I got too. The framework runs, I just can't do anything with it.
-
So, just for shits and giggles (and to alleviate boredom during the train ride home) I wondered how hard would it be to make something basic that does the whole "v8 engine in a wrapper executing JS" thing. v8... OH! QML uses v8 for JS interpretation! And I don't have to include the whole Webkit either! So, 10ish minutes of work later (half of it being reading the docs because I haven't used QML that much yet):
import QtQuick 2.2 import QtQuick.Controls 1.1 import QtQuick.Layouts 1.1 ApplicationWindow { id: appWindow visible: true width: 640 height: 240 title: qsTr("JS editor thing") menuBar: MenuBar { Menu { title: qsTr("File") MenuItem { text: qsTr("Exit") onTriggered: Qt.quit(); } } } Rectangle { id: editorArea anchors.fill: parent RowLayout { spacing: 2 TextArea { Layout.alignment: Qt.AlignLeft Layout.preferredWidth: editorArea.width / 2 Layout.preferredHeight: editorArea.height id: editor } Rectangle { id: resultPane Layout.alignment: Qt.AlignRight Layout.preferredWidth: editorArea.width / 2 Layout.preferredHeight: editorArea.height Text { id: jsResult anchors.left: parent.left anchors.top: parent.top anchors.leftMargin: 5 anchors.topMargin: 5 } } } Button { id: execButton anchors.left: parent.left anchors.right: parent.right anchors.bottom: parent.bottom text: "Execute" onClicked: { var jsText = editor.text; var result = eval(jsText); jsResult.text = result; } } } }
There we go! And yes, I know you saw the
eval
if you read it. You are not alone:I know QtCreator, I know, but this is just a stupid experiment anyway. So, here's a screenie:
Yes, I know, no syntax highlighting, no fancy inspection in code. BUT! Can I customize my editor using JS?
YUP!
I almost want to make something out of this. Almost.
-
But if you multiply six by nine you can get FORTY TWO
In base 13 anyway
-
for the "Oh my!" button
-
I don't have a problem with it. I will be the first to bitch about JS and how it is a major PITA when debugging IE's interpreter but it is a piece of piss to work with node and you can even debug it in Chrome. But then again I kinda like JavaScript and PHP even though they are "shit" languages.
-
Onyx's Molecule code editor, coming to github soon! Star us!
-
Horrible idea or not. I actually use QT to make an embedded system's main UI on a LCD by just rendering HTML. Data was piped from another process over websockets in the QT Webkit which was already available just because it was there to manage remotely on a network via browser anyway.
-
These days, I'd do just do the UI in QML. Qt 5.3 has native websocket support now and it's trivial to get it running. And I would assume QML would give you better performance than loading webkit stuff.
Then again, these days mobile apps do the HTML thing a lot and it seems to be working for them, so I guess if it works...
-
Unforunately I'm stuck on the qt4.8 or qt5.1 packages for now. Then there's the fact that qtcreator, well...it's different.
-
Not start, but lift. Because these are sails, you see
I thought they are sails, not dumbbells.
-
The main difference is javascript doesn't really have threads.
That's not that bad for most GUI apps, provided you've got coroutines. Even without them, most GUI apps really don't need threading (which only makes things seem easier; threading bugs are bitches to hunt down).Some GUI apps don't fit that model (especially real-time games) but they're not the majority.
-
Indeed. The correct nautical term would be "Hoist"
Filed under : Javascript - the language based on doing it wrong
-
…threads.
That's not that bad for most GUI apps, provided you've got coroutines. Even without them, most GUI apps really don't need threading (which only makes things seem easier; threading bugs are bitches to hunt down).
Most GUI frameworks are not thread-safe, even. You are not even allowed to call methods on the widgets from other than the main thread in most frameworks including Gtk, Qt, MFC, WinForms…
-
Most GUI frameworks are not thread-safe, even.
And knowing what sort of things they do internally (I'm a maintainer of a GUI framework in my spare time) that's entirely unsurprising. The guts of those things are brain-boggling even when you're single-threaded.
-
Most GUI frameworks are not thread-safe, even
Indeed. If you want something truly thread-safe, you'd probably need to go to something purely functional, with no shared state or mutation. One of the FRP frameworks would probably work. This paper might be a decent read, for example.@tufty said:
Probably invented by the sort of cunts that think MySQL is a database.
It is. It might not be especially good at the more complex stuff but it's fine for simpler stuff. And, you know, Oracle.- There are still serious unrecoverable data-loss scenarios1 for current2 MySQL. The MySQL people haven't fixed all of them, although I reported mine around 5.0.x time. I wouldn't recommend MySQL for any data you actually care about.
- Even ignoring that (or assuming I'm bullshitting), the "folk myth" of "MySQL is the fastest open source database" stops being true once you start bringing in the sort of things that all databases need, like referential integrity.
- Oracle, you say?
- Ironic, isn't it, that it's easier to migrate from PostgreSQL or Ingres to Oracle than it is from MySQL, which is owned by Oracle.
1 - At least 2 that I know of, because I found them
2 - Well, current as of about 18 months ago, the last time I bothered testing.
-
Ironic, isn't it, that it's easier to migrate from PostgreSQL or Ingres to Oracle than it is from MySQL, which is owned by Oracle.
Sort of, except that's a relatively recent development.
-
Oh wow, another NodeJS-based editor.
But this one is actually curses-like, for terminals!
-
It's named after what happens to you when someone suggests your company adopt it!
Hey you know what's kind of like SublimeText and portable to every OS that matters and runs pretty fast with no JavaScript? SublimeText.
-
Hey you know what? This actually looks pretty good! I'll try it out.
-
Well you know, some day you might have to telnet back in time to edit some file on a server in the 1970s, and then what'll you do?
Filed under: The standard go-to justification for using a terminal-based text editor
-
Well you know, some day you might have to telnet back in time to edit some file on a server in the 1970s, and then what'll you do?
Well, definitely not fire up a fucking node.js runtime on it.
-
Well you know, some day you might have to telnet back in time to edit some file on a server in the 1970s, and then what'll you do?
You throw a tantrum because they don't have your favourite version of Vim or Emacs and the operators are somehow unable to download it from the Web?
Filed under: Lovers of
ed
excluded.
-
-
Ah ed! The standard editor, perfect for your teletype and even usable when you had one of those sweet new visual display terminals.
If you lived in DOS land back in the 1980s, think of using ed as being rather like using EDLIN, but marginally better because you could use regular expressions to do some operations.
-
So, my first impressions about the slap editor............... I like it. With caveats.
FINALLY a terminal editor that just acts like a 21 century editor. None of that custom keybindings shit. Just normal cut/copy/paste operations, undo/redo, text selection that WORKS with clipboard etc... Like someone took DOS's edit, and modernized it for *nix environments.
Standout feature: code highlighting auto detection. Open a extensionless script and there's a good chance you'll get bash syntax highlighted. Even sublime doesn't try that.
Of course, I would never actually code in this; that's what IDE's are for. But if you need a quick config edit or bash script hack, it's MUCH better than nano.
Downsides and caveats:
-
Currently I'm having problems with my terminal emulator blocking shift+pgup/pgdn and such keys, so selection doesn't work like it should. Trying to resolve it ATM.
-
As mentioned, uses node.js. Meaning you need to have node.js installed and there's slight performance penalty, especially during startup. Rough estimate, it takes 300-500 ms to start up compared to practically instant startup by nano. On the upside, the installation is still dead simple thanks to the excellent npm system. On most systems, all that's needed is
sudo apt-get install nodejs npm install -g slap
Not a big deal IMO.
- Caveat: I still haven't tried it on a remote server through ssh. So not sure how will it act there.
-
-
On most systems, all that's needed is
sudo apt-get install nodejs
npm install -g slap
Not a big deal IMO.Except....I get /usr/local/bin/slap which starts with:
#!/usr/bin/env node
This seems reasonable, except it should be:
#!/usr/bin/env nodejs
@blakeyrant to follow
-
apt-get install nodejs-legacy
There used to be some kind of node package, so there's a name conflict. It seems when you install the legacy thing, you get normal node binaries.
-
Yes, but still the point stands: it should be
#!/usr/bin/env nodejs
.
-
The problem is that you go from
apt-get
tonpm
. Which pulls from who knows where.
-
Did anyone notice that Github Atom is one of the people advertised as a Discourse user?
-
I think one of those guys posted on the "What IDE do you use?" thread over on meta.d.
-
They also have a forum, but the "endorsement" could be from either one.
-
On the upside, the installation is still dead simple thanks to the excellent npm system
Still, you have to install it. And you have to install a runtime. And what's 300-500 ms on your PC will probably be way more on a free EC2 instance or a $5 droplet.
Perhaps in a few years, when node becomes as ubiquitous on *nix as .NET is on Windows, it might become a viable "quick edit" choice. Wow, it'd take only what, 40 years for *nix to have a sensible terminal text editor? You know, the system that pretty much runs on terminal and text files?
As it is now, there's too much hassle.
Filed under: node.js is .net except instead of an awesome language to code in, we get JavaScript
-
As it is now, there's too much hassle.
Probably.
So far, RoxTerm shortcuts are still the biggest hassle. Stupid thing can't seem to unbind backbuffer scrolling keys that I need for selection manipulation. If I ever fix that, I think I'll install slap to a few often used servers, just so I don't have to suffer the indignity of using crappy nano anymore.
-
Filed under: node.js is .net except instead of an awesome language to code in, we get JavaScript
Crappy language, but better parallelism methodology IMO.
-
Wow, it'd take only what, 40 years for *nix to have a sensible terminal text editor?
But vi is a sensible terminal text editor. You just need to have a sensible terminal.
-
Getting back to the original topic.
I just gave Atom another shot. Actually went the distance with updating libc so I can install it on Debian.
Sigh...
Such a shame. Looks really nice. I can see how the idea with fully customizable appearance is enticing. All the sublime features are there, and more. Some nice plugins too.
But what's the point of it all when it's just so SLOW. It takes 5-10 seconds to load, like you're starting visual studio. You drag the selection and you can see it struggling to follow along. You hold PgDn and can tell the screen is lagging behind. Everything you do is perceptibly slower and thus crappier than the competition.
The worst thing is, I don't think there's anything github guys can do at this point. With Discourse, Jeff & Co can at least hold hope that their HTMLBars Messiah will descend from heavens and save their asses on mobile. Nothing is coming along to save atom. Such shame.
-
Is anyone else seeing entity fail or is something wrong with my browser? Chrome 36.0.1985.143 m
Since trying to paste the image crashed my browser, I'm going to guess it's me
-
They're failing for me, too.
I'm using the same version of Dischrome right now and it also fails on Discofox.