GitHub Atom

blakeyrat

JSONP is used for fetching data.

That's not a hard-and-fast law.

anonymous234

So is there anything that makes Javascript worse for desktop applications than other languages like Python?

dkf

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.

blakeyrat

@anonymous234 said:

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.

anonymous234

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".

razerwolf

@cartman82 said:

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 as sails 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

cartman82

@anonymous234 said:

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.

cartman82

@blakeyrat said:

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.

blakeyrat

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.

tufty

@delfinom said:

Well the theory of nosql is the developer enforces the schema

Probably invented by the sort of cunts that think MySQL is a database.

Arantor

@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.

aapis

Yeah, that's as far as I got too. The framework runs, I just can't do anything with it.

Onyx

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.

Arantor

But if you multiply six by nine you can get FORTY TWO
_{^{_{In base 13 anyway}}}

aliceif

for the "Oh my!" button

lucas

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.

cartman82

Onyx's Molecule code editor, coming to github soon! Star us!

delfinom

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.

Onyx

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...

delfinom

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.

Bulb

@cartman82 said:

Not start, but lift. Because these are sails, you see

I thought they are sails, not dumbbells.

dkf

@cartman82 said:

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.

tufty

Indeed. The correct nautical term would be "Hoist"

Filed under : Javascript - the language based on doing it wrong

Bulb

@dkf said:

…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…

dkf

@Bulb said:

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.

tufty

@Bulb said:

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.

@Arantor said:

@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 scenarios₁ for current₂ 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.

boomzilla

@tufty said:

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.

Zecc

Oh wow, another NodeJS-based editor.

But this one is actually curses-like, for terminals!

GitHub - slap-editor/slap: Sublime-like terminal-based text editor

Sublime-like terminal-based text editor. Contribute to slap-editor/slap development by creating an account on GitHub.

blakeyrat

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.

cartman82

Hey you know what? This actually looks pretty good! I'll try it out.

hungrier

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

Maciejasjmj

@hungrier said:

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.

JBert

@hungrier said:

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.

VinDuv

@JBert said:

Filed under: Lovers of ed excluded.

?

dkf

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.

cartman82

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.

boomzilla

@cartman82 said:

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

cartman82

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.

Zecc

Yes, but still the point stands: it should be #!/usr/bin/env nodejs.

boomzilla

The problem is that you go from apt-get to npm. Which pulls from who knows where.

Arantor

Did anyone notice that Github Atom is one of the people advertised as a Discourse user?

boomzilla

I think one of those guys posted on the "What IDE do you use?" thread over on meta.d.

ben_lubar

They also have a forum, but the "endorsement" could be from either one.

Maciejasjmj

@cartman82 said:

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

cartman82

@Maciejasjmj said:

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.

cartman82

@Maciejasjmj said:

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.

dkf

@Maciejasjmj said:

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.

cartman82

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.

Yamikuronue

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

aliceif

They're failing for me, too.
I'm using the same version of Dischrome right now and it also fails on Discofox.