Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
midrus
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
1.
▲
by
midrus
4y ago
I’ve used thinkpads (and the X1 in particular) for many years. And I do think they’re the best option you have outside of the apple ecosystem. But they are far, far, far of being an excellent replacement for MacBooks. Specially after the ne
2.
▲
by
midrus
4y ago
What an awesome metaphor, 100% agree with this. That's why I've always said that the SPA architecture with a separate backend is a way to increase the amount of work so that it can be distributed to more people/teams. It baff
3.
▲
by
midrus
4y ago
I think my job is to ship useful, secure and robust features to my company's customers. Dealing with technology is a consequence of that, not the end goal itself, which seems to be what's most wrong about this industry. Certainly
4.
▲
by
midrus
4y ago
It's mind boggling some people don't know you can render plain html on the server, or even submit forms without javascript. Such a basic building block seems to be fading away nowadays, even some times presented as a "novel&q
5.
▲
by
midrus
4y ago
Say you're travelling back from 2099 and your comment still applies :-)
6.
▲
by
midrus
4y ago
In my opinion (and experience, this architecture is great as a way to scale teams, having a clear interface between them. As soon as you have to work on both sides of the API, it is not and advantage anymore. I think separating the backend
7.
▲
by
midrus
4y ago
Not my experience. Most Laravel projects I've seen are in a much much better shape than even the most minimal "microservices" I've seen around. You get so much done for you with Laravel that it makes it a bit more diffic
8.
▲
by
midrus
4y ago
Already mentioned in other replies, but as a long time node/react developer, for the last year or so I've been working on a project built with Laravel (blade components) + Unpoly (for server interactions) + Alpine (client side onl
9.
▲
by
midrus
4y ago
Next.js is easy peasy and lovely and wonderful until you need to mix in validations + translations + authentication + authorisation + calling upstream APIs with user's credentials + ... That's when you realise using what would be
10.
▲
by
midrus
4y ago
I use Unpoly (equivalent to HTMX for your question) + Alpine and they complement each other very well. Unpoly handles everything that requires what in SPA world would be an "API call", the difference is that the response I get is
11.
▲
by
midrus
4y ago
A lot. https://blog.jannikwempe.com/debunking-tailwind-counterargum... https://www.swyx.io/why-tailwind And many similar ones.
12.
▲
by
midrus
4y ago
Don't forget Unpoly! A bit more opinionated and "batteries included" than HTMX, still same ideology. I use it every day and I love it.
13.
▲
by
midrus
4y ago
> I make a difference between website and webapp. Everyone says this, which doesn't solve anything. 99,9% of what we build is just something in between. It is not as easy as you make it look like.
14.
▲
by
midrus
4y ago
> Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend I've been working for 20 years on this, last 8 ~ 9 only with node and React a
15.
▲
by
midrus
4y ago
But it is trendy and fashion, so we still do it /s
16.
▲
by
midrus
4y ago
The moment you need SSR, you'd be in a better place if you were using just plain old server rendered (componetized) views, such as the ones you can do with laravel's Blade system, and do your client side interactions with Alpine a
17.
▲
by
midrus
4y ago
Err... We're literally this close to wipe out ourselves. I'd still take the discovering of an advanced civilization any day.
18.
▲
by
midrus
4y ago
Or they just got bored and wanted to try some shinier toy. I've seen this happen dozens of time, all the bullshit for justifying it is just that, bullshit. Not saying this is the case here but highly likely.
19.
▲
by
midrus
4y ago
Unless it is an offline-first web app, or something like Figma, I'd go for the TALL stack [1] and deploy to Heroku or App Engine (or Dokku [2] if it is just a side project). Specially if I'm building it myself, or with a small tea
20.
▲
by
midrus
4y ago
Wile E. Coyote will be so happy with this.
21.
▲
by
midrus
4y ago
My cat is the smarter cat ever. It managed to train me very well.
22.
▲
by
midrus
4y ago
This is so common, sadly. I've seen this happen a lot. And those geniuses advocating for these insane infrastructure usually leave the company after they scratched their itch with kubernetes or whatever they were interested in playing
23.
▲
by
midrus
4y ago
You are confusing parallelism with concurrency. It definitely can be a problem.
24.
▲
by
midrus
4y ago
I love the simplicity and how clean it looks. There should be more websites like this. Congrats.
25.
▲
by
midrus
4y ago
This guy maths
26.
▲
by
midrus
4y ago
Maybe they couldn't agree on the frontend framework to use. Not entire companies, but I've seen projects fail because of this or some similar decision paralysis
27.
▲
by
midrus
4y ago
Have you tried Unpoly? It's like htmx but more "high level". I've used it for several projects and it is one of the more underrated tools out there. On my latest project.im using it in combination with Alpine.js on a Lar
28.
▲
by
midrus
4y ago
>If your other option is Django/Rails/etc: it is like Rails, but integrates better with the frontend. And worse with the backend. Let's not pretend running code in the server are issuing queries to a database is all you do
29.
▲
by
midrus
4y ago
This is why these new "Rails killers" are a huge risk. Unexpected U turns every now and then. I wouldn't trust any of them for a real life project at work.
30.
▲
by
midrus
4y ago
Regarding to hidden complexity, the complexity is there. You either deal with it yourself or rely on the "magic" of the framework to do it for you. I prefer the latter.
More ›