Minor usability nitpicks

[mperham]

• Can you provide a GemName::VERSION constant in each gem so runtime code can easily log and determine which version is running?
• This is a little more of a stretch but is there any chance you can reduce the number of runtime dependencies? This gem includes a bunch of utility gems which transitively pull in about 25 gems. Here's the dependency chart from bundle graph:

[AndyObtiva]

Thank you for raising these requirements/concerns.

Can you provide a GemName::VERSION constant in each gem so runtime code can easily log and determine which version is running?

This is already provided.

Any application generated with Glimmer DSL for LibUI standard Application Scaffolding would get a VERSION constant as per the code below (from https://github.com/AndyObtiva/glimmer_snake):

class GlimmerSnake
  include Glimmer

  APP_ROOT = File.expand_path('../..', __FILE__)
  VERSION = File.read(File.join(APP_ROOT, 'VERSION'))
  LICENSE = File.read(File.join(APP_ROOT, 'LICENSE.txt'))
end

After you started your Kuiq project, I was going to replace everything with a standard Glimmer Application Scaffolding, which would have automatically included executable scripts and provided a command to generate gemspec from Gemfile automatically, among other things. But, then I noticed you manually added many of things that Application Scaffolding gives you, so I left the code alone.

This is a little more of a stretch but is there any chance you can reduce the number of runtime dependencies? This gem includes a bunch of utility gems which transitively pull in about 25 gems. Here's the dependency chart from bundle graph:

I don't see a practical benefit in reducing gems in the age of terrabyte hard-drives, tens-of-gigabytes of RAM, and 10+ core CPUs. I think Software Engineers should be encouraged to use as many gems as needed to avoid re-inventing the wheel, and the more the merrier.

I am closing this. If I missed some points you made or didn't full comprehend your concerns, please feel free to reply to this issue while closed, and I could re-open if needed in the future.

[mperham]

Well, gem dependencies all add up in terms of startup cost and they do add some amount of memory usage, cognitive complexity and maintenance burden. People who want to vet a codebase have to vet all dependencies too. Downstream users have to understand how each dependency works and keep it current. This is a maintenance nightmare for a system like NPM where JS apps have thousands of tiny dependencies.

I wrote this about Rails 5.0 and its "fat" dependency tree requiring ~60 gems:

https://www.mikeperham.com/2016/02/09/kill-your-dependencies/

Obviously your code, your project but if you can remove rake-tui, that would drop 10 gems on its own.

Here's the memory breakdown of the current bundle:

> bundle exec derailed bundle:objects

allocated memory by gem
-----------------------------------
   4432741  libui-0.1.2.pre-arm64-darwin
   3213118  super_module-1.4.1
   2626187  fiddle
   2512970  glimmer-dsl-libui-0.11.4
   1244886  method_source-1.0.0
   1186004  uri
    875587  psych
    819267  color-1.8
    789176  csv
    662860  perfect-shape-1.0.8
    621796  glimmer-2.7.3
    504642  redis-client-0.18.0
[snip]

[AndyObtiva]

Thanks for sharing that article. I appreciate reading technical articles, so I will read it when I get a chance.

One thing to keep in mind is several of those gems, including rake-tui, are development-only dependencies that are useful when using glimmer inside a scaffolded application. But, once a glimmer-dsl-libui app is launched, many of those gems are not loaded as far as I know. They are loaded on a per-need basis. So, I don't think the cost is as serious as it seems. In fact, the allocated memory breakup you shared confirms this. The development-only gems are not loaded into memory.

Also, one of the principles of the project is to avoid premature optimization, which plagues many libraries online that end up reducing the development experience into that of programming in the 80's because they still assume we have kilobytes of memory when in fact we have a lot of unused tens of gigabytes of RAM and even bigger hard drive space, and devs are forcing themselves to work a lot harder than necessary with those fictional constraints as a result.

That said, if real practical problems are encountered as a result of this, I'd be happy to work on solutions, including consideration of separating gems that are unnecessary from the main project gem. But, until then, this feels like splitting hair given our modern computer systems. I have built many many projects with Glimmer libraries (e.g. Are We There Yet? Project Management App, Math Bowling 2 Game, DCR Programming Language for Kids), and have not practically encountered any dependency hells from the use of many gems. In fact, desktop apps usually have a fraction of the number of gems in Rails web apps, so they are a lot more manageable in my experience. But, I am willing to keep an open mind if I hear of a real practical problem relating to this that can only be solved by eliminating gems.