Interesting! Does the backend serve 'standalone' web content to the browser to render or is there generic SPA UI that adapts to the messages sent by the backend? So does the todo.id ever leave the backend? Because if it does I feel like your sample is quite vulnerable to SQL injections 🙂. I do agree that server side rendered web pages get rid of quite a bit of complexity, but I do wonder what's the added value in skymass over existing server side web UI frameworks like ASP.NET Razor Pages?

Thanks for checking it out!

The code runs entirely on your server. I’ll add a comment to call that out.

The way it works is the backend specifies high level widgets + params (eg: table + data) that are mapped to an implementation in the UI.

What’s different:

• It comes with a growing, high quality UI component library out of the box vs writing html+css.
• it comes with auth (ready), localization (wip), themes (wip). the goal is to offer everything a complete app needs over time.
• the server doesn’t expose any http ports. it opens a websocket out to the UI server. this has of security/ops benefits.

Okay, so maybe something similar to Blazor Server (which I'm using atm btw). Basically everything is run on server and it just sends the DOM deltas to the browser which runs a bit of javascript to apply the deltas. It also has component libraries and supports basically all ASP.NET features. Not meaning to talk down what you've built, but might be worthwhile to check it out and think about how to differentiate if you're planning to productize Skymass :)

No worries! I definitely welcome the feedback and it’s great to hear about alternatives (N > 1 is usually a good thing). Blazor is definitely closer 🙂 The diff is that Blazor (and Liveview) operate at the DOM level (sending DOM deltas). I think that leads to a very chatty protocol. SkyMass components try to handle as much as possible on the client and only interact with the backend for significant events (eg: table selection was changed or a button was clicked).

The other part is philosophical — SkyMass is aiming to reduce the boilerplate/config/integrations etc.. to get a complete/good app up and running to a minimum. I think there is a class of apps where you just need to get something done — and all the other stuff is creating friction that prevents people from making progress or honestly starting— eg: I find registering and setting up OAuth providers and callback endpoints etc… for a new app cumbersome. I just want to write a login protected public app with minimal effort.

not sure if others are seeing this issue, but pldb.com doesn't load for me due to a security issue (neither Chrome nor FF w/ https everywhere) -- certificate problem?

Oh wow, thanks for reporting Arvind!

@Arvind Thyagarajan I reopened this issue:

github.com/breck7/pldb/issues/47

Could you share your details there?

Someone may need to do something to take care of it.

I was surprised to find TopShell there! How do you compute the number of users?

Great question @Joakim Ahnfelt-Rønne! I just updated all the pages so that should be more obvious:

IE, pldb.com/languages/topshell.html

But the specific answer for jobs is: "poorly"

Gotta get that improved

Thanks 🙂 I think it's great to have a database spanning so many programming languages!

I love the idea of shared variables that I can remix into my own code. I have played around with a similar concept in the past — one thing I struggled with was versioning. If my var is used by others and I changed it, what happens?

Great question! I have rudimentary versions in the product already but no real way to access them. The plan is to encourage people to refer to pinned versions @stevekrouse.foo_v7 but also allow latest access as well stevekrouse.foo

if you control the IDE, you could render the val mentions specially. perhaps highlight them if there is a new version available. and/or a drop down that lists other versions. bonus points if it lets me run my code with those versions before picking one.

Exactly, great ideas!

Duh - just noticed you already dealt with versions in the docs 🙂

This looks exciting Steve Krouse! Some cool features in there, and I like the approach of “vals” as first class citizen. The collaboration modal is a bit similar to what I’m trying to do with TypeCell. Keep up the good work!

Typecell is cool too!

this looks so cool—do you have any public work about how you're analyzing the design systems to do the live bidirectional code editing or is that all secret sauce?

Thanks Garth 🙂

Editing that's both live and bidirectional is indeed the at the very core of our secret sauce, haha 😂 Will likely do a blog post on the core tech at a later time once we've gotten our footing in the market (competition is beyond intense in this space!). Will also share it here in that case.

What I can share is this:

• We're intentionally editing and executing TypeScript since that allows us to tap into existing code bases and ecosystems, including open source. We want teams to just be able to have designers jump into existing code bases.
• Relatedly, we didn't invent a new programming language, which means that the work done by the TypeScript team in their language service and compiler APIs is available for us to build on
• We're able to use two-way Git since any code reads/edits we do eventually end up as the same text files that your IDE manipulates today.

Off-topic: can y'all see a comment by me 10 hours ago on this thread? I just noticed it looks grey..

Kartik Agaram Nope, I'm seeing Garth's reply as the first comment.

Here it is again, some overlap with Garth's comment:

The 2-way sync is great 👍 How much information do you need to provide Henosia with about a new design system for it to make minimal changes?

(I'm not a designer or Javascript developer, so I have no idea what form design systems are provided in. Is it just React components in jsx or something like that?)

Kartik Agaram

Not much info needed. Beyond a bit of initial config to make component previews work on the canvas, we use the TypeScript source code to drive the editing you saw in the video. Specifically, we use the type information that TypeScript React components define as their props, e.g. a button will have its props defined as something like:

interface ButtonProps {

  label: string;

  size: 'small' | 'medium' | 'large'

}

We turn that information into the properties panel on the right, e.g. a size drop down with the three possible size values.

React components are found by scanning the code base that's open in the editor, and we also identify components that are available through your package.json dependencies. For example, you can have your product code base open, and insert a button from your design system library that's in a linked NPM package.