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

How I build software quickly

evanhahn.com

Post reply on HN
Print view View original

201–210 of 215 posts

Re: How I build software quickly

#201

Post by oblio »

kukkeliskuu wrote: post #182
brabel wrote: post #172

Earlier quoted context omitted.

I used it a long time ago. As far as I know, it's an abandoned project now, very few people use it in the Java community. Go for one of the more popular ones: Spring, Micronaut, Helidon or Quarkus.

There are new frameworks all the time, but only very few establish a community that allows the framework to survive on the longer term. When you choose something that has been around for a long time, the probability for this is much higher, than for something that looks promising. Another benefit of the established frameworks is the amount of experience from various corner cases that has been coded in them. New frame…

Yup, exactly, and Dropwizard is basically an opinionated bundle of Java "All-Stars" libraries. It's not like the "glue" needs a ton of updates and everything else is already well maintained at the source.

Re: How I build software quickly

#202

Post by lmm »

kukkeliskuu wrote: post #187
lmm wrote: post #83

Earlier quoted context omitted.

> Most applications don't need to be single-page apps nor require heavy frontend frameworks. Even for those that can benefit from it, traditional Django views is just fine for 80% of the pages. For the rest, consider AlpineHJS/HTMX Doesn't that contradict "learn one tool well"? I write every webpage in React, not because I think everything needs to be an SPA, but because enough things end up needing client-side state…

Yes, I contradicted myself in that sense. I am not going to argument against your point. But let me elaborate my approach which explains this apparent contradiction. Backend is needed in any case, and for me that is almost always Django. It is extremely fast to build traditional (non-SPA) CRUD apps with Django if you have only one model / one page. I can make a new one less than an hour. If I need more interactivity…

> Backend is needed in any case

Well, sort of. Much as I hate the idea, maybe Next.js for everything is the way to go, bashing out a CRUD app there is very quick.

> create partial forms and return HTML fragments, instead of full pages

I loved that approach with Wicket and made systems that way for many years, but it just isn't good enough these days, at least for a website that's going to be used in more than one location. When it takes a network roundtrip to update your UI it's always going to be noticeable.

Re: How I build software quickly

#203

Post by brabel »

kukkeliskuu wrote: post #182
brabel wrote: post #172

Earlier quoted context omitted.

I used it a long time ago. As far as I know, it's an abandoned project now, very few people use it in the Java community. Go for one of the more popular ones: Spring, Micronaut, Helidon or Quarkus.

There are new frameworks all the time, but only very few establish a community that allows the framework to survive on the longer term. When you choose something that has been around for a long time, the probability for this is much higher, than for something that looks promising. Another benefit of the established frameworks is the amount of experience from various corner cases that has been coded in them. New frame…

Hm I can guarantee that the frameworks I listed above will be well maintained for a long time and are much more “battle tested” than Dropwizard itself (though some of the libs that it includes are actually independent and used in other frameworks, those are sure to survive long time). You make it sound like Dropwizard is the more established framework when in reality it’s rather the opposite.

Re: How I build software quickly

#204

Post by kukkeliskuu »

gl-prod wrote: post #72
kukkeliskuu wrote: post #22

In recent years, I have learned how to build sufficiently robust systems fast. Here are some things I have learned: * Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot. Several times I have started a project thinking that maybe Djan…

In Django, how do you create components well and handle user interactions?

I use django-components.

Re: How I build software quickly

#205

Post by pdimitar »

kukkeliskuu wrote: post #187
lmm wrote: post #83

Earlier quoted context omitted.

> Most applications don't need to be single-page apps nor require heavy frontend frameworks. Even for those that can benefit from it, traditional Django views is just fine for 80% of the pages. For the rest, consider AlpineHJS/HTMX Doesn't that contradict "learn one tool well"? I write every webpage in React, not because I think everything needs to be an SPA, but because enough things end up needing client-side state…

Yes, I contradicted myself in that sense. I am not going to argument against your point. But let me elaborate my approach which explains this apparent contradiction. Backend is needed in any case, and for me that is almost always Django. It is extremely fast to build traditional (non-SPA) CRUD apps with Django if you have only one model / one page. I can make a new one less than an hour. If I need more interactivity…

