Hacker Newsnew | past | comments | ask | show | jobs | submit | neeleshs's commentslogin

Syncari | Remote (US only) | Full-time | Director, Solutions Engineering

We are an all-in-one modern data integration, management, workflow and analytics platform.

VC funded, small team. Hiring for Director, Solutions Engineering team, to run our onboarding, implementation including PS and support functions.

Apply: https://www.linkedin.com/jobs/view/4276895381/

Comp: $175k base + bonus + equity + 95% healthcare contribution (medical+dental+vision and some life insurance)

We don't sponsor visas at the moment


I use LLM to generate complete solutions to small technical problems. "Write an input stream implementation that skips lines based on a regex".

Hard for an IDE auto complete to do this.


Yeah absolutely.

I find Copilot is great if you add a small comment describing the logic or function. Taking 10s to write a one line sentence in English can save 5-10 mins writing your code from scratch. Subjectively it feels much faster to QA and review code already written.

Having good typing and DTOs helps too.


Or a tapestry! (I have one in our dining room)


Can you say more about what didn't work with HTMX? What parts make terrible DX?

I also think HTMX is meant mostly for backend developers to be more productive in frontend.


My experience with it is, one there’s no decent templater for nodejs, two this web1 like architecture really makes no sense as a developer. Everything is a subpage transfer rather than a meaningful operation/update. I came from desktop ui background (delphi, vb, gtk, qt, appkit), not from web. The web is all fucked up, tbh, it’s not only htmx. But at least spas vaguely resemble how normal apps function.


I see. HTMX and others target the browser, which is primarily an HTML renderer. So there is nothing inherently bad about page transfers. That's what hypermedia is about.

React et al try to create a different paradigm on top of this. And that makes it like building a desktop UI AND a server app

To me, this is not in anyway better than building something for the browser - pages and html.


Even with react, we have found that having a separate API layer was more ergonomic.

Maybe with graphql it is different


B25 for Bloom would've been nicer


I'm probably an outlier here. My experience with GCP support has been nothing but stellar, like I described in another comment down below


I've had similar experiences with Google as well. Reaching out with new services, hours with some of their technical people, invites to meetups, free credits, an extremely pleasing and responsive account manager. We spend a few hundred thousand dollars a year with them. The actual software is top notch. Most haven't been just turn it on and forget it.


Yeah, I'm a little biased here as I now work at Google, but I joined in part due the positive experience we had migrating from bare metal to Google Cloud.

We went through two rounds of migration. First placing our data warehouse, where BigQuery was just so far past Redshift it was almost a joke. Then we wanted to move to a cloud provider with good container orchestration and GKE was obviously better than AKS and all of Amazon's proprietary orchestrators. It was pretty good.

Customer support varied between excellent and ~fine. Amazon customer support throughout that time (we had a few small bits on Amazon) was fine, but less enthusiastic about winning our business.

Not long after a friend of mine reported a security incident to AWS, something that looked like Amazon privileged access to their data, and it took months to get a response from them, and it was never an adequate explanation for what looked in all ways like a hack.


Yep. BQ,GKE, and at a metalevel the simpler project structure -all have been great. I cannot still fully understand the org hierarchy that AWS has yet.


Do you do this in raw react, or use some third party carousel library? If so, maybe something like that can be used with HTMX as well?

But your larger point stands, HTMX is probably not a great fit for highly interactive webapps, even though you can push it pretty far


Spring boot has form validations pretty much out of the box, via validation annotations.


It does have validations but the integration of then in Rails goes much further. In Rails you associate the form with the model and the validation errors somatically show up on the form.


The biggest difference here is that Spring Boot has the errors in a seperate object BindingResult. If you use Thymeleaf, this is smoothly integrated and you just write: <p th:if="${#fields.hasErrors('comment')}">Invalid Comment</p>

Grails Framework (Spring Framework more like Rails) integrates errors directly into the domain model, so if you have a domain class Person, it was extended with person.errors property.


I'm amazed that some people think that coupling your forms to your database models is a good practice.


Maybe, because it works?

What value does "not coupling" give you, when you end up copy pasting the attributes from one object to another anyway?


More often than not, forms are the database model. They very frequently evolve together. The entire data transfer object to model copy back and forth is unnecessary most of the time


If the form is basically raw CRUD then it works out well, and being able to get up and running quickly and replace it with something more sophisticated later when you actually need that is a good thing.

It does require the discipline to actually _do_ the 'replace it' part when you reach that point and the results of failing to do that are ... not pleasant ... but that doesn't mean it's _always_ the wrong choice, especially when getting started.


It goes further than that. The form gets passed the model and it's name and based on that also drivers the URL and http action to take.

IMO this is good coupling since it's very loose, trivially changed and eliminated boilerplate code that's just noise. Of course, as always, it depends on a number of circumstances what trade-off is best for you, your team, the specific problem, etc


It depends a lot on the application. I have a little Django app that I haven't updated in years and is used by one person—it's basically just a nice frontend for a database. For that use case, being able to just directly plug forms into database models is super convenient!


Could you elaborate on why it is a bad practice?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: