211–220 of 225 posts
Earlier quoted context omitted.
JSX is XML and it can cause some confusion. For instance the fact that you can only have one root node is not obvious.
It is obvious, because when you use a component, it's usage is as a single root node. should not render multiple root nodes.
return label;
Earlier quoted context omitted.
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 overhe…
Maybe I am too old to get this, but the idea of keeping bending the browser for native applications just doesn't make sense.
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.
Earlier quoted context omitted.
"I can't think of what "insane" could possibly mean in this context other than technically challenging or infeasible." Apparently, responding to keystrokes by putting a character on the screen in less than a couple hundred milliseconds is still technically challenging, or at least, doing everything we want to do within that time frame is still technically challenging for a high-powered editor. Which is less silly if…
Does it really need to happen on one core? The platform supports webworkers and serializing certain events across channels wouldn't take much... if you look at, for example some of the cross channel rendering with react that has been experimented with, there's merit there.
Earlier quoted context omitted.
I love ST; I happily bought a v2 license a while ago, and will buy v3 when it's an option. I just get nervous about the resources being allocated to its development, so I've run Atom almost exclusively for a few months as a hedge.
It's worth noting that if you haven't checked in recently, ST3 development appears to be back on track and proceeding at a pretty good clip. (Having said that, I'm keeping my eye on Atom myself. My big concern with ST3 is that the combination of closed source and single developer gives it a bus factor of 1. I'm hoping Jon follows through on his vague plan to get another developer in this year.)
Earlier quoted context omitted.
> 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…
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 tha…
Unfortunately, HTML won...
Earlier quoted context omitted.
Maybe I am too old to get this, but the idea of keeping bending the browser for native applications just doesn't make sense.
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 l…
Earlier quoted context omitted.
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…
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 docume…
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.
Earlier quoted context omitted.
Didn't ST3's creator try to get 100k in a Kickstarter-like site to open source it, and failed? I seem to remember this.
Do you have a link? I have not heard of this, but I'd be curious to see. If I knew about a ST3-related Kickstarter, there's a good chance I'd give it money (depending on the details).
Earlier quoted context omitted.
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…
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 docume…
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.
Earlier quoted context omitted.
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 docume…
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…
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