No development in a long time; please give me ownership

[JonathanWilbur]

@jheising

It appears that development of Freeboard has been abandoned. I would like to take ownership of Freeboard. Would you kindly either:

1. Make me an owner of the project, so I can keep it going or
2. Merge all pull requests (after review, of course) and close out all relevant bugs (if needed, of course)?

I like the work you have done and I would like to keep it going, preferably under the same name.

[FynnMazurkiewicz]

@JonathanWilbur I am currently looking for a dashboard and freeboard looks great. But the recent development activity is scaring me off, especially because I also require #142 to be merged.
I saw that you merged a lot of the PRs in your own fork, am I good to use your fork as a remote for my local install?

I can't believe that great software used by Verizon and Ford is being abandoned like this. 😞

[JonathanWilbur]

@FynnMazurkiewicz , do not use my fork of it. Actually, I will delete it tonight. Basically, all I did was fork it, merged (almost) every outstanding pull request, and perform some very cursory testing in between each merge. After I merged everything, I found out the hard way that something screwed up the drag-and-drop. I could not quite figure it out.

Upon familiarizing myself with the source code further, I have decided not to take this on. There are very serious problems with the source code here. But there is good news: I am making my own from scratch. It is a lot more modern in that it uses TypeScript, Vue, and Vuex. I might even incorporate a router, too, but we'll see after I get the basics working. It is still in the works, and I am not even ready to publish a Git repo for it yet, but I do have a minimally working system of data sources and widgets now. I'll comment here with links to it when I've got it ready for you!

[FynnMazurkiewicz]

That would be amazing, don't forget about posting it here!

In case you care about an opinion on features, I would love:

• Clear cut between widgets and data source, with a typed abstraction layer that allows to map the same source cleanly to different widgets.
• Pretty default widgets for a plug-n-play experience.
• Typed plugin systems for both widgets and data source, with data source plugins being a lot more important. If you have a solid selection of widgets (like freeboard), there is no need to extend them.
• Theming support (Primary/Secondary colour combination in configuration would suffice)
• Grid layout through config file.

These are just my two cents and I am sure that you have a better vision for a better mousetrap.
Hoping to catch this on a Show HN.

[FynnMazurkiewicz]

@JonathanWilbur https://github.com/creativetimofficial/material-dashboard, in case you don't know yet.

[JonathanWilbur]

@FynnMazurkiewicz I wanted to follow up on this to give both of us some closure. I spent about two weeks working on an alternative, and I eventually gave up. I started the dashboard in VueJS, then added TypeScript compilation, then Vuex. After building the scaffolding for data sources (which my intuition tells me I could have done way better), I started to implement the arrangeable grid of tiles using a third party library, only to find that it was abysmal. I tried remaking it in TypeScript only to have a plethora of problems I don't have the patience to solve. So that marks the death of this project for me.

I did, however, commit both the dashboard project, which I called "Wildboard" (after my last name), and the grid library I wrote. For whatever reason you might want to see them, here they are:

• https://github.com/JonathanWilbur/wildboard
• https://github.com/JonathanWilbur/vue-grid

I can also tell you from experience what you should do if you want to make something like this on your own: Use Angular. I found from experience that, as I implemented TypeScript, state management, and a build system, Wildboard increasingly approximated the Angular setup--except not enjoyable or efficient at all, unlike what Google designed. Further, there are standardized widgets--Material Components--that Google has already made, and which are top-notch in terms of testing, portability, and user experience. I used to be a VueJS fan-boy, mostly because I missed the old AngularJS experience, but knowing what I know now, using Angular would be a no-brainer. Also, make it a Docker-Compose app!

On a final note, I would like to make another point about the whole dashboard thing: I think there are better ways of doing dashboards. After using Metabase and the ELK stack, I believe a much better way of doing it is to have a dashboard that only serves as a front-end for a single database, and all of your data sources should dump their results into the database, instead of being requested client-side, which innately has extreme limits. If you implement something like the ELK-stack architecture, you could pull in data from way more sources than just HTTP requests, since server-side technology is not as limited as client-side. Your data sources could include files on a file system, entries in an LDAP directory, Kerberos tickets, mail messages in a mailbox, calls coming into a support center, etc. It also means that the client-side state can be persisted in the database rather than the browser. So in summary, I think projects like this--while they are a cool demo of what you can do with just a client-side web app--are not really worth any serious investment of time and effort. I highly encourage you to consider either using Kafka + MySQL + SuperSet or Elasticsearch + LogStash + Kibana (ELK).

However, if you take up this torch, I'd be interested in following it!

• Jonathan M. Wilbur

[FynnMazurkiewicz]

Hey Jonathan,

a lot of people would have silently let this die, so thank you for the update.
I figured that this is quite an ambitious task for a solo mission, but thankfully you at least got to to take some programming learnings from it.

I've been actually using Angular professionally for multiple projects, so I absolutely agree with your opinions on it providing a great basis for larger and complex projects. The strong Angular/npm ecosystem is also a big plus. I've not yet gotten around to composing my own containers, usually other people in the dev-ops process package my code.

I never actually mentioned it, but I got my dashbaord usecase working well in the end, with a different setup. I also ditched the client-side data polling, absolutely agree that a dashboard should really only be an organized view on data. But since I just needed a small set of specific features, I still didn't want to go trough the hassle of building from scratch.

In case you are interested: I build a dashboard, that shows 2D graphs on the history of my personal habits (working out, reading, sleep, cooking...). I now have a small widget on my Android home screen per habit, where I can either hit '+' if I did that habit well or '-' if I cheated (ate unhealthily etc). The widget data is stored to a web server on the internet and can be read from different frontends. I've connected the dashboard to a smart plug and Alexa to turn it on and off.

Stack:

Android client & database:
Using open-source project Habitica for all habit tracking and generating a habit value to rate progess on a per-habit basis. This is very lazy, but works well and they've got good developer APIs.

Dashboard:
I used https://smashing.github.io/ and build my own dashboard plugins in Ruby (nice language, never used it, unfamiliar syntax) to integrate data from Habitica. There were minor issues in the core (or the way I used it) which also needed some patching.

Hardware:
Bought a cheap 11" LCD from China, powered with an Raspberry Pi as a server and connected to Alexa with TP-Link smart plug.

Best of luck with your future ideas! 😊.