Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RIP Low-Code 2014-2025

zackliscio.com

Post reply on HN
Print view View original

141–150 of 160 posts

Re: RIP Low-Code 2014-2025

#141

Post by surajrmal »

antidamage wrote: post #76
rahilb wrote: post #24

> the cost of shipping code now approaches zero Does anyone actually believe this is the case? I use LLMs to ‘write’ code every day, but it’s not the case for me; my job is just as difficult and other duties expand to fill the space left by Claude. Am I just bad at using the tools? Or stupid? Probably both but c’est la vie.

I think the answer is that by the time AI can replace every function you do, it's also replaced everyone else and the world will either already have or will need to change radically. I personally hope that the future becomes a UBI consumer-as-a-job thing, minus too much of the destructive impact that current consumerism has on the world.

Working together to make something is actually fun though. Seeing something you helped build be useful for others can be fulfilling. I'm not suggesting you should only live to work, but there are aspects of work that make life more enjoyable. I dread becoming a full-time consumer (aka retirement).

Re: RIP Low-Code 2014-2025

#142

Post by nicohorn »

thewhitetulip wrote: post #124
nicohorn wrote: post #34

Earlier quoted context omitted.

Same here. I use Claude Code everyday, very useful, but nowhere near to where I don't have to jump in and fix very simple stuff. I actually have a bug in an app that I don't fix because I use it as a test for LLM's and so far not one could solve it, it's a CSS bug!

I use Cursor daily, I have worked on Agents using LangChain. Maybe we are doing something wrong but even ysing SOTA models unless we explicitly give which mcp tool to call, it uses anything - sometimes - while other times it can do a passavle job. So now our mandate is to spell everything out to LLM so it doesn't add a non existent column like created at or updated at to our queries I've used every SOTA for day to da…

Precisely, I always find myself thinking that maybe I'm just too dumb to use these LLM's properly, but that would defeat the purpose of them being useful haha.

Re: RIP Low-Code 2014-2025

#143

Post by _heimdall »

electroly wrote: post #134
_heimdall wrote: post #126

Earlier quoted context omitted.

REST is self documenting. Edit: for down voters, I'd be curious why.

Not one of the downvoters, but I'd guess it's because this is only true with HATEOAS which is the part that 99% of teams ignore when implementing "REST" APIs. The downvoters may not have even known that's what you were talking about. When people say REST they almost never mean HATEOAS even though they were explicitly intended to go together. Today "REST" just means "we'll occasionally use a verb other than GET and PO…

But that is roughly the point here. If we still used REST we wouldn't need swagger, openapi, graphql (for documentation at least, it has other benefits), etc.

We solved the problem of discovery and documentation between machines decades ago. LLMs can and should be using that today instead of us reinventing bandaids yet again.

Re: RIP Low-Code 2014-2025

#144

Post by storystarling »

Bishonen88 wrote: post #129
oxidant wrote: post #73

Earlier quoted context omitted.

Exactly the point I was going to make. Shipping something requires knowing how to ship it, monitor it, and fix it. Writing code is the "easy" part and kind of always has been. No one triggers incidents from a PR that's been in review for too long.

LLM's can help with all of the above. Deployed an app with a backend, frontend, docker database and more with gitea on my NAS just yesterday. Have little knowledge about how it did it. Now I have a git remote to which I push and the app updates itself.

I guess it works well until you hit a stateful failure. My concern would be Day 2 operations—debugging a database issue or networking partition without a mental model of the underlying architecture seems pretty painful.

Re: RIP Low-Code 2014-2025

#145

Post by pacoWebConsult »

NetMageSCW wrote: post #137
pjc50 wrote: post #115

Earlier quoted context omitted.

It has been a very long time since I have written any Delphi, but I prefer dotnet these days. The only (very real) problem is trying to predict what the best long term UI option is for native apps.

