One thing I noticed is that it doesn't draw zoomed-in images correctly - pixels are blurry. Didn't check if this is Canvas or WebGL, but something in the code begs being changed from LINEAR to NEAREST.
(EDIT: turns out to be a Firefox issue; Chrome shows the sweet pretty pixels correctly.)
> I really think this is an awesome project, but I am old enough (30) to remember fast performing GUI apps and I don't know if I'll ever "get over" losing them.
Same here (I'm 29). I'm getting tired of complaining, this literally feels like trying to turn back the tide of a river. We're doomed to use slow and shitty software until the present web fads go away and the ecosystem stabilizes.
I don't see that happening. Web apps gave us an environment where it's easy to create complex applications quickly. Now efforts are going towards making these apps smaller and faster, but I don't see developers going back to C++ to develop GUI apps like this one.
I do like Java, but sometimes get a bit pissed off how things went, because we had "an environment where it was easy to create complex applications quickly as well" in the form of Smalltalk, VB, Delphi and C++ Builder.
With the exception of Smalltak, all had native code generation, then Java happened.
VB (i assume you mean classic VB, not VB.NET) wasn't really an environment to create complex applications though - at least not in VB itself. The best use for VB would be to use to mix together components made in other languages (often C and C++). If anything people who tried to use VB as the implementation language for complex stuff regretted it later.
I agree about Delphi and C++ Builder though, but Borland seemed hellbent on chasing enterprise unicorns - and pricing their products according to those dreams - so the software and the ecosystem suffered because of it.
I'm not sure about Smalltalk since i haven't used it much to know, although the first time i came in contact with was with a demo of IBM's VisualAge Smalltalk that was given on a magazine coverdisk and i ran away screaming (ie. deleted it immediately) when it took ages for the environment to load and do anything on the 4MB 386 i had and even then after following the simplistic tutorial it created an "executable" (that actually needed some other stuff to run) that was like 10MB (which for my 130MB HDD was a gigantic waste of space). Of course that was probably the entire image, but i didn't knew it at the time - and it wouldn't change much really, i needed the space for games and other stuff :-P.
I remember liking being able to drag arrows between elements in the GUI to hook events and properties together. I haven't seen that bit in the little i played with Pharo some time ago, i wonder if it was VA-specific. I tried to run the demo when i got a better PC, but for some reason it wouldn't work in Windows 95 and it has been years since i lost the disk. I wonder if it is available somewhere online but all searches point me to IBM's pages that have nothing.
Starting with version 5, VB allowed the creation of COM components natively, and could generate pure native code, not like the previous versions that just embedded the p-code inside a binary with a VM.
I have seen several enterprise level applications, with distributed objects (DCOM) and transactions, written purely in VB.
Including my first sight of an "Electron" app, exposing several COM libraries, written in VB, into a MSHTML container, using those objects from JScript in the page!
Regarding Borland, when Java came into picture, the company was still doing alright, and their Java development environment was designed similarly to the Delphi and C++ ones.
Their problems and change of focus came afterwards, when they lost a few people to Microsoft, including Anders, whose first project was to design Microsoft's Java implementation, J++.
VB5 indeed allows that (i have a VB5 box i got off ebay some time ago :-) and i've spent a lot of time with that and with CCE before that), but the language isn't really that friendly towards complex applications. But FWIW i think that VB lost its way around version 4 or 5 anyway :-P.
About Borland and Java, i actually have JBuilder 2 (again off ebay - i collect old development software :-P) and yes it does look nice and sort of friendly (although it is far from Delphi's level of ease of use). I think the entire thing is built on Java too. Sadly it doesn't seem to work in modern Windows - even the applications it creates throw exceptions.
Java had the advantage that it not only worked everywhere, it had just so incredibly much built in. The Java standard libraries alone provide more functionality than in many other languages all third party libraries for a feature can do combined. Building cross-platform apps in Java is actually easy, even easier than in Delphi or VB.
Nowadays, in Node, we don’t even have timezone handling properly built in, or UI frameworks. Or anything.
Sure, one of the reasons I liked it, was because of the chaos that still was writing portable C or C++ code back then.
But when focusing on the PC market, it felt a step backwards being interpreted, the JIT only came in 1.3 and AOT compilation has only been available in commercial JDKs (gjc was never that good).
Let alone the whole story with value types.
Thankfully, I have been able to avoid Node thus far.
I meant it primarily as "present fads in the web ecosystem", not "web as a fad" (I ultimately gave up on the latter; that's one hell of a tide and it ain't getting turned around).
> Now efforts are going towards making these apps smaller and faster
Yes, I'm hoping those efforts will eventually bear some fruits.
> We're doomed to use slow and shitty software until the present web fads go away and the ecosystem stabilizes.
I have two possibly conflicting thoughts about this. (I'm a little bit older, and I feel like this has nothing to do with the web.)
One, everything computer related was much, much slower, and much, much shittier when MS Paint first came out. I feel like software and software standards and hardware and the web, all of it, has improved.
Two, I'm not convinced we'll ever escape shitty software, I think we always have and always will have slow and shitty software, outside the web and inside. We always want the machine to do more than we have a budget for, we always want to write features in less time than we have, we always want cooler features than others, etc., etc. Keeping software fast and good is time consuming, expensive, takes more self control than most have, and often just isn't the highest economic priority. In short, I think there are legitimate reasons we're always sitting at the threshold of pain rather than the threshold of pleasure.
Seems to me like "shitty software" is just a moving target. All software is shitty because we can envision something better. In 10 years we'll all be complaining that Windows 20/macOS 23/iOS 21/Android {{confectionName}} is shitty, though surely it will be something that our 2018 brains would find amazing.
I'll give you one definition of shitty that particularly annoys me: does the same or less than an equivalent made 10+ years ago, while running just as fast or slower than the old one. Advances in hardware seem to be mysteriously eaten somewhere.
Oh. Didn't even occur to me that it could be a browser issue (after all, I would think that not antialiasing things in an API meant for per-pixel operations would be the default). Alas, you're right and guessed correctly - I tested it on Firefox. I just tried it on Chrome, and there the pixels show correctly.
Software will always fill up the capacity of the hardware.
For me the brush tool is very smooth (running Chromium browser on a 5 year old gaming/dev rig).
The problem is that most software of today doesn't do much more than software of a decade+ ago. The capacity of hardware is filled with boilerplate, abstraction layers and an occasional UI animation sprinkled on top, instead of more powerful solutions to more difficult problems.
Except that what used to require a much larger and heavier machine can now be done with a phone, if not a watch.
Cars don't really do much more than they did a century ago. This doesn't mean there haven't been HUGE improvements to make them do their function better.
> Except that what used to require a much larger and heavier machine can now be done with a phone, if not a watch.
That's just a function of miniaturizing hardware. Think how much longer your phone's battery would last if not for the software bloat.
> Cars don't really do much more than they did a century ago. This doesn't mean there haven't been HUGE improvements to make them do their function better.
They serve the same fundamental purpose (moving people around), but they are faster, more economical, much more safe, and offer large amount of convenience features. In a way, it's the exact inverse of what's happening with software.
See for example the history of Photoshop and games!
When making software you don't optimize more then needed. It just have to be fast enough. But where performance is a selling point, things have actually gotten faster, for example JavaScript engines. And compilers can probably compile a 20 years old program and make the binary more optimized then it was before.
(EDIT: turns out to be a Firefox issue; Chrome shows the sweet pretty pixels correctly.)
> I really think this is an awesome project, but I am old enough (30) to remember fast performing GUI apps and I don't know if I'll ever "get over" losing them.
Same here (I'm 29). I'm getting tired of complaining, this literally feels like trying to turn back the tide of a river. We're doomed to use slow and shitty software until the present web fads go away and the ecosystem stabilizes.