I have tried, mostly successfully, to avoid JS and I think that Lua is a program with better syntax and semantics that JS. The idea of a trilingual oligopoly of HTML, CSS and JS seems odd and I see the web more as a “exporting and delivery format” that a development platform. So having Lua in TW avoids the pain point of JS as the only deeper language to extend TW (TW has its own operators custom syntax, but I would prefer something more general, like Lua).
My idea is not a total replacement of JS in TW with Lua, as it has a lot of traction. It’s more about offering Lua as a compelling alternative to JS, starting with specific use cases: my first extension would be a playful project about supporting hexmaps for tabletop role playing games (more details this week).
1 Like
That sounds great. I’m not familiar with the TW eco-system but I see now that it has a plugin system. I’ll look forward to hearing more details from you. In the meantime I’m going to play with fengari-web.
Coincidences… I discovered Ferangi yesterday during a conversation on Mastodon. My first impression was “finally a nice scripting language for the Web”. For two reasons: First, Lua is overall a nicer (more consistent, fewer concepts) language than JS, and second, it can be used easily outside of the Web as well, whereas JS via Node or equivalents is a huge pain to work with. Maybe it gets better with experience, but the onboarding experience is horrible.
Lua in TW is definitely something I’d like to see, though I don’t know how far it can go. I see two weaknesses with today’s TW for the use cases I have in mind:
- HTML generation via TW’s macro system seriously suffers from accumulated cruft. It’s OK for simple use cases, and it can handle quite complex ones but at the price of messy and incomprehensible code.
- The only way to run code in TW is as part of the rendering process of a tiddler. There is no way to type code and run it in such a way that both code and result are visible (as in computational notebooks, REPLs, or Smalltalk environments).
Neither issue is related to JS vs. Lua. But maybe your idea is to use Lua to attack the first issue. For example, use a Lua-scriptable templating language as an alternative to TW’s crufty macro system. That should be doable in a plugin.
3 Likes
A good (but lengthy) introduction to TW is Grok TiddlyWiki.
1 Like
I just published a manifesto (15-minute video with a complete transcript and links)
http://akkartik.name/freewheeling
Shout out to @khinsen for reviewing a draft of this.
3 Likes
That’s the best sales pitch for situated software I have seen so far!
I happen to be writing my own sales pitch for situated software right now, specifically for scientific computing. The different context leads to different conclusions in particular for technology choices, but the argumentation is overall the same.
1 Like
A useful addition to your manifesto would be links to all your forks of your freewheeling app. Or a link to a list of forks, if it already exists. They seem to be scattered around various git hosting sites.
1 Like
That’s a good point. I optimized the links for random access (each repo’s Readme points to its immediate upstream and downstreams), but here it’s worth providing an overview.
I have a list of links to the bottom half of forks (everything that can be edited live) in the readme of the repo linked in the final slide. But it isn’t everything.
1 Like
As an experiment I’ve added an old-school image map at the bottom of the page. The drawback: it turns out HTML doesn’t support scaling image maps, so it looks a little ugly. Try it out and let me know what you think.
http://akkartik.name/freewheeling#resources
1 Like
Great job with this, seems to convey your points quite well! 
The image map (forgot those were still around!) of links is quite handy to browse the web of projects as well.
I think it would be good to add this video / transcript to our malleable catalog as well… Does that sound reasonable to you?
1 Like
Sounds great! I’ll refresh my memory of the template on Github later today.
Ah, no need to go to GitHub. The catalog is now driven by a special category of this forum, so all that’s needed is a new forum topic in that category.
1 Like
Perfect. In fact, my first idea when looking at your transcript was “I should be able to click on the boxes in the graph”. After all, that’s how I work with Glamorous Toolkit all day. But I thought that this must be hard to do on Web page without tons of JS. So… today I learned about image maps!
Thinking about your remarks on the Lua/LÖVE community and its attitude towards old versions. It reminded me of the change in attitude in the Python community as it started to grow rapidly. Before, people installed Python from source and it was quite normal to have several versions in parallel. Then, Python distributions appeared, roughly at the same time as Python became common in the big Linux distributions. From then on, the attitude “everybody should update to the latest version” become the norm, the disagreement being only about how much time one should leave for users and distribution managers to follow the official release schedule.
Maybe this is part of professionalization? I wonder how Lua escaped from this. A quick check shows that both Ubuntu and Guix provide multiple Lua versions in parallel, which was never the case for Python apart from the 2->3 transition period.
1 Like
It’s quite possible that Lua is on the same trajectory but not as far along. Or it’s not in the same trajectory in spite of trying hard to be. It has a package manager just like the other languages (Luarocks). And there’s certainly no coherent principle of avoiding native libraries, a constraint I’ve been forcing myself to follow. Part of my hope is to articulate to the community why what they have is valuable, so they don’t throw it out over time like so many others have done.
But perhaps it’s not so hopeless. The embeddable nature is intrinsic to Lua and the other languages never had that. Hopefully that provides a large enough counterweight.
1 Like
This is a bit of a ramble, but I found a game today which led me to this new game engine that looks quite promising: https://bevyengine.org
But then I scroll down to the bottom of the page, and see the number of companies sponsoring them, and back away slowly. Compare the bottom of https://love2d.org (2 companies)
Early Python was embeddable, and for a while it was popular in scientific computing to add a Python interpreter for scripting simulation engines and visualization software. Those software packages then slowly mutated into Python programs, with the native code (C or Fortran) transformed into libraries. Embeddability was effectively lost with the transition of Python’s C modules to dynamic libraries.
With your principle of avoiding native libraries, your bedrock platform really is LÖVE, not Lua. It’s LÖVE that defines your interface to the lower layers of hardware and software, much like the JVM defines/limits what Java code can do without native libraries.
Oh interesting, I was not aware of that early context. I suppose embedding must have been an important use case back in the early 90s. Computers were so much slower. I didn’t come to Python until 2001/2002.
With your principle of avoiding native libraries, your bedrock platform really is LÖVE, not Lua.
I don’t follow this. For one, I don’t understand your notion of “bedrock platform” and why it matters. For another, I don’t understand how the presence or absence of native libraries in a program changes its bedrock platform.
…much like the JVM defines/limits what Java code can do without native libraries.
The analogy here seems inverted? The equivalent of JVM here is the Lua VM. I don’t think LÖVE makes any changes to it.
What I call “bedrock platform” is the interface between your code and the rest of the computing universe. It’s the foundation that is necessary and sufficient to run your code and that you (have to) suppose will always be available.
Lua + LÖVE but no native code means that your code has access to whatever Lua + LÖVE provide. For example, if they provide an API for the file system, then you can access files, otherwise you can’t.
With “native code”, your bedrock platform is your device’s OS. Maximum capability, but no portability and uncertain stability.
Yes, that’s right. As a concrete example, baseline Lua has no way to list directory contents. LÖVE provides such a primitive, but only within a small part of the system (under the save dir). So a LÖVE app mostly doesn’t.
1 Like