I'd recommend MintData (https://mintdata.com)

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

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?

[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/

Great post!

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)

Design + Code tooling.

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

Agreed on the democratization front!

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...

What's a "non-artistic developer"?

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.

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)

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

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

We use "nested spreadsheets" that can live in any cell, and combined with aggregate functions like GROUP_BY() we're able to get this behavior.

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

https://mintdata.com

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)

So, for (2) above, not sure I understand:

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

Interesting, what were the challenges you faced with MDX?

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?

Kyle,

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

Thank you!

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.

The issue is that FBP (flow based programming) scales to a certain point of complexity.

After that, it stops being more effective than a textual representation or (gasp!) even old fashioned imperative programming.

As a result, we need new approaches for more powerful tooling that scales better along the axis of complexity (for the idea / thing we want to create)

This is exactly what we built at MintData. [1]

A new way to construct software by using a spreadsheet to define application logic, instead of today’s spreadsheets which breed chaos.

“A canvas of composition” - I really like that phrase to describe this approach of re-mixable software creation and usage.

—-

[1] I’d add a link here, but I think folks below might be sharpening their pitchforks by now :D

I think of this in two parts:

1) Computing is cheap, human time is not.

2) Competition in established industries is fierce (finance, real estate, education, construction, etc)

-- To the extent possible, I'd:

a) time out bad queries

b) add more hardware where feasible

-- For the "wiping out data" part, I think:

1) Mark things as "removed", delete when {GDPR,CCPA,etc} requires it

2) The UIs designed can/should have human processes in mind -- that is, things like multiple people involved (async) on what to do with a piece of data (flag it, mark it removed, send it for approval, etc) -- what a lot of companies are calling "workflows" and "workflow management platforms" these days.

3) Backup/restore should be used only as a last resort (DR and the like)

4) Versioning like Google Sheets of the UI is paramount and integration with CI/CD systems is crucial to having the cake (allowing people to create the tools they want) while also eating it too (making sure IT doesn't drive the above-mentioned dune buggy off a cliff in protest)

Thank you! Genuinely warms my heart to hear it :)

We've been using our own "Visual SDK" to build large parts of MintData for the past few years.

It's 100% written in TypeScript/React, using decorators (cough: annotations!) and allows us to:

1) add new spreadsheet functions in TypeScript

2) wrap any React component

3) we get the auto-magic property panel UI "for free" & it instantly talks to/from the spreadsheet

For our cloud/backend imperative layer:

4) we use our own real-time stream processor (think: Apache Storm but minus the Clojure stacktraces)

5) the SDK lets us quickly write flow blocks in Java using annotations & connect to all sorts of enterprise-y systems (SQL/NoSQL stores, Queues, File Systems, etc)

@slifin -- in terms of engineers writing & selling those layers, we're open to it -- ping me if you have ideas & we can give you access to the docs & SDK.

--

[1] I'd put a link here, but the flamethrowers have come out on this thread :)

Point taken :)

Is it ok to shill Roosevelt?

[1] https://youtu.be/Mm4epcGApnY?t=14

200% agreed.

I learned to develop software [1] before the interwebs, where we would just kind-of hack things together in C/Unix. Manuals were our only (& best!) friend.

I then went to uni for a CS degree, and they had a very "holy grail" attitude about the whole affair.

I agree that:

1) an apprentice system would work better 2) we have got to get more powerful tooling out there, into people's hands

--

[1] founder of https://mintdata.com here, which makes me biased on the above

[2] I'm still reminded of a world where the bridge between creating & using software was much smaller (not to mention, user interfaces were much snappier!) Here's a virtual toast to hoping we can one day come back to that reality.

I'll give you an example that mid-way [1] disproves the above.

Think of a typical "product tour" in a SaaS product. We're building the MintData product tour, in MintData itself. We then "publish" this "product tour application", and include it with the original blank design that a user gets when they first enter MintData.

So, in a way, our MintData onboarding is built in/on MintData itself, a bit like how you can have a bootstrapping compiler (one that compiles itself).

So, is the above us "modifying the original system"?

I think to some extent yes, although we have special spreadsheet functions that help jump the gap between Onboarding Application and Blank User Design (akin to the Postgres extensions [2] above).

So I think it is possible to build a system that allows you to then customize the system's own behavior (earlier versions of MintData could not build the onboarding experience, similarly to how the first compiler has to be built in a lower level language).

Genuinely curious -- derefr, do you agree or disagree with the above?

--

[1] Chief abstraction wrangler at https://mintdata.com, so YMMV on the above.

[2] As a person who was held at Grade-point and forced to write PostgreSQL C code to "modify the original [Postgres] system", I can only say it's an acquired taste :) Even Prof Franklin at UC Berkeley I think would back me up on this :D :D

(!) This!

First, big props for shipping stuff that people use.

Second, I've [1] often compared 90% of what we do in software development to being highly trained baristas. Granted, this buys me little love from engineers & even less from Starbucks.

To the point -- I think it's time we rise up & start to use more powerful tooling.

Tooling that:

1) Lowers the barrier for who can author software (really, web-based interfaces that help us get stuff done, the way we want to accomplish a task)

2) Doesn't introduce more chaos (disparate data spread across 10 SaaS products, death by 1,000 spreadsheets by email or in Google drive, no centralized/secure/managed storage, etc)

3) Emphasizes that a superb user experience is table stakes for such tooling.

Thoughts?

--

[1] founder of https://mintdata.com here, so just a tad biased, take the above with a few pounds/kilograms of salt.

[2] oblib -- DM me, we're happy to give you free access if you'd like -- the above wording just warms our collective hearts.

Whoa! What do you have against hillbillies? :)

Jokes aside, imagine if Annie in accounting has the ability to define her own malleable tools, on top of a solid/robust system for centrally managing data? (version, backup, secure via IAM, etc)

Or will we really be stuck writing procedural code for the next 20, 30, 50 years?

--

[1] Caveat: chief hillbilly of https://mintdata.com here, where we think you really can have your cake (create expressive tools) and eat it too (centrally control, manage, and version your data) .

Here's a counter argument:

In college (17 years ago) a professor once told me that databases largely outlive the apps that use them.

Imagine a world [1] where IT manages data centrally, but users are free to interact with it how they best see fit?

Would this kind of a world be better?

(provided of course you have the right permission model & audit trail for modification)

--

[1] Founder of https://mintdata.com, so I'm biased -- malleable systems are near and dear to our heart

[2] Professor Franklin at UC Berkeley, if you're reading this, I am very sorry for not being the most attentive student :)

Very cool! I'll show this to our team [1]; we have a few keyboard ninjas & I think they'll absolutely love it.

--

[1] team of https://mintdata.com, where we've been known to appreciate a fine keyboard shortcut or 12.

[2] partly an inside joke to our team who reads HN, since we recently shipped keyboard shortcuts for our top menu (Google Sheets, we borrowed what we could to ease the pain :D )