I spent 5 years in the 90s creating a WYSIWYG tool with Visual Basic 6 , and VB6 was a life saver.
I think retool is a fantastic, modern-day re-incarnation of that.
However, I think when the UX is important -- that is, a rich, pixel-perfect design combined with robust facilities to define custom app logic, a principles-first approach has to be taken.
We've taken one stab at this, to say that logic should be defined in a spreadsheet specifically tailored for the app-building purpose, and I think only time will tell if this approach is right. [1]
100% Agreed! Defining logic in JS is quite clunky for these sorts of tools.
I'm biased[1], but for this reason we took the approach of creating a spreadsheet from scratch for the sole purpose of creating logic for apps (both internal tools & customer facing UX).
Would be curious to get the everyone's input on our spreadsheet-driven approach -- thoughts?
To op, for tools like Figma, what do you think the future holds? In what dimension will they evolve? How can they help you be more effective? Will they help you express your ideas in ever higher fidelity over time? [1]
[1] Biased questions, but genuinely curious about the op's answers given his deep expertise in the field (as the founder of https://mintdata.com)
We [1] used to think the same thing a few years back, but then figured out empirically that virtualization (above the React layer) will let you view/scroll through virtually unlimited-size datasets (until you hit the browser's memory limit per tab).
So, at this point, I would say canvas is not required to render large grids in modern browsers (even though Google Sheets does this for likely legacy reasons)
"I can't imagine how that would work"
-> hearing that kills me inside :(
I think we have 2 options:
OPTION 1)
We've reached a plateau -- software will continue to be developed as it is now, no new abstractions.
OPTION 2)
Mankind will create a better set of tools to:
- reduce the effort needed
- increase the # of people who can participate
in the translation of ideas/requirements -> software.
For everyone's sake [1], I really hope it's the second! :)
As one crazy idea, imagine if you could have a spreadsheet that would let you build software instead of crunch numbers...
... anyway, probably a bad idea, we should stick to our current abstractions and tools :D
[1] Take the above with 2.42 lbs of salt, I'm the founder of
I think dates, times, UTC offsets, and locales/cultures is a topic we frequently think of as "that's easy" [1] when in practice it's painstakingly hard to get right.
As an example, we've spent the past few days on our eng team refining our spreadsheet functions for date/time handling, and it's like the 5th time we've iterated on this (after supporting everything Excel / Google Sheets do).
Funny part is, I'm sure we'll iterate on it even more -- it's hard to get this topic both right & make it easy to use / approachable.
Btw, does anyone have good reading materials on this topic? (date/time/locale handling)
[1] I'm biased as a founder at https://mintdata.com, but thankfully our engineers set me straight on the subtleties :D
We’ve used this API in our https://mintdata.com/docs examples, but the limits run out fairly quickly.
Would be curious to ask here — are there any alternative APIs you’d recommend for showing financial application examples? (Ideally something that fetches the delayed price of a stock (CUSIP) and related news for it)
camp 1) at best, a TCP connection is re-used, and the HTML for "page 2" is fetched over the network, parsed, the CSS OM is applied, and then the whole caboodle* is "painted on screen".
camp 2) the CSS OM is applied and "page 2" is painted on-screen (possibly even faster if the browser cached "page 2" in a texture on the GPU, so the CSS OM application step may be optimized away)
So I genuinely don't understand how fetching a "page 2" from a CDN
(we use Cloudfront & GCP's CDN at https://mintdata.com, so I'm basing my experience on this)
is faster than the SPA approach?
I am genuinely curious on the above -- not trying to start a flame war :D
* Yes, apparently caboodle is a word?! I had to Google it just like you to make sure :)
I'll take a stab at this, Kyle just shoot me if I get something wrong below :D
1) There's a server-centric approach and a client-centric approach:
--a) hand-maintained HTML + php falls into the first camp
--b) React (/Angular/Vue) fall into the second
2) If you go with the second camp (b), you end up having a higher initial page load time (due to pulling in the whole "single page app" experience), but a great time transitioning to "other pages" (really just showing different DIVs in the DOM)
3) Gatsby does some very clever things under the hood, to make it so that you get all the benefits of the second camp, without virtually any downsides.
4) There are of course all kinds of clever code-splitting, routing & pre-loading things Gatsby does, but I hope I got the general gist right.
If not, Kyle, get the nerf gun out! -- how would you describe the Gatsby (& static sitegen) benefits? :)
Before the others come with torches, I’ll point out we turned on public/free access recently, would be happy to hear your thoughts/feedback on the MintData approach.
It lets you define your dashboard logic in a spreadsheet & then drag/drop the dashboard UI and publish it for end-user consumption.