To me it sounds like it's time for you to get to know Elixir's (Phoenix's) LiveView. It does this even better and you barely write any JS at all.

Re: How I build software quickly

#206

Post by kukkeliskuu »

whizzter wrote: post #195
kukkeliskuu wrote: post #22

In recent years, I have learned how to build sufficiently robust systems fast. Here are some things I have learned: * Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot. Several times I have started a project thinking that maybe Djan…

I think HTMX as "simple" solutions comes into the same class as you mention "django being too heavy". Sure, Django,Rails,Asp MVC,etc with static pages could be fully functional for something that is 99% CRUD. But I myself foolishly tried using static view+HTMX for something that should have been built with something more dynamic like Vue/React(perhaps Alpine?) from the start due to actual client-side complexity. In g…

Who could argue with the "right tool for the job"? I am not saying that there are no use cases for other approaches.

But when you say you had a "static view" (in singular, not plural) with HTMX, what do you mean? I am very interested in hearing what kind of complex interaction you had where that approach failed?

With HTMX, I have found the most useful approach is to build your pages from lots of very small components. Initially, I don't worry about reuse of those components, it is more about decomposition than reuse.

Of course, if you want to do "fast client data slicing", then HTMX makes no sense, because it pushes logic to the backend and by definition your solution wants to process data in the fronted. So if you start from that premise, HTMX is obviously the wrong tool.

If you want to use HTMX, you need to rethink your solution, i.e. question whether you really need "fast client data slicing". So why bring all the data to the frontend, and not just the slice you want to visualize?

One reasonable use case is reducing server load. I have one app where data is loaded from static generated pages (periodically updated, for performance, stability and reduced server load), and sorting is done on the frontend using Javascript, based on data attributes on the DOM.

Re: How I build software quickly

#207

Post by qwertox »

kukkeliskuu wrote: post #22

In recent years, I have learned how to build sufficiently robust systems fast. Here are some things I have learned: * Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot. Several times I have started a project thinking that maybe Djan…

> Learn one tool well.

That works well until that tool stops being maintained, or is evolving in such an odd direction that it breaks your code.

Django is really an exception to something one can rely on, but reality is more like Angular -> breaking, Vue -> breaking, React -> breaking.

Re: How I build software quickly

#208

Post by kukkeliskuu »

lmm wrote: post #202
kukkeliskuu wrote: post #187

Earlier quoted context omitted.

Yes, I contradicted myself in that sense. I am not going to argument against your point. But let me elaborate my approach which explains this apparent contradiction. Backend is needed in any case, and for me that is almost always Django. It is extremely fast to build traditional (non-SPA) CRUD apps with Django if you have only one model / one page. I can make a new one less than an hour. If I need more interactivity…

> Backend is needed in any case Well, sort of. Much as I hate the idea, maybe Next.js for everything is the way to go, bashing out a CRUD app there is very quick. > create partial forms and return HTML fragments, instead of full pages I loved that approach with Wicket and made systems that way for many years, but it just isn't good enough these days, at least for a website that's going to be used in more than one loc…

I assume you are talking about geographical distribution of the user base. I don't have experience implementing apps that require heavy geographical distribution, but why does REST/JSON work better for this?

I don't have experience with Wicket, but with HTMX, I have tried to make components very small. For example one switch button is one component. Loading that is very fast in my experience, as compared to reloading and rerendering all data with React etc.

Re: How I build software quickly

#209

Post by kukkeliskuu »

pdimitar wrote: post #205
kukkeliskuu wrote: post #187

Earlier quoted context omitted.

Yes, I contradicted myself in that sense. I am not going to argument against your point. But let me elaborate my approach which explains this apparent contradiction. Backend is needed in any case, and for me that is almost always Django. It is extremely fast to build traditional (non-SPA) CRUD apps with Django if you have only one model / one page. I can make a new one less than an hour. If I need more interactivity…

To me it sounds like it's time for you to get to know Elixir's (Phoenix's) LiveView. It does this even better and you barely write any JS at all.

That is on my list of things to learn. It is not high priority, though, because I don't think Phoenix LiveView is extremely boring technology at the moment. The user base is not large enough.

Re: How I build software quickly

#210

Post by pdimitar »

kukkeliskuu wrote: post #209
pdimitar wrote: post #205

Earlier quoted context omitted.

To me it sounds like it's time for you to get to know Elixir's (Phoenix's) LiveView. It does this even better and you barely write any JS at all.

That is on my list of things to learn. It is not high priority, though, because I don't think Phoenix LiveView is extremely boring technology at the moment. The user base is not large enough.

A lot of stuff is quite commoditized already, and I never found the size of a user base a convincing metric to judge by (not to mention the chicken-and-egg problem that you just demonstrated).

People are doing genuinely hugely impressive production-grade work there, and I am currently looking at a SigNoz dashboard while >200 users are frantically clicking on dozens of places in our UI (contains many reactive bits); our code is nowhere near optimal and we very rarely get >150ms response times, most are 20-50ms, and we're talking some quite tame machines (2 of them) with 8GB RAM and 2 CPU cores... and even then 90% - 99% of the time is spent waiting on the database.

Post reply on HN