[Question / Brainstorming subsection] Long term goals for glimmer "as a whole"? about glimmer HOT 2 CLOSED

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.

from glimmer.

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.

from glimmer.