WingNews logo WingNews GitHub [2]

hypermachine's comments

hypermachine | 5 years ago | on: PSD is not my favourite file format

How do you deal with features that cannot be modeled as pure functions or are too computationally heavy to rerender on change? For example, user selections, copy and paste, ray tracing.

Also I recommend using the Rete.js library for the underlying nodes editor instead of rolling your own.

hypermachine | 5 years ago | on: Wix and Their Dirty Tricks

I have tried many, many website editors. Wix is one of the better ones. Among the big three managed website builders of Wix/Squarespace/Weebly, Wix has the most powerful editor. Sure it's very unintuitive if your are a frontend web developer. But it maps very well to pre-2008 desktop application builders. Take a look at the Retool editor if you want a better explanation. The ideas behind them are similar; rapid development based on pixel grids.

You can divide UI editors generally into two categories, those that allow arbitrary positioning and sizing, and those that don't. Those that don't are much more familiar to web developers as the underlying structure is based on relative positioning for different screensizes. In other words flexbox and breakpoints. It is also easier to use variables for fonts and other elements as there are fewer hard constraints. But if you try to use a website (or any UI) builder without arbitrary drag and drop, it gets very frustrating as your UI feels as if it is "stuck" to a particular design. Weebly and Squarespace don't even allow much changes to layout at all by the visual editor outside of pre-built components so they are significantly less powerful than Wix relatively speaking.

hypermachine | 5 years ago | on: I can only think that modern front end development has failed

The hardest thing is making things pretty and flexible while maintaining ease of development. Newer UI kits like Flutter are basically architected like game engines. This is a challenge that UI framework designers will have to confront if they want more native alternatives to electron. Whatever replaces electron must at the very least be similarly easy to use, accessible to many languages and runtimes, and trivial to style with non-copyleft usage license.

hypermachine | 5 years ago | on: Developer tools can be magic but instead collect dust

Because in 2021 developer tools are fundamentally not profitable. Jetbrains is the exception, not the norm. Developer tools are loss leaders for large corporation to acquire developer goodwill and mindshare. Previously we sold developer tools/PaaS. Programmers do not like to pay for their tooling. You have to sell to management, and when your target is management, then the metrics are completely different from what developers want.

This is why no-code and low code are so much more successful than developers tooling startups in terms of revenue and profitability. The people using are the same people who are running the business. The value proposition is clear. "Better developer experience" alone is not sufficient for selling to enterprise. And programmer productivity cannot be quantified in lines of code written. This is hard point to explain and get across on HN because this forum is inherently dismissive of the value of RPA and RAD software.

hypermachine | 5 years ago | on: Comparing Svelte and React

The UI builder and libraries are still heavily WIP. Previously we were focused on making a VBA interpreter.

For the HTML-over-wire part we are experimenting with a protobufs-based protocol so the backend runtime can support as many languages as possible. The most challenging part is that client-server UIs have fundamentally different assumptions about state, concurrency, and session handling compared to traditional desktop/mobile GUIs that operate on callbacks. Most of the design patterns used for your typical WinForms/Cocoa UI fail horribly in web scenarios (unless the entire app is running client side in WebAssembly) because state must be held in a DB, global variables are completely not allowed and multiple users may simultaneously access a service so any form of long-running loops or blocking code is very problematic. Serverless could help here but you will need long-running serverless containers. The current pricing models of AWS Fargate and Google Cloud Run are not compatible with this.

This is additionally complicated by the fact that many languages have async/concurrency "bolted-on". It is hard to integrate a WebSockets server into the language if there is already another event loop to deal with. This is especially problematic for feature-fragmented languages like Python where async is a relatively new concept. (See https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...) Go is basically the gold standard here. Overall, we are still working on how to build the language-agnsotic backend SDKs without too much duplicate code. If you see similar systems like Streamlit and Plotly Dash, they avoid the problem entirely by making proxying the default way of embedding in third party applications. The integration is not as tight as traditional UI frameworks but avoids many of the problems with state management.

For deployment, the Blazor/LiveView/HTML-over-wire format would also require CDNs that are as close to the end user as possible for lowest UI latency. Think Zeit/Vercel or Fly.io.

There's a mailing list link below where you can be notified for when we launch:

https://hypermachine.org

hypermachine | 5 years ago | on: Comparing Svelte and React

We are actually going the other direction. Currently I am experimenting with making a Blazor/Liveview (HTML over wire) runtime that can support many programming languages. And a GUI builder.
page 1
more