Hacker News Reader

Comment by Goopplesoft | Hacker News Reader

> and to be honest, I think their technical choice of going for Javascript will be their ultimate downfall, but that's a discussion for another day

I'd like to see this discussion today ;)

View on HN

It's not javascript. Modern javascript engines (like v8 which powers Atom) are well beyond fast enough. GC can cause occasional latency if the programmer is lackadaisical with allocations, but with care it's a non-issue.

But Atom simply will not achieve performance competitive with Sublime while they are using the DOM. The DOM is too general-purpose for what is almost always just a grid of monospaced text. The overhead introduced by allowing plugins to render entire webpages inline with the text is just too much.

I want so very much to like Atom --- a Free text editor that isn't vim or emacs and is actually powerful enough to replace them, but the imperceivable latency manifests as a gradual accumulation of stress.

Maybe I am too old to get this, but the idea of keeping bending the browser for native applications just doesn't make sense.

Why not? The browser is something like a mechanism for delivering text, images, layouts, and interactive scripts. It's highly cross-platform. Quite perfect for many uses, and the popularity of web apps is almost evidence in itself.

CSS is a bit annoying, but with evergreen browsers and flexbox it's getting very good—and even as annoying as it is, it's still mostly easier to work with than most GUI toolkits.

I often think of the browser as something like an X11 server. It doesn't matter how old you are; why don't you think it makes sense?

> Quite perfect for many uses, and the popularity of web apps is almost evidence in itself.

Mobile and micro-services will change that.

> why don't you think it makes sense?

Because I went through the evolution of using text based GUIs, Amiga, Atari and PC GUI toolkits, drawing UIs with the likes of Visual Basic, Turbo Pascal, Delphi and C++ Builder. To the modern ones of XAML, Cocoa, QML and so on.

The list is just a bit long to post here. Most of them provided a saner developer experience than HTML/CSS/JavaScript will ever do. Unless we throw DOM away and replace it by something more tailored to applications instead of rendering documents.

Even if the DOM gets replaced, the browser can hardly provide an integrated experience in terms of what any native desktop/mobile environment offers to its users in terms of immersion and interactivity between applications.

It is just no different than using Java with AWT 1.0 in the early years without native widgets and integration to the respective desktop APIs.

Hmm, interesting. I've used a few GUI toolkits, written bindings for GTK+, worked with Java and Swing, etc. Modern web development, especially using React, is in many ways the sanest thing I've come across.

It reminds me of stuff like Emacs, Lisp systems, Smalltalk, etc. Inspectable environments using dynamic languages... But React's model for components and DOM elements seems to me in many ways easier and better than Emacs buffers or Smalltalk widgets.

I use browser developer tools a lot for changing scripts and styles interactively, and while it's nowhere near perfect, it's often extremely useful and convenient, and I think the model has lots of potential.

> It reminds me of stuff like Emacs, Lisp systems, Smalltalk, etc. Inspectable environments using dynamic languages

In a way yes, but only if we can get rid of DOM and have 1:1 parity with desktop APIs.

One ends up piling div elements with CSS and JavaScript, to imitate something that looks like native widgets, but don't behave like them nor can interact with the desktop environment.

I find Qt5's QML to be a million times easier to use, read, debug, maintain. And that is because it is designed as a markup for applications. HTML was never designed for that. Neither was CSS. This is the reason for all this incredibly inefficient HTML webapp madness.

Unfortunately, HTML won...

The DOM's main advantage is supposed to be accessibility and portability to different form factors; otherwise, just roll your own UI using Canvas (like I do using WPF canvas anyways for my editor work). It's not clear to me how accessibility could be preserved while allowing for more flexibility.

Mobile and micro-services will change what? Even then microservices are an architectural pattern, it's not inherently tied to a platform, whether it runs native or in the browser.

Many native application on the mobile space are using micro services with a native UI, as a means to provide an integrated user experience with the respective platform features and keeping the business logic portable.

I don't like that it's this way, but the web is a (mostly) open standard for GUIs that is supported virtually everywhere that has a GUI at all.

Cocoa and .NET produce good interfaces but are proprietary and only work on one platform. GTK+ is Free and "works" on all desktop platforms, but anyone who's used a GTK app on mac can tell you how awful it is (and it's really the only place that it's great is on GNOME-based linux DEs).

Qt is Free, and it has fairly good support on all platforms (even mobile), but making the interfaces look and work great on all platforms requires the developers to put a lot of work into custom UI elements (see how Qt programs look on GNOME or OS X when they use the default UI elements). It also requires developers to use C++, offensive to programmers who prefer hosted languages (although arguably better for those planning to port to mobile). But the C++ it uses is so far removed from non-qt C++, even requiring compiler plugins, that many C++ developers have qualms with the language it uses.

The web is programmer-friendly, cross-platform and Free. Writing a desktop app using web tech means it's relatively easy to port it to ChromeOS (or FirefoxOS if that becomes popular ever) or an in-browser app. It has the lowest performance of any of the mentioned technologies, which is only relevant for especially performance-sensitive apps (text editors) and mobile.

Really Qt wins out on technological merit, but web is comes in a close second, and there's actually a large supply of developers who know what they're doing with web.

With Qt5, you write your interfaces (and optionally can even write all or most of your app) in QML. I tried it out, and it is such a breath of fresh air, compared to HTML/CSS. You can achieve the exact same thing with a small fraction of the resource consumption.

Browsers give you cross-platform windowing.

Without having installers that include adware (Java) or that seem borderline-unsupported (X11/Quartz) or that require funny multi-stage compiling (Qt).

> Without having installers that include adware (Java)

Only for developers that aren't savvy enough to know the multiple options to bundle the runtime or compile to native code.

