[Question / Brainstorming subsection] Long term goals for glimmer "as a whole"?
rubyFeedback opened this issue · 2 comments
Hey there Andy and everyone else,
This is a bit of a meta-question or meta-suggestion. It's a bit wild in format as usual
when it comes to my issues.
Before I explain the issue here (actually more a question than an issue), allow me to preface it a bit
and explain the context surrounding how I got the urge to ask that question.
I have been following glimmer for some time now; I forgot when I first noticed it but
I don't think I even knew about it ~2 years ago. Hard to remember without me
checking all my browsing activity (which I am too lazy to do) but I am pretty certain
to not have known glimmer ~2 years ago or so.
Glimmer itself is semi-young, I think, if we look at rubygems.org:
https://rubygems.org/gems/glimmer/versions
At the least the entries from 2017 I assume came from Andy. Not sure what happened
between 2009 to 2011 but perhaps the project is older but was dormant? Either way I
think we can say that glimmer started to "get traction" more recently. I also see Andy's
message elsewhere, e. g. the cyberpunk GUI thing and so. I assume Andy invests / invested
more time into glimmer in the last ~2 years or so, but again, I am just assuming here.
Recently glimmer-dsl-gtk support was added. glimmer-libui is a bit older now, a few months
I guess. glimmer-tk is much older, glimmer-java (whatever the name was) too, and the
javascript stuff.
In many ways glimmer is a bit similar to the idea I once had about a unified widget base,
like you just use a DSL to describe all different GUIs. Back then I was thinking mostly about
gtk, qt, tk, fox/fxruby ... but we can include the world wide web. And the latter part got
me thinking a bit...
What if we could use glimmer a bit like rack, as a base for other projects, BUT also as an
abstract toolkit for rails-based projects? Perhaps even have direct support for javascript
as-is via opal.
What I mean with this is ... if we think about rails, we work with widgets too, sort of - all
the HTML5/CSS things, and the dynamic parts via javascript or some javascript-framework.
Wouldn't it be cool to actually describe this just once, e. g. in the glimmer DSL but have
it work "internally"? I am not necessarily saying to be able to do what ALL of rails can
do, but more like ... a bootstrap stage for minimal rails-like things. Like a web shop!
We could then describe a webshop once, but have it "run everywhere". Actually I was
even thinking of converting ruby-gtk3 code to the corresponding C code or at the least
as much as possible, so I can compile it for more speed. :D
Alright. This is the intro for this issue request kind of ...
My question thus can be summarized as:
- What are future goals for glimmer (say in the next ~2 years)?
Now, Andy provides some ideas and things on a todo list, such as
https://github.com/AndyObtiva/glimmer#feature-suggestions and
elsewhere, but I mean more like "grand visions". Like what's coming
next for glimmer as a "platform"?
I think this may not only be interesting to me but to other newcomers too,
in particular when a project becomes more widely distributed (see upstream
libui struggling here a bit because others are reluctant to want to take
over :D ); things that may come to glimmer eventually. Or perhaps even
ideas that currently are too much work or can not be done otherwise due
to time constraints.
Andy writes a LOT of content which is good, but specifically I'd love to hear
good ideas too (I admit to stealing a few good ideas every now and then,
but by and large my own laziness is my own biggest obstacle so I just
want to read up on great ideas coming about, if that makes any sense).
As always please feel free to ignore/disregard or close, but perhaps in
the event that you work on glimmer in the future as well as the documentation,
perhaps you could think about this part too, whether it may make sense
to add a section to the README in this regard or not; obviously goals may
change, but that's ok, even if outdated - I like to look at my older projects
to see what grand ideas I had when I was younger; most of these never
got implemented but a very few did! :P )
I think I already addressed that question over here: AndyObtiva/glimmer-dsl-gtk#1
I am repeating again for convenience:
"I think Glimmer’s most important goals are high productivity and simple maintainability. Unification is not a very important concern by comparison. It is good to have multiple different tools available to be able to use the right tool for every varying job. Options are helpful to have."
To clarify further, if any of Glimmer's projects are enabling software engineers to write an application at a fraction of the time they could write it without Glimmer, I have succeeded in meeting my goals. In fact, that is exactly what Glimmer enables; that is finishing projects that take years in months, projects that take months in weeks, projects that take weeks in days, and projects that take days in hours.
Furthermore, given Glimmer's custom keyword support (like Custom Widgets and Custom Shapes as illustrated in Hello, Custom Widget! and Hello, Custom Shape!), it has no upper cap on productivity. You could always compose ever higher concepts that are simpler than lower more complicated ones, thus double, triple, or tenfold your productivity and more...
This also makes maintainability cheaper, meaning the work you needed to do before to add a feature is a lot less given you would have a lot less code to maintain with Glimmer DSL syntax. So, a project that took $100,000k per year to maintain now takes $50,000k or less to maintain (perhaps $5,000k) thus increasing profit by developing and selling multiple projects in the same time it would take to develop one project.
In the grand scheme of things, unification is not important at all except in cross-platform situations to make the same app run on Mac, Windows, and Linux or desktop, web, and mobile. Otherwise, I appreciate the competition that diversity brings to various projects. For example, GTK Cairo competes with Java2D, and LibUI competes with SWT. Diversity is good. It encourages different toolkit software engineers to innovate their own unique ideas that may not be available in other toolkits for a while. This ensures the entire ecosystem is thriving and growing. I wouldn't want to hold that back by trying to enforce one common unified platform on everyone.
But, as demonstrated by the Glimmer DSL for Opal project, I do see a benefit in unifying web and desktop as platforms to avoid duplicating wasted effort. That said, when people usually use a toolkit like GTK, they would not care that much about also supporting FOX toolkit. What they chose originally tend to be good enough to commit to in the long term. But, they might want to support Web in addition to Desktop, so the Glimmer DSL for Opal projects aims to provide adapters (Adapter Design Pattern) to enable the same desktop app code to run over the web. Furthermore, I added to TODO.md the idea of exploring building a Glimmer DSL for RubyMotion, which enables writing apps for mobile in Ruby. I could perhaps add another Adapter layer to this project to make the same desktop app project run on Mobile automatically (but I am not sure yet if this is a good idea given the varying screen sizes on Mobile.. I'd have to try it to find out)
Otherwise, to recap the grand vision of Glimmer, it is simply to enable higher productivity and maintainability everywhere it is needed.
For example, I don't care to support bad toolkits like Qt that are not even well supported in Ruby anymore.
But, I wouldn't mind supporting every GUI toolkit out there that has a large user base, like FOX and Swing in the future (even if generally GTK and SWT might be able to do everything they do, but better). After all, I respect people's choices for various toolkits, and I wouldn't want to hold that against them (assuming the toolkits are decent enough of course). If someone thought Swing was the best toolkit for their project, it wouldn't hurt to double their productivity and halve their maintainence time using Glimmer.
I would be willing to support every GUI toolkit that is worth its salt out there. I think FOX, Swing, and JavaFX remain as toolkits to support in the future in addition to all the current Glimmer DSLs.
I also added glimmer-dsl-specifications to TODO.md, which would be the first non-GUI DSL, made for writing better automated-testing specs than RSpec (which I think got diluted lately by many awful community ideas like switching to an imperative expect syntax that contradicts the original goals of RSpec's should syntax which I attended a talk for in Chicago when the project first started). To be honest though, I am not even sure if I need all the capabilities of Glimmer for this project. I might be able to build it without Glimmer. I'd have to start it out to find out.
I hope I answered your question. I am closing this issue for now. We could continue conversation while it is closed if needed.
What if we could use glimmer a bit like rack, as a base for other projects, BUT also as an
abstract toolkit for rails-based projects? Perhaps even have direct support for javascript
as-is via opal.
What I mean with this is ... if we think about rails, we work with widgets too, sort of - all
the HTML5/CSS things, and the dynamic parts via javascript or some javascript-framework.
Wouldn't it be cool to actually describe this just once, e. g. in the glimmer DSL but have
it work "internally"? I am not necessarily saying to be able to do what ALL of rails can
do, but more like ... a bootstrap stage for minimal rails-like things. Like a web shop!
Concerning Rails, perhaps Glimmer DSL for XML & HTML (glimmer-dsl-xml) could be leveraged on the server-side as a pure Ruby alternative to ERB. I definitely could see this improving productivity as one of the things I hate most about ERB is having to mix Ruby with HTML. With Glimmer DSL for XML, the problem is solved! You just write Ruby code for everything and the HTML part is a lot more concise and readable in Ruby anyways. I had this idea since 2007 to use Glimmer DSL for XML in Rails, but I never got around to executing it and now I think other competing projects already copied my idea and did it. Still, perhaps it would be valuable to offer as an option anyways since Glimmer often has unique productivity ideas and smart defaults/conventions not found in other projects.
Otherwise, Glimmer DSL for Opal already enables using Ruby code on the front-end in Rails.