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.