Or the users that don't install Java from http://www.oracle.com/technetwork/java/javase/downloads/jre8... or can't be bothered to read a dialog box.

> or that seem borderline-unsupported (X11/Quartz)

Since when is Quartz unsupported?

> or that require funny multi-stage compiling (Qt).

Since when do users compile GUI frameworks?

Cross platform UI is nothing new, there are much more options to choose from than those you listed, and browsers can hardly offer more than a 90's GUI experience.

> Since when is Quartz unsupported?

I think he was referring to X11.app — aka XQuartz — which has not been supported or included in OS X since 10.6 (Mountain Lion).

Qt only requires funny multi-stage compiling in C++. If you use it from Python it all just works.

And there's no reason someone couldn't create similar bindings for atom/node/iojs etc...

But that means the technology is being chosen to suit the developer, and not the end-user.

Most native applications use a language runtime and most GUI ones use a general-purpose declarative layout engine. Put those together and you basically have a browser.

Except their GUI (if well made) is much better at interop, handles tons of shortcuts that are forgotten in webapps, and native apps don't have to bother with crazy amount of limits browsers have "because security". Like Chrome not letting you bind to half of the Emacs shortcuts because some evil actor could use them on a webpage to phish you.

HTML is anything but general purpose.

It's the closest thing we have to a general purpose, cross platform application engine that pretty much runs anywhere with a GUI interface (for anything updated in the past 3-5 years).

Browsers are more easily available on every major, and most minor platforms than any GUI toolkit out there... Things like atom, brackets and similar make sense. They translate well between standalone app in an OS, or a platform app for the likes of ChromeOS, or as a SaaS app in a browser.

No, they aren't the fastest, lightest or best performing. They don't even have the smallest codebases... what they are is broadly available, with minimal variance and a lot of developers with most of the knowledge needed to maintain them.

Using CSS magic tricks and JavaScript to make an unordered list appear like a menu or a toolbar just feels wrong, just as one example from many.

I liked the way XHTML was going to remove the semantic and pave way for proper components, sadly it never happened that way.

Anyone experienced with XAML and similar layout engines can see how much better the browsers could be, if people wouldn't insist into binding a document model into an application engine.

Even with HTML 5, which still is a problem to support properly across multiple devices without a "debug everywhere" attitude, has less widgets support than a 90's GUI.

Completely agree. The fundamental problem is that HTML and CSS are the wrong tools for webapps. They are designed for documents. This is why all these CSS rules are so hard to use for applications. It is built on the model of a document, not a user interface.

The situation is immensely worse on machines like the Raspberry Pi or the BeagleBoard. People have drunk the HTML5 kool-aid and now want to run HTML5 on such machines. When you see how these boards choke when running stuff like an asteroids clone in Firefox or Chrome, you weep. Write the same thing in C++, or in something like XAML/XUL/QML/Enlightenment Edje, and it is super smooth.

My favourite would be something like QML, but with Lua instead of Javascript (but a Lua variant where the array indices start with 0, not with 1). Lua is much easier to accelerate properly, as LuaJIT has shown.

So use a component adapter, like polymer... That said, I wouldn't mind something closer to XAML or Flash/Flex that was an open specification, with a cleaner language implementation (though, I like JS)...

The trouble is actually getting a cross-platform rendering engine working everywhere that HTML/HTTP already works... So, you go build it, get it working at LEAST on Windows, OSX, Linux, Android and iOS... then we'll see how adoption goes. More likely you'll see React* bindings take off with generators to whatever platform is targetted, with JS as the language in use.

> So use a component adapter, like polymer

I am yet to be on a project where the customer uses them on their stack.

>So, you go build it, get it working at LEAST on Windows, OSX, Linux, Android and iOS

Qt, JavaFX, Xamarin Forms, any SDL based GUI

> Qt, JavaFX, Xamarin Forms, any SDL based GUI

I don't want to spend money on the side projects I'm just playing with, but it would be nice to have them cross-platform (including mobile). Do any of those options still apply? IIRC Xamarin is expensive and there's no free way to run Java on iOS? All the SDL-based GUIs I've seen have looked awful.

Qt would be lovely - what does using it from Android Java look like? I remember messing with the Qt Java bindings a while ago and finding them a bit ropey.

Is it any more insane than effectively running applications over telnet (that is, a fixed width text terminal)? :)

So much this. The DOM is absolutely going to be the bottleneck more than JavaScript. I can't really provide any concrete benchmarks to support this because its a very complex topic, and you can really only come to that conclusion after trying to optimize the DOM for something as critical as a text editor.

>"Free text editor that isn't vim or emacs and is actually powerful enough to replace them"

Maybe not powerful enough to replace them but still worth a look http://foicica.com/textadept/

Just curious - why replace vim or emacs?

Don't tell me, because I use both (mainly emacs), but maybe is to do something like this https://confluence.atlassian.com/display/BITBUCKET/Edit+onli...

It can be strategic even if limited to quick edits and for some subsets of the repository now. Anyway I can think of a GitHub augmented with an IDE and integrated with a CI and CD system with deployment to a Heroku. It could let you write code from pretty everywhere, occasionally even on a tablet or a large phone. Somebody will use it.

GitHub has been slowly tricking me into doing more and more of those quick edits on their site. If they can work Atom in as seamlessly as their other updates I'm sold. Somehow I'm still circumspect.

emacs doesn't have decent support of jsx: the jsx-mode is actually for another tech with same name, the js2-mode is great except xml support.

i love vim a lot (use evil in emacs), except vimscript. I hope oneday I could use neovim with atom/st2 as frontend.

I use web-mode to edit JSX. It's not bad at all actually - the indentation and highlighting are there. I've started using web-mode for its intended purpose, too (when editing templates that have CSS and JS snippets).

Reply on news.ycombinator.com