Yes, it is in the Visual part of Visual Studio that Microsoft has gone off the rails. .Net (C#) is a good development language but Windows Forms being the most usable GUI framework is far from where Microsoft should have gone.

WPF was full of footguns and rigid organization to alleviate said footguns. MVVM (Model, View, Viewmodel) architecture was so much boilerplate and toil to work with. It feels like the advent of Electron-based desktop apps caused MS to simply give up on the space.

I don't have too much experience with MAUI so I can't comment on that.

Blazor's initial bundle sizes made it quite difficult to consider as an option for web applications, despite the ability to share code between frontend and backend.

I still feel like the ASP.NET + Frontend SPA story has a long way to go compared to what is available in the fullstack typescript ecosystem right now. Shared typings between the frontend and backend via tools like tRPC/ oRPC, or full RSC/SSR frameworks like Next and TanStack start are just so much more ergonomic, but the backend TS story, especially in data access and ORMs is so much worse compared to Entity Framework. Prisma is abysmally slow, and Drizzle is getting there but IMO nothing right now compares to the power and DX of EF Core + Linq methods.

Re: RIP Low-Code 2014-2025

#147

Post by pphysch »

dgxyz wrote: post #103
pphysch wrote: post #65

Earlier quoted context omitted.

> MS Access for the web with an SSO This is essentially Rails and Django and so on

That's not even remotely close to the idea. It's conceptually entirely different. I'll note that Access existed in a completely usable form before the www even existed.

How is it conceptually different? RDBMS ORM-based web frameworks (with built-in Admin GUIs) ate the web-oriented crowd, and the rest are happy managing their data in Excel. That doesn't leave much room for MS Access.

Re: RIP Low-Code 2014-2025

#148

Post by raverbashing »

electroly wrote: post #134
_heimdall wrote: post #126

Earlier quoted context omitted.

REST is self documenting. Edit: for down voters, I'd be curious why.

Not one of the downvoters, but I'd guess it's because this is only true with HATEOAS which is the part that 99% of teams ignore when implementing "REST" APIs. The downvoters may not have even known that's what you were talking about. When people say REST they almost never mean HATEOAS even though they were explicitly intended to go together. Today "REST" just means "we'll occasionally use a verb other than GET and PO…

HATEOAS won't give you the basic nouns on which to work with

Re: RIP Low-Code 2014-2025

#149

Post by elzbardico »

hecanjog wrote: post #46
spankalee wrote: post #7

I think this view is really short-sighted. Low-code tools date back to the '80s, and the more likely outcome here is that low-code and agentic tools simply merge. There's a lot of value in having direct manipulation and visual introspection of UIs, data, and logic. Those things allow less technical people to understand what the agents are creating, and ask for help with more specific areas. The difficulty in the past…

This makes the most sense to me too. My feeling is so-called AI is going to deliver on a lot of the things we're used to having shoddy versions of -- good natural language interfaces, good WYSIWYG type tools, all of this could turn the wix/squarespace/wordpress/etc landscape into something pretty good, rather than just OK. In my most hopeful of futures, we've figured out how to do lightweight inference, and if the mo…

Why your tiny custom music shop can’t sacrifice part of their income for labor, but developers losing income is ok?

Re: RIP Low-Code 2014-2025

#150

Post by _heimdall »

raverbashing wrote: post #148
electroly wrote: post #134

Earlier quoted context omitted.

Not one of the downvoters, but I'd guess it's because this is only true with HATEOAS which is the part that 99% of teams ignore when implementing "REST" APIs. The downvoters may not have even known that's what you were talking about. When people say REST they almost never mean HATEOAS even though they were explicitly intended to go together. Today "REST" just means "we'll occasionally use a verb other than GET and PO…

HATEOAS won't give you the basic nouns on which to work with

Right, you wouldn't need HTML at all for LLMs though. REST would work really well, self a documenting and discoverable is all we really need.

What we find ourselves doing, apparently, is bolting together multiple disparate tools and/or specs to try to accomplish the same goal.

Post reply on HN