Something that I've begun to do recently is writing my applications in web technologies with HTML, CSS, and JavaScript. The reason for this is that it has many benefits, cross-platform being a big one. However, it wasn't the biggest one that I saw. Maintainability and ease of development were the biggest. The code-base for my apps would stay very simple and easy to understand to any web developer. Changes could be made very easily and quickly given HTML's dynamic capabilities.
Seeing the current state of the menu's development, I think it may be ideal to at least consider doing this. I've outlined some more reasons below.
Pros:
- True Cross-Platform: Very early into the platform's development, some developers here considered writing it in C++ for the advantage of being able to deploy the platform on OS X and Linux in addition to Windows. Although we have not created a launcher concept for Linux and OS X, this could be something we look into for the future. WINE is great, but a platform that runs without its inconsistencies would be better.
- Moving away from Delphi: The fact that the current platform is written in Delphi scares away new developers. Delphi is expensive ($999 or $199 for starter) and not worth learning due to its low usage in the industry. On the other hand, HTML, CSS, and JavaScript is used almost everywhere.
- Opening to the community: Web development is known to almost all programmers. Having the platform written in an ubiquitous language will have more contributors ready to make patches.
- Screen-reading: We've struggled with screen-reading support in the past. Screen-reading would work almost the same as a web page in a browser, so support for it is built in. Machine reading of HTML is a very established technology.
- Design is limitless: GUI widgets are no longer limited to the Windows toolkit. There will be support for a custom designed scrollbar and one that resizes appropriately.
- Theming is limitless: Practically all elements of the menu will be modifiable with CSS. Themes will have control over how many items are displayed on one page, sizes of elements (including the menu itself), and even placement of menu items. Overall, much more control than before.
Cons:
- Depreciation of current code: The current code has been in work for at least 5 years, so there is a lot of sentimental value to it.
- Size of distributables: AppJS has a 20 MB overhead, so the install size of the platform will increase from 10 MB to around 25-30 MB. This isn't a large concern for modern usb drives which are growing in storage monstrously, but a platform of this install size may scare some.
Overall, I think it is worth it. I feel like I could have the current platform written in this code within 2-4 weeks (considering my other commitments). Thoughts and opinions?
Edit: Let me clarify. AppJS is not the only framework I had in mind. I just mentioned it in the cons since it was the only one I could quickly look at the overhead for.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
While I like the the route you're going down in thinking, there are some big assumptions in the above. For starters, AppJS is pre-pre-alpha stage, aka version 0.0.20, so I don't know that I'd want to base production-level software on it. As for the other points.
The pros are a bit idealistic and some turn out to be cons on further examination:
On the cons, neither of those are really a big con. Size is less of an issue. There is no sentimentality tied to the existing code. We just want it to work, have it work well, have it be fully open source under the GPL, and have all code joint copyright with us so we can link it to proprietary DLLs for drive-specific hardware features and other situations should the need arise.
Sometimes, the impossible can become possible, if you're awesome!
I've started to look into this, but haven't had time yet to do more than run Lazarus' auto-converters. Unfortunately, not everything was converted initially, so I'm having to step through more or less line by line.
I'll put up a mercurial repo if anyone's interested in helping.
Thank you. I like the way I think too.
I wrote the original post generalizing around building an interface in web technologies, and neglected the actual framework to be used since I thought that was more trivial and could be decided later. It looks like that was a mistake since the post now suggests that AppJS was what I had in mind. I only mentioned it because it has the smallest overhead I've seen in a framework like this. node-webkit is what I've been using for my projects, and it is much more production ready than AppJS. It is being used in a lot of software projects, so I'd argue that it is very stable.
Considering that, I think a lot of the points you made are incorrect and I am probably less idealistic now. Let me clarify somethings from my original post.
I really feel like this would improve the platform and allow us to add new features at a pace quicker than before. John, you're practically the only platform developer, and I think that should change so you can focus on more important matters.
The issue of overhead is the only one I really see. node-webkit is ~40 MB in application overhead. I need to experiment with reducing this size.
You may not see them, but these issues are large and remain.
I'd love to get more help working on the platform. But, I don't think these alpha-quality web engines are the way to do it (node-webkit is alpha, AppJS is pre-alpha). Lazarus is probably a more likely candidate. C++ code be, too, with enough developers. We have one other interested party who has already contributed Delphi code as well which will be in the next beta in a few days (the PStart-style cascading menu from the taskbar some folks asked for).
Sometimes, the impossible can become possible, if you're awesome!
I'm confused as to what the biggest issue is. I would have thought it was about screen reading, but that wasn't your third bullet point.
I feel like we're not on the same page with the HTML/CSS/JS limitations you're talking about. Node.js and its module system provides limitless capabilities that anyone with JavaScript knowledge will be able to use. Here's Node.js's native filesystem module. Here's a native event binder to detect file changes. Here's an npm module for usb plug/unplug. Anything in C/C++ can be turned into a Node.js addon by simply wrapping them.
What you're saying kind of contradicts what I've heard until now. I've always thought that web pages had the best support for screen reading. I'll look into this further. I also thought this would be an improvement since I last heard that the platform still had some issues in this area, but it looks like it was more minor.
I don't know what bad GUI of example applications has to do with this. The platform doesn't have to look like any of those apps. Here's one of my apps for something that looks a bit better (at least in my opinion).
Not that I don't believe you, but where did you find that node-webkit is alpha and that AppJS is pre-alpha? I don't see that status on either of their sites and GitHub pages.
node-webkit is versioned prior to 1.0. This is, by definition, alpha quality. Or beta if stated. 1.0 is the first release you consider 'stable' and production-worthy.
My 3rd point was exactly what you think. You can't write in node-webkit with just HTML/JS/CSS, you need to know node.js as well (a much smaller subset of HTML/JS/CSS folks). And then write a bunch of plugins for all the things it can't do. Some of the things it can do, but not well. For example, fs.watch is listed as unstable, which makes sense as node.js is not considered 1.0 yet. The USB plugin you mentioned just hit 1.0 a few days ago, has been downloaded a total of 32 times, and only has a single developer. It requires two other plugins each also with a single developer, one of which is also pre-1.0. Honestly, the further you get, the more it confirms alpha quality (fun to play with, but don't build anything important with it yet). Many of these seem like proof of concepts still. And some of it seems like it is being built for the sake of the 'node.js is the hot new thing and can do everything' crowd. The same phase that every hot new thing seems to go through in the last few years (we could always write it in Ruby). That's the gist I get from it anyway.
Screen reader support in web browsers is one of the most difficult things to do and has to be done per-browser. Native control support is built into every screen reader, which is why they can do nearly all regular apps with ease (unless they use oddball custom controls). Google Chrome is only recently working properly with the standard screen readers. I really doubt that a chromium-hack to do local apps with node.js will work well with them. I could be proven wrong if you test your app with NVDA and it works well, though.
Mind you, I'm not poo-pooing what node-webkit could become in time. It's just that right now, it doesn't look like it meets our needs. It's far too young, immature and unstable (as in unfinished/unfinalized, not necessarily crashy).
Sometimes, the impossible can become possible, if you're awesome!
If we're talking about Semantic Versioning, Semantic Versioning Specification #4 and #5). That's not quite the same as unexpected behavior and crashing, and certainly doesn't mean we can't use it for something important. Node.js is at the 0.10 version number because there will be more API changes in the future, but it is used very extensively in the industry. Really, the common practice for an unstable application with unexpected behavior is to denote alpha quality on download pages, or somewhere on the site that it is not ready for usage. node-webkit and Node.js are both quite ready for production and I'm sure their respective lead developers would agree.
C/C++ Addons for Node are simply just wrappers and bindings for C++ functions. There's not a whole lot that can go wrong here if the developer understands the process.
I tested my app in NVDA. It worked beautifully. The only issue I found was reading of the "User Messages" pane and it's likely that the issue is tied to it being a textarea. I could and probably should change that to a div to fix it. I feel like some ARIA controls may also work to fix screen reading of that pane. On the other hand, I just noticed that the Platform (11.2 and 12 beta) have some issues. All I'm getting is "PortableApps.com Platform K" spit out at me. None of the items in the menu are being read to me. This contradicts the blog posts I've seen, so is there a setting I'm missing or something dumb I can't figure out?
Regardless, you've expressed your disconcert at the idea, so I'll drop it. There's no way for me to convince you that technology is ready if you don't think so. I enjoyed this discourse though.
The immaturity of the platform is one of my biggest issues. As is the extremely small number of developers. An unproven, immature, small volunteer team technology isn't something I want to base something this important on. And, regardless of the semantic versioning website, pre 1.0 means not ready for prime to most of the world. The C++ add-ons aren't merely wrappers to Windows APIs, they have to manage the communications in an ongoing way with those Windows APIs (example, listen for notifications from Windows for a USB drive insert), so we'd want those to be very solid and many of them are clearly very new and mostly untested. Couple that with the fact that the developers themselves label functionality we need as unstable (which I'm unsure why you keep glossing over), means that a platform written in it could be a fun exercise to play with, but not production-worthy enough to push out to millions of people who depend on it.
I get that it's interesting new technology and you enjoy writing in it and are a fan of it, but that's not reason enough to switch to it. Nor is it a reason to switch to Ruby or Python or C++ or Lazarus, etc. We need stability of the base product, some real proven large-scale apps as examples instead of really basic webpage-style apps, either an actual paid support policy or a large and active community around it, a larger team of developers would be nice instead of the ~3 that seem to commit, etc. I'd wager this is why you don't see any decent size apps written using it yet, just these small proof-of-concept type apps. It's still very early stage pre-1.0, so this is expected.
All the above doesn't mean it's bad or worthless, just not up to the level we'd need it at yet for PortableApps.com. And it does seem like a yet, because this has some really solid ideas and tech behind it. I'm honestly pretty curious to see how well this works and what can be accomplished with it. And it would be an excuse to learn node.js and refresh my JS skills, which I've been meaning to do. On that note, how much work do you think it'd be to get a MVP (minimum viable product) of the menu? Not the full updater or reading in non-PAC apps for now (that would need another plugin written), but just the base?
As for NVDA with the platform, I'm unsure why and will take a look. I tested it myself on Windows 7 x64 and it worked with both the local and portable versions. NVDA does have a tendency to change a lot between releases (it's not exactly stable and solid) so they could have introduced some regressions since then.
Sometimes, the impossible can become possible, if you're awesome!
A minimum viable product would not be a lot of work. You're right that a full product would require a C/C++ plugin for icon extraction of non-PAC apps. That's probably the biggest mountain.
Creating the interface is done with standard HTML & CSS. That should take no longer than a day. The manipulation (renaming, organizing apps, creating context menus), should take around a week. I don't see a lot of work for a MVP.
I'm starting to think that the biggest potential for this is overhauling the App Store we currently have..
Edit: I'm willing to put in the effort to make a MVP for demonstration. I'll have to start after I finish the Driver Station app I screenshotted earlier though. I don't have a problem with waiting a year or even two years for these tools to mature.
But AppJS is still very young, and just from a quick look at their bugtracker seems to have a lot of missing features.
I am all for it if there is a more mature alternate to AppJS, or when it works out some of its issues.
I'm cross-posting this from irc so my thoughts are in the pertinent thread.