ttd

Preview of an upcoming feature - adding interactivity to your diagrams. This may be of interest to those who do a lot of architecture-level design and presentation, since many times you'll want something high-level with details hidden unless they're relevant for the audience or discussion.

Thank you for checking it out! What sort of text auto-magic are you looking for?

Interesting - do you have a writeup or a demo available somewhere? What types of junctions were you envisioning?

Thank you for sharing this perspective! Your proposal is potentially a good middle ground, and I will certainly give this some thought.

Thanks! I would say no. Mermaid is strongly code-first diagramming, which is an excellent usecase and niche in its own right. I would be surprised if Mermaid ended up with a WYSIWYG editor on top of it, since that is pretty counter to its philosophy (as far as I understand anyway).

Thanks for this feedback! This is one of those quality-of-life features that I think are really important for the overall experience - I will be adding this.

Some type of programmatic diagram creation is definitely something I'm interested in supporting. It's not clear to me how large the audience would be, so it's been hard to prioritize.

Thank you for the feedback! This is a great idea and definitely fits into the vision.

Do you know if the FPGA and/or hardware communities use any type of formalism for design or documentation of state machines? One example of what I mean is is Harel statecharts - essentially a formalized type of nested state diagram.

Would love to hear those frustrations and reservations - drop me a line if you're interested in sharing: tyler@vexlio.com.

Awesome, thank you! If you or your colleagues have other LaTeX-related goals or wishes, do let me know. There's a lot of untapped opportunity there as well (IMHO).

Definitely seems to be the case from my observation as well. Appreciate it!

Cheers, thank you!

Whoops - FAQ issue should be fixed if you refresh (if it's still broken, give it some time for caches to be invalidated). Thanks for mentioning that!

Re: desktop version. The short answer is yes, probably, but I don't have a concrete timeline. I made tech and architecture choices from the beginning to make sure a cross-platform desktop version always remains possible. Frankly, the biggest obstacle for desktop is not the app itself, but distribution and figuring out a pricing model. The current solution for enterprise, business, and other interested people, is to self-host Vexlio, with separate licensing.

Thank you! If you end up having any feedback, definitely feel free to drop it here, or email if you prefer.

I'm working on a new app for creating technical diagrams - https://vexlio.com. It's an area with some heavyweight incumbents (e.g. Visio, Lucid) but I think there's good opportunity here to differentiate in simplicity and overall experience. I'm still in the fairly early phase, and I suspect I haven't quite found the best match of features to customers yet.

From a dev perspective this area has a ton of super interesting algorithmic / math / data structure applications, and computational geometry has always been special to me. It's a lot of fun to work on.

If anyone here is interested in this as a user, I'd love for any feedback or comments, here or you can email me directly: tyler@vexlio.com.

Some pages the HN crowd might be interested in:

* https://vexlio.com/blog/making-diagrams-with-syntax-highligh... * https://vexlio.com/solutions/state-diagram-maker/ * https://vexlio.com/blog/speed-up-your-overleaf-workflow-fast...

Part of my curiosity was sparked by the article on HN the other day discussing the hamburger menu icon: it used to be confusing, but now is pretty widely recognized as long as some guidelines are followed. So while I used to agree with you re: usability, these days I'm not so sure anymore.

One idle thought I had: when computer interfaces were still new, using physical analogies like file cabinets was good practice for teaching new users. Maybe GUIs are now commonplace enough that people are able to speak the different "languages" without as much trouble.

I appreciate the simplicity! How did you arrive at your one-time pricing scheme? Pretty rare these days.

PS, the Demo link in your site's header doesn't seem to go anywhere (nor FAQ).

I have no affiliation with this product or company. I'm curious about the options here from a business perspective.

A business has continual costs, which at the minimum may just be the ability to support a single developer's adult life. This app is selling itself once per major version, which judging by some comments here is somewhat unappealing. Many people are justifiably sick of subscription payments. I am also assuming many people would not appreciate e.g. an ad-supported version of something like this app.

So, what does that leave in terms of realistic business options? Are there any examples out there of a software business that succeeds in supporting its own development while helping its customers feel like they are getting their money's worth?

Can you share any examples of obstacles like that you've seen?

No real comment on mobile, but I disagree with your take on Flutter web. I've deployed a moderately complex Flutter web app (SPA) and have been pleasantly surprised at every turn with how capable it is, from performance to complexity management to testing. And the flexibility to produce an AOT-compiled desktop app from the same codebase, should I choose, is nice to have.

Ah ok, I see what you mean (and likely sibling comment too w.r.t. gcc feature). Yes that is a fair point - though still has the substantial downfall of maintaining many different implementation of any given algorithm.

This is useful but not equivalent. Using this type of tooling you still have to write the algorithm itself in N versions. Changing the algorithm then requires changing all N implementations. This contrasts with the Halide approach where the algorithm is written once, and then schedules can be modified without worrying that you are changing the algorithm itself.

Good article that I agree with mostly. One interesting note is this:

> There is no way to provide both optimized assembly and equivalent C code and let the compiler use the former in the general case and the latter in special cases.

This is true, but can be seen as a failure of language and tooling. For example, Halide [1] pioneered (AFAIK) the concept of separating algorithm from implementation at the language level. This separation lets you express the algorithm once, and then "schedule" it by specifying parallelism, vectorization, etc. You can provide multiple schedules for one algorithm, which allows you to specialize / make different choices depending on varying factors.

It's a really interesting concept, though maybe limited in practice to DSLs. I'm not sure a general purpose language would be a good fit for this model, but then, for general purpose programs written in general purpose languages, perf optimization at the level TFA discusses is frequently limited to just specific hot sections. Those hot sections could be extracted out into specialized components written in such a DSL.

1 - https://halide-lang.org/

I don't know what the author of this article, used but the current iteration of Vexlio [1] is a good fit for this type of diagram. (I am the developer).

[1] - https://vexlio.com

Author here - happy to answer questions or field feedback!

Is this a serious thing? If so, I'd like to know where I can purchase the wasp meat required to make this recipe: https://www.recipeninja.ai/recipe/r_NYrbOKZEyqrp7r/wasp-meat...

Bezier curves (the regular kind) cannot represent circles and ellipses, this is true. However, rational Bezier curves can [1]. I don't know if PostScript has a rational Bezier primitive, but some drawing libraries do. A prominent example of a library that does is Skia, the rendering engine behind Chrome and Android.

[1] - e.g. https://en.wikipedia.org/wiki/B%C3%A9zier_curve#Rational_B%C...

Oh wow, thank you for linking that paper. I've been working an interactive tool for a while and have been musing on new constraint and layout types to add. Anecdotally it seems a lot of mainstream graph layout algorithms work well for small to mediumish complexity inputs, but then quickly start generating visual spaghetti. So this looks incredibly apropos for me.

Does Cloudcraft do generic diagramming? At least from the landing page it seems pretty purpose-built for cloud architecture diagramming only. I also have to give major kudos for whoever made the call to go with an isometric projection... visually and mentally, it's a perfect choice for that domain!

Hah, I appreciate the distinction on enterprise-grade... Anything in particular you like or dislike in particular from your experience with Lucidchart or draw.io?