It lets you define your dashboard logic in a spreadsheet & then drag/drop the dashboard UI and publish it for end-user consumption.

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]

[1] Take with a grain of salt, I'm the founder of

https://mintdata.com

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?

[1] I'm biased, because I'm the founder of: https://mintdata.com

[2] But this example shows what I mean by the "a spreadsheet is better to define logic than JS" approach:

https://mintdata.com/showcase/photo-finder/

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)

Hard problem:

How do we evolve design tools? Can Sketch/Figma be evolved to create full featured software? [1]

Something with no limits, and the freedom to create any feature developers create today with React/Angular/Vue.

Is it possible or a pipe dream?

[1] https://mintdata.com

Where's the Visual Basic 6 of our era? :)

Sure, apps weren't pretty, but you could bang one out in a few days and start getting use from it.

That's why I've devoted my career to tooling, hoping to improve the situation [1]

[1] {cough, cough} https://mintdata.com is where we put our blood, sweat 'n tears as a result :)

We saw this OpenAI demo: https://player.vimeo.com/video/427943452

and were just blown away. Very cool!!

I guess a spreadsheet is never too old [1] to learn new tricks :)

[1] Founder of https://mintdata.com here, so a bit biased (& opinionated about) spreadsheets, take the above with a pound or 10 of salt.

[2] I've sent them this example how we'd invoke their APIs, hopefully they'll let us into the beta, fingers crossed :) https://mintdata.com/docs/learn/core-mechanics/work-with-dat...

I think:

1) Design is like a muscle, you can always develop it

2) Digital experiences [1] are all around us! And they play a more pivotal role in our lives as time goes on.

So, hit the gym (practice) & with time everyone can improve.

[1] As the https://mintdata.com founder here, I'm highly biased -- I'm not a designer but certainly aspire to improve along this dimension.

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)

[1] You can see how we render large grids at

https://mintdata.com/docs in the example sections.

Would be genuinely curious -- would our approach [1] help w/what you're working on?

[1] Here's an example of how we think about multiple dimensions in spreadsheets (videos + text): https://mintdata.com/docs/learn/core-mechanics/work-with-dat...

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

https://mintdata.com

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

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 :)

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? :)

We built https://mintdata.com/docs on it, and it's been proverbially better than sliced bread -- that is, a true joy to work with MDX.

What're the challenges/pitfalls you faced with MDX + Gatsby?

Just read the post, congrats on the launch!

We've been using Gatsby on:

https://mintdata.com

for the past few years, and are huge fans of your work.

I still recall the day when I brought Gatsby into our org, our front-end guys almost ate me alive :D

They said: a React.render(...) + GraphQL thing, why do we need it? What's the big deal?

Fast forward a few years later, and Gatsby dominates (in my opinion) the best way to build a static website based on React.

Keep up the awesome work!

Your true fan, Denis

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.