If your question isn't answered here, feel free to reach out.

A Widget is a do-it-yourself web application (WebApp) intended for use by individual, families, or small groups. The central idea of the Widget philosophy is: It should be just as easy to build a WebApp as it is to write a web page.

Since they are very easy to develop, Widgets can be highly customized to suit individual user's interests, goals, and tastes. This philosophy stands in stark contrast to the economics of mainstream sofware, which depends on a building a product that is highly polished but generic so that it can be sold to large numbers of people.

Widgets can be used for a wide variety of applications relating to organization, productivity, fitness, diet, finances, and learning. As you build more widgets and get to understand how to use them effectively, you will naturally discover more and more potential use cases. I personally have built widgets for the following use cases:

  • Workout logging
  • Studying Chinese characters
  • TODO List management
  • Project management
  • Expense tracking
  • Junk Food / Alcohol logging
  • Chore Reminders
  • Private Question/Answer database
  • Link Management

All of the data for a Widget is stored in a SQLite file on the server. When the Widget loads, the data in the file is transformed into JavaScript objects and sent to the browser, along with the HTML and other assets (images, etc) that make up the page.

The JavaScript code running on the browser can then perform whatever computations are desired to format and display the data to the user. The Widget typically provides the user a variety of ways to manipulate the data and create new data (for example, in a training log, the user can log new workouts). These data updates are sent back to the server for long-term storage. The Widget framework provides a simple API for querying and updating the JS objects that correspond to SQLite records.

FAST, except for the initial page load, which might take half a second.

The lifecycle of a user interaction with a Widget consists of two steps: the initial page load, and subsequent updates, queries, or data input that is performed by the user. In the initial load phase, the server converts all of the data in the underlying SQLite file into JavaScript objects and sends it to the client. Thus, this phase can take a short but perceptible amount of time, depending on the amount of data in the DB file. However, after the initial page load, all updates and operations should be nearly instantaneous, because all of the data is present in the browser's memory, and the server updates are performed asynchronously.

For example, suppose you are using a TODO List Widget and you add a new task. This requires the page to be redisplayed to include the new task. The redisplay can be performed instantaneously, without waiting for a server response, because the browser already has all the data it needs to redraw the page. The actual update to the SQLite DB won't happen for perhaps half a second after the user makes a change, but this latency is invisible to the user.

Not currently. At the moment, WebWidgets is a personal service offered by the proprietor, Dan Burfoot.

I am thinking about turning it into a startup. If I get a large number of interested early users, I will do so.

YES. As of October, 2023, there is an open-core version of WebWidgets that you can install on your own machine(s). The backend Java code is now included in the GitHub repo. There is an installation script that guides you through the installation. Here is a YouTube video that walks through the installation process.

The open-core ("community") runs the basic Widget functionality. The full-featured WWIO system is enhanced with email-sending capability, blob storage so you can upload photos or audio, and the ability to export Widget data to Google Sheets.

The WebWidgets site uses industry-standard methods for encrypting messages between the browser and the service, and for authenticating users.

However, the SQLite files stored on the server, and backed up in AWS cloud storage, are not encrypted. Thus, you should not store highly confidential information in a Widget.

I think the current level of security to be sufficient for the main applications of Widgets, such as note-taking, fitness tracking, and so on. However, if there is strong demand from users, I am happy to implement increased security features.

YES, absolutely.

The service we provide makes it extremely easy to download the SQLite files that contain the Widget data. Not only do you have the data, but because you are the developer of the Widget, it will be easy for you to understand, access, and modify the data. You will know the exact schema of the DB, and you will know what each field of the DB means in terms of the Widget's functionality.

Widget data is stored in SQLite database files.

The use of SQLite is one of the core design factors of the Widget system. SQLite makes it so that every Widget user can design their own data structures. Furthermore, users can easily upload and download their data files, ensuring that members truly own their data.

YES, You can use any frontend framework that does not require any special backend support. This includes React.

Unfortunately we cannot allow people to run arbitrary framework code on our servers. The Widget framework is designed to create a clean separation between the backend code and the frontend. Users can do whatever they want on the front end - the code is running on the user's browser - but all Widgets connect to the same, simple backend.

At one point, I developed several Widgets using React. They worked fine, but eventually I decided React was too heavy for what I wanted to do.

The Rise-and-Fall (RNF) problem is one of the most serious challenges facing people who want to aggressively adapt to new technology. It is a well-known issue in technology companies, but it afflicts individuals as well. The RNF problem refers to the fact that new technologies are constantly coming and going - rising and falling - and this endless cycle often destroys the value of technology investment.

Imagine you are the CTO of a tech company that produces a popular mobile app. It is a constant struggle for you to make sure the Android and iPhone versions have the same functionality, and interact with your backend databases in the same way.

One day, a new technology appears that promises you the potential of writing both iOS and Android versions using the same codebase. Do you jump on board with the new tech?

These kinds of questions are very difficult to answer. The new framework may very well save you dozens of man-years of labor over the next five years... but only after you've invested almost as much effort in the first year, as a price to be paid to adopt the new framework. Furthermore, if the new framework fails, all of that effort will be wasted. More commonly, the framework thrives for a couple of years, and then a new one appears that grabs all the mindshare. This continual cycle of boom and bust causes the RNF problem.

The Web Widgets system is a new framework, that requires some investment to get started. But the design of the Widget system protects you from the RNF problem because it is built on core web standards such as HTML5 and JavaScript. These standards are built into every browser, as well as millions of web sites around the world. They are not going anywhere soon.

To answer this question, it's useful to ask a related question, which is "What makes mainstream WebApps so difficult to build?" Mainstream WebApps have to satisfy a lot of requirements:

-- They must display correctly for every browser (Chrome/Firefox/Edge), including older versions. But each browser version has a slightly different set of functionality and quirks, especially when it comes to JavaScript. This makes it extremely difficult to implement client-side functionality.

-- They must be built to be scalable, and handle extremely high loads. Even if the load isn't very high on a daily basis, every entrepreneur dreams that her business will suddenly go viral and start gaining users rapidly. For this reason, developers must spend great efforts designing the application backend.

-- They need to look very professional and "slick" for the sake of branding. That means the designers must spend a lot of time thinking about the app's color scheme and making sure every icon looks perfect.

As you can see, Widget developers don't need to worry about any of these issues. Since you are the main user of your Widget, you can make sure to use a browser that is new enough to handle the version of JavaScript you want to use. You don't need to worry about designing the backend. And you can make your Widgets as slick or as basic as you want, depending on your own taste in web design.

YES, basically. Widgets are WebApps that run in the browser, and all modern smartphones and tablets have browsers, so you can access the Widgets that way.

However, in my personal experience, it is somewhat tricky to get Widgets to display properly or nicely on multiple display formats of widely varying size. If I have a Widget that I developed to access on my laptop browser, I can certainly see it on my phone, and it will work correctly. But it is often more difficult to use, and I often have to zoom into a certain part of the display to see the information I want. It is probably possible to design pages that display well in both a laptop screen and on a phone, but that's a bit beyond my level of expertise with HTML and CSS.

YES, by all means! All of the Widgets in the Widget Gallery can be used or remixed for any purpose. I invite you to either copy my Widgets entirely, or make small changes to them to suite your use case.