4 ms·

The other thing is that we've adopted the wrong abstractions on many occasions. Today, in the software industry, we have an arrogant mono-culture which believes

The other thing is that we've adopted the wrong abstractions on many occasions. Today, in the software industry, we have an arrogant mono-culture which believes that we're at the end of history and have figured it all out... But in fact, I believe we've gone down the wrong path with many more recent tech. I feel like everything was moving on the right direction until around 2014... Then it's like progress started going backwards and we started using all the same hyped up frameworks. Companies started forcing everyone to use these frameworks and now software development has become both inefficient and demoralizing. I know the current mainstream state of the art is inefficient for sure because I've built an SDK which I use for my own projects and I'm at least 10x more productive with it than with mainstream frameworks I used during my day job and the code is way easier to read and maintain. I could show the code to a junior dev who doesn't know any frameworks and they will be productive with it. I wrote a no-code BaaS (Back end as a Service) platform in 2 months part time using my SDK. I highly doubt I or anyone else could have done this in 12 months full time using mainstream tools and frameworks.

halfmatthalfcat 3y ago
> 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.
tommybu 3y ago
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?
- jongjong 3y ago
  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.
  - meiraleal 3y ago
    > 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?
Olreich 3y ago
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.
- jongjong 3y ago
  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.
- pleoxy 3y ago
  > 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.
- kbelder 3y ago
  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.

halfmatthalfcat 3y ago

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

tommybu 3y ago

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?

jongjong 3y ago
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.
- meiraleal 3y ago
  > 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?

Olreich 3y ago

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.

jongjong 3y ago
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.
pleoxy 3y ago
> 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.
kbelder 3y ago
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.