I'm all for new features, but I would also like to bring light to the fact a big majority of Hype users are building ads (for which the runtime size is crucial).
So I hope that if more advanced features such as above are added, that it would be possible to toggle between different runtimes with the export (beyond the min and full that we have), in order to not bloat every export with features that specific creative don't need.
They do that already, like with Physics. So, I imagine that could continue.
Yet, something like this could be expanded to add a new feature to manage ads. This template is close…
It's storing the different languages in one multidimensional array. That's a bit of a problem for advertisers, that require lightweight exports. Yet, imagine how this could work in an improved Hype…
I'm not sure if there's a huge demand for a feature like that, but the multilingual project is one of the more popular templates.
Also, with Hype 5, IE support is supposed to be dropped, that should save some space in the runtime. I'm not saying that saved space should be replaced with bloat, but I think it's possible to modify Hype for lightweight work and feature intensive projects.
Ideally, the runtime would be so streamlined that it would only include features that are needed. Like if I don't use filters, fonts, drag events, then the runtime could be generated dynamically — for even more lightweight projects. The runtime is huge though, so I don't know if Tumult is considering such an intensive project.
Actually at the place I work at there's a huge demand for this. Since all client's I service on display/video level are global brands that seek creative scaling for multi market campaigns (1k-3k creatives per campaign).
Currently, I'm using @MaxZieb's DataMagic extension in combination with our internally developed tooling to find & replace content from variables stored in the in the Hype exports with our feed data at a massive scale. Connecting it to our data sheets we're generating unique zip packages by replacing variables from the feed per row into a unique zipped creative, by injecting the variables in the head into the Hype layers with DataMagic.
It would be much appreciated if this became a native feature within Hype to easily connect to custom data sources.
Thanks for both of your thoughts!
In regards to data-driven animations and content, this is something we've been wanting to do for a looooong time. The first feedback from a user on this comes from a day after Hype 1.0's launch. It is both a huge opportunity to redefine how animations are made, though the mechanisms and potentially business side hasn't congealed beyond a vague form for putting it in a previous release. It was great to see Hype Data Magic's approach at it, and I'm definitely encourage that you're able to make use of it.
As for SQLite in the browser, I've been following that project a bit as I'm generally a huge fan of SQLite. I think the notion of "binding" is agnostic to what it is binding from. SQLite's strength is that it is queryable via SQL itself. Being heavily programming oriented as such, I'm not sure where it fits for being built into Hype vs just something developers using Hype should bring along for their needs (and Hype continues to have good APIs for them to leverage in conjunction with the data). I'd also say a general issue with SQLite in the browser is that for data small enough to download, you usually don't have heavy query needs. For a database that is big enough, you'd do a connection to a remote server to get the fractional bits of data you need on demand. One parallel though is Apple's Core Data. There's probably some middleground that makes sense. It does seem though like you're also bringing up using a database at export time. This is pretty interesting too, and solves some issues on sizing.
I also would make data magic or reactive content more native if there where a proper interface API to map the actions UI to extension and an event system for the web view of the editor for implementing more stable previews.
Even when I was doing the programming myself, in a Swift / WKWebView setup, I still used another application to manage the SQLite data. Why couldn't Hype do that?
…and isn't that the point of Hype? “No coding required.”
If you need an offline database to power your project, where do you go? How would a designer do something like that?
I think that's a big place to focus with Hype 5… like with Physics …I could program my own collision detection, but you're losing so many people that can't… like with game controls… I could code my own inputs, perhaps even add controller support… but Hype is losing the aspiring game developers that can't.
Progressive Web Apps haven't taken off yet. But if you think this is going to be a big thing, and even Apple is improving PWA support with Safari, Hype could be a leader in the space… managing data, simplifying PWA creation, improved game development with offline database support, kiosks …there are common problems I've seen on the forums, so how many other people are having the same trouble but don't even know about Hype?
Personally, I would prefer to do this in vanilla Javascript, no WASM or SQLite, but I don't know how to get back the memory.
As an example, what if I was building a simple word game? So, I load an array of valid words. The word is checked, then what? Even if I knew how to release that data from the browser, it's still going to need it again a few seconds later with the next word. The whole dictionary is loaded into memory.
That was a big problem with “Widgets”. Even with just a few widgets using big arrays, it was using a lot of memory, but the problem was solved with SQLite. The app ran more efficiently. (Although, I don't know if this technique would be as effective in PWA setup.)
The main idea is about offline data. Running a web server so that thousands or even millions of players can check if a word is valid… whew …not ideal.
I was thinking it was dozens, but thousands?!
I imagine the automation would need to be pretty advanced, as it's not just languages if the number is in the thousands. But, I suppose even two features could be added to improve Hype… export project per row (replacing text / html) in elements assigned column data… and export per scene.
So, for every database row there could be an export, and for every scene there could be an export. Now combine both and they multiply… creating so many different exports.
Offline databases and database driven exporting are two wildly different features, but it does highlight the main point… Hype would be more powerful with database support.
I personally love TablePlus - I'm not sure of use cases where Hype's HTML5 view of the world would lead to a different feature set, and therefore there doesn't seem to be a need to replace it?
I think if your needs are so sophisticated that you need to include SQLite, they have likely gone beyond no code solutions.
We can definitely provide some amount of mapping infrastructure (this is more useful for simpler data sources like JSON). As a user of cocoa bindings I can tell you that use cases fall over really quick. This is why there are not cocoa bindings in UIKit - Apple considered their own system to bind data to UI (without code) as a failure.
Basically if you need code, then there's probably going to be tons of great code related resources for package management already out there than have folks try to learn a new and alternate system.
You can also give Hype Data Parser a try… it supports multi-table number files. If you make the CSV export local in your Hype project, you can use it as long as fetch is allowed (meaning in Preview and when deployed to a server, but not on file://).
The workflow involves loading data from the CSV and displaying it in your Hype project using your own solution, Hype Reactive Content, or Hype Data Magic. Now, the client can simply update the tables in Numbers, re-export them, and upload the CSV to the project (via FTP) or use any other online table solution that can be queried via CSV. Update complete.
That said, there are solutions like Airtable, etc., that have a JSON interface, so you don't even need a CSV intermediate step. I mainly created the solution for clients who wanted no dependencies like that (or are offline) and keep sending me their data in Excel spreadsheets.
Here is another approach using SQLite in the browser:
I think that's the point, is it really so complicated?
Let's look at one of the primary weaknesses of Hype. It's supposed to be a no-code solution, but there's no graphical interface for working with variables. The closest is Data Attributes, but you can't do anything with that data without additional JavaScript.
Wouldn't Hype be more powerful if variables could be created and managed in Hype? Imagine if that could be done from the “Action” pane… read data, write data, work with data (math / strings) …to even do 2+2, that's JavaScript coding.
So, take that to the next logical step. If you can create variables, then arrays are the next level… specifically spreadsheet-like multidimensional arrays.
What is it that I'm doing with these arrays? Searching for a specific row, then use that data in the related element. This can be done graphically. Drupal Views is an example — so powerful with little to no coding.
On WordPress, I use TablePress. Could I create the tables manually? I have… https://photics.com/data/the-legend-of-zelda-overworld-map-as-emoji/ …but that interface on the admin side is so nice. Here's an example… Crossy Road Characters List – Photics.com …the generated tables can be searched and sorted.
That plugin has over 700,000 installs!
I think that's the ultimate idea for Hype 5 — break free of that old Apple tech. Hype should be cross-platform. While I've seen some complaints about Electron, I think Visual Studio Code is amazing.
Even with Swift / Swift UI, I found myself wondering why this wasn't being done with JavaScript / HTML / CSS.
I think I've mentioned it before, but Tumult should be throwing money your way. Have them incorporate your most advanced stuff into Hype, but give it that Apple charm so that's it's more inviting to beginners.
You're fighting the limitations of what Hype can do, while Tumult is stuck with what could be done in Mac-Land. That's a lot of work doing things the hard way. Hype could be redesigned to be more powerful and easier to work with… for everybody… Tumult, third-party plugins, and regular users of the software.
But basically, I haven't quite figured out which technology I'll be using. Even if it's not IndexedDB, it's probably a good idea to understand how that works. The only reason I'm even considering SQLite is because of the size of the databases.
I figure that if Tumult added offline database / spreadsheets / JSON / support to Hype, that's the logical problem. What happens if it's thousands, tens of thousands, or even hundreds of thousands of rows? So, if such a feature is added to Hype, it should be scalable.
It's not necessarily about adding SQLite to Hype. That's just one of the technologies considered while thinking about this problem. Offline and no dependencies has been the idea… and I can do that technically, but I'm working on doing it in a way that is more efficient.
It's a nice puzzle to solve, and I'll probably figure it out eventually, but I also see how this relates to the future of Hype. What if something like JSON was a native feature in Hype? WOW! 
Funny enough I have been playing with wix websites of late..
The interface for elements has a bit where you can link special elements like galleries etc to a cms/db. With a simple selection panel using multiple drop down menus for selection to manage the mapping between the elements components and the cms fields.
The cms/db can be a local one to wix or an external linked one.
This works really well.
Would I like this in hype. Simple answer is yes.
I do this type of mapping in hype with javascript all the time.
So if hype had a simple db mapping feature like this, I would use it.
It would require hype to be able to read a db of most common structures I think, either import them or request them to memory or do both
Or written into a hype function
JSON
Csv
Both would need to be strict.
This combined with also being able to use a db in hype for export mapping, could possibly work much better in then the current advanced export.
On GitHub it was said, “This can help with reducing bodies passing through each other in many cases.” The word “Help” does suggest it's not a definitive fix to this problem, but the demo shows a dramatic improvement…
https://brm.io/matter-js/demo/#substep
I filled it with lots of tiny bodies and they rarely went through the stick. When I thought that one of the bodies did go through the stick, I had trouble seeing it happen again to confirm it was actually happening — but even AAA video games have trouble with perfect collision detection.
Just see the Backwards Long Jump in Mario 64. 
It seems to help A LOT! 
Just look at the current state of Hype…
Stick-Test.zip (10.9 KB)
The square goes right through the stick with just some basic gravity.
