> The PilBox App itself (called the "PilBox kernel") is written in Java, the normal Android way. It displays a WebView GUI, and starts a PicoLisp binary compiled for Arm64 CPUs. This binary may now run any PicoLisp program, by setting up a local web server where the WebView component connects to, possibly opening a database, and doing whatever is desired.
I think this is a really cool project and I'm all for new (to me) lisp dialects doing their thing, but reading the main page, the tag line and copy don't seem to match, for my definition of "simple":
> [picolisp is] Programming simplified!
> PicoLisp is a programming language, or really a programming system, including a built-in database engine and a GUI system!
These two statements seem to be at odds.
That aside, I do like the idea because I'm a huge fan of the HTML/JS/CSS display paradigm for it's easy cross-platform support.
I also like reducing the "mobile app" to really just interacting with a single local "edge" (which is what people are calling client-side programs these days I think) server. Just me personally but I would love it if all frontend development was reduced to HTML/CSS/JS -- I have no desire to learn QT/GDK+/wxWidgets/whatever else (just like I don't like learning Java for Android, Swift/ObjC for iOS, Java for Blackberry, etc), and firmly believe that eventually performance will be comparable (or close enough to not matter) and support for native features will be passable.
You're right in that JS is a horrible language -- it was designed very quickly (and IMO Brendan Eich did a great job in the time he was given).
There are some things JS got right and things JS got wrong -- but I basically put it at the same level as languages like python/ruby/perl.
Another great thing about JS is that if you hate the semantics of JS, you can transpile -- pick up Typescript, Flow, Elm, Purescript. Compile-time-checking-as-an-addon, linters, transpilers, have all seen a tremendous uptick in interest partly thanks to JS's shortcomings.
Also, what in your opinion is a "good" language? because the list of innovative languages with amazing time-saving features/ground breaking research in them is very different from the list of workhorse languages people use from day to day.
This is all by unfortunate necessity, certainly not by choice.
The very raison d’etre of languages like TypeScript that transpile to JavaScript is because of the flaws of this hack language that simply found itself in the right place at the right time in history
It can scale but it takes an increadible amount of care.
Everything has to have unit tests and documentation and be split out into reasonable modules. Large scale projects in C are honestly easier to work on than JavaScript.
It does scale but almost no one puts in the effort to do it.
If writing a lot of support code is inevitable anyway, why not automate writing tests, etc? That is, why not write a proper translator from a more expressive language? Something like Elm, maybe.
But this is one of the things that I think will disappear over time. What parts of the user experience are bad for you? Accessibility? Raw speed? Native transitions?
It's entirely possible to write a completely native app with terrible user experience. Right now making an app with great UX is hard, but I don't think it gets easier by solving it separately for different platforms, I think it's easier to build giants to stand on by focusing on one platform.
Also, people talk about UX a lot, but half of the most successful apps out there have really basic UX, and are basically websites to start with.
- Not able to use OS widgets. They might look similar with lots of CSS effort, but we stay at the L, instead of L&F
- PWAs are a step in the right direction, yet ServiceWorkers feel like a hack for what native applications get for free
- As a example, writing an application that can seamless transition between mobile and desktop platforms, like Microsoft's Project Rome.
Many successful apps with lousy UX are successful, because they are the only way to access certain services.
As a consumer I only use web apps when there is no way around it.
As a developer I don't get to be picky about which projects I get to work on, but I surely make my point of view every time customers ask for something that can only be provided by proper OS integration.
I'm not sure what this means... You mean like the propensity of web apps to open non-native modals?
> - Sluggishness
This really depends on what kind of blended app you're using. Cordova (PhoneGap) and all the webview-based things are pretty terrible for this, but newcomers (react-native, nativescript) have been doing much better with the bring-your-own-js-engine-and-render-on-separate-thread approach.
> - Not able to use OS widgets
This is completely overcome-able with sustained effort, and appropriate sharing. Flutter literally decided to draw every single pixel on the screen and was able to do it, CSS styling is easier in comparison.
Also, this isn't a problem for the hybrid frameworks like react-native or nativescript, they do use native widgets, but you lay them out, style them, and perform interactions with HTML/CSS/JS mostly, which is preferable to trying to figure out each platforms layout quirks.
> - PWAs are a step in the right direction, ...
Yeah I think I wasn't clear enough with what I wrote -- I don't mean I want the web itself to become the mobile platform, I just mean I like approaches like nativescript and react-native/vue-native much more than learning ios and android separately, and think the HTML/CSS/JS paradigm is better than those things individually.
ServiceWorkers are the only solution if you are talking about a purely web app (webview) -- you can actually shim and use native stuff if you want, OR serviceworkers, or whatever else if you take the hybrid approach, while maintaining html/css/js for most interactivity.
> I'm not sure what this means... You mean like the propensity of web apps to open non-native modals?
There is a reason why it is called Look and Feel, not just Look.
You can make them Look as close as possible with looks of CSS work, or even canvas drawing, but they don't Feel like native widgets.
> This is completely overcome-able with sustained effort, and appropriate sharing. Flutter literally decided to draw every single pixel on the screen and was able to do it, CSS styling is easier in comparison.
Drawing pixels is only half way there to how native widgets interact between each other, or even basic stuff like dragging content between them, in different applications.
If we take the web part of it, on native rendering side, HTML/CSS are not as powerful as native rendering. For example the visual layer in Windows 10, animations engine in iOS and Android.
HTML/CSS is kind of ok, if one only cares about CRUD applications.
> The PilBox App itself (called the "PilBox kernel") is written in Java, the normal Android way. It displays a WebView GUI, and starts a PicoLisp binary compiled for Arm64 CPUs. This binary may now run any PicoLisp program, by setting up a local web server where the WebView component connects to, possibly opening a database, and doing whatever is desired.
I think this is a really cool project and I'm all for new (to me) lisp dialects doing their thing, but reading the main page, the tag line and copy don't seem to match, for my definition of "simple":
> [picolisp is] Programming simplified!
> PicoLisp is a programming language, or really a programming system, including a built-in database engine and a GUI system!
These two statements seem to be at odds.
That aside, I do like the idea because I'm a huge fan of the HTML/JS/CSS display paradigm for it's easy cross-platform support.
I also like reducing the "mobile app" to really just interacting with a single local "edge" (which is what people are calling client-side programs these days I think) server. Just me personally but I would love it if all frontend development was reduced to HTML/CSS/JS -- I have no desire to learn QT/GDK+/wxWidgets/whatever else (just like I don't like learning Java for Android, Swift/ObjC for iOS, Java for Blackberry, etc), and firmly believe that eventually performance will be comparable (or close enough to not matter) and support for native features will be passable.