Hacker News Reader

Most likely, your framework Is productive for you not because it’s the best framework available, but because you wrote it and know the ins and outs of it and it matches up to how you think. This isn’t too day it’s not likely better than other frameworks in at least some ways, but familiarity begets expertise which begets productivity.

Many experts in drywall installation before drywall screws were popularized swear that screws are slower and worse. However, an expert nailer and an expert screwer both complete jobs just as quickly (if not faster for the screw-adherent), and just as well.

And the ability to focus on just aspects that are relevant. That simplifies the problem immensely.

I look at the current situation of UIs in Rust, every one of which is unappealing, and think I could build my own. The basic structure and paradigm is so simple! Then, I think... Unicode support. Right-to-left text display. Affordance for text readers.

All very important, but things I could ignore for myself, but not in a publicly shared library. And... ugh. Either I would have to spend years figuring that stuff out, or pull in a number of other libraries which adds layers of abstraction and complication. So I fire up Civ 6 instead.

There is an element of truth to that, especially as I was building the SDK, it helped me a lot that I knew how all the parts worked and could make everything fit together into a cohesive whole. Though now that it's done, I think you don't need much knowledge to use it. Will be interesting to see how other people react to it as it's geared towards designers and junior devs who only know HTML, CSS and basic JS.

> Many experts in drywall installation before drywall screws were popularized swear that screws are slower and worse.

Screws are superior as an end product. Old houses will tell you that with the amount of creaking and slop that builds up with nails.

But there are videos floating around about the expertise of some old nail drywall experts. Holy smokes it could be fast. They are probably right about the speed.

> Companies started forcing everyone to use these frameworks

Companies are made of people who, hopefully, have people in decision making roles who have context and the knowledge to make the right decisions. There are reasons why we use "these frameworks" (be it frontend or backend). You may not like the reasons but corporate programming isn't just about language purity but what makes the company money, of which there are a lot of factors like hire-ability, maintainability, continuity, etc.

What happens when your company uses your bespoke SDK and you leave? You may think its easy to teach someone else how to use it but there's a lot more that goes into how companies make technology decisions.

I am curious about your SDK now. Do you host it publicly? If no, could you at least explain what is the difference between your method and mainstream frameworks?

I plan to introduce my SDK publicly via the no-code platform I've been working on as a 'low-code' alternative for cases were additional flexibility is required.

To give you a rough sense:

- My SDK has some front end components and back end components connected via WebSockets using a client/server framework I wrote years ago and have been maintaining.

- It's all declarative so for example, for the back end, I don't write much code, I just declare the models, what fields they have, what views of the data are exposed and specific access controls. The back end is mostly a large JSON object. I don't want to go into too much details but the way it's set up, it's very flexible and you can model almost any kind of data and relationships with little to no code. It guides you towards a good architecture which makes good use of database indexing (so it performs and scales well). To connect the back end models and front end, it's a twist on the old CRUD concept so that it is conflict-free. I went down a completely different path to GraphQL and I think the result is simpler, more efficient, provides better access control, simpler caching and code (or should I say markup/JSON) is much easier to read and maintain. As you build your system using it, it guides you into making optimal architectural decisions at every step, keeping complexity as low as possible (as opposed to GraphQL which, by virtue of its extreme flexibility allows complexity to grow out of control).

- The front end components provide ways to render lists and objects in complex ways (e.g. grouped, filtered based on relationships between different models; all declarative). Components are hooked into the model backend in a particular way so they update in real time by default. Real time updates are delivered to the front end efficiently. Only relevant components/views update themselves and they do so automatically. Pagination is automatic and specified declaratively as part of the HTML and in accordance to limits specified in the back end JSON. Access control is enforced automatically based on the rules specified on the back end in the JSON object.

I'm almost at a point where I can build entire complex apps using only HTML on the front end and JSON on the back end with essentially no code.

> I'm almost at a point where I can build entire complex apps using only HTML on the front end and JSON on the back end with essentially no code.

I think you are missing the point of no-code. Your solution isn't even low-code, you just created a framework with well-thought components to start a project. If you need to integrate a third-party component that uses code, you'll need to integrate that code in your HTML/JSON or create a new abstraction in JS to use in the HTML.

disclaimer: I'm creating a "similar" platform and got curious by what would set your SDK apart from mainstream frameworks but I don't think what you described is anything different. For the view part, is it using something like htmx, react or pure JS?

It's definitely no code. I built some dynamic pages of my service to manage data with it that are all HTML markup and JSON. I would have used it for all pages if I had created the components earlier.

HTML is markup, not code. JSON is object notation, not code. I used very little code to build my service. I think this type of highly flexible low-code is the right path to no-code.

I know from experience that people with zero tech knowledge can be taught HTML and CSS in a few weeks.

> HTML is markup, not code. JSON is object notation, not code.

They most definitely are code. They are not programming languages, and writing them is not 'programming', but they are still code.

You might find the paper Out of the Tar Pit interesting if you haven't already read it: https://github.com/papers-we-love/papers-we-love/blob/main/d...

The ideas and approaches you talk about evoked some of the concepts from that paper for me. It talks a lot about separating accidental complexity and infrastructure so you can focus only on what is essential to define your solutions.