Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
simonhamp
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
61.
▲
High Performance SQLite
(highperformancesqlite.com)
5 points
by
simonhamp
2y ago
|
0 comments
62.
▲
DirtMatch: Got dirt? Find folks who need it
(dirtmatch.com)
1 points
by
simonhamp
2y ago
|
0 comments
63.
▲
Show HN: NativePHP Now Supports Windows
(github.com)
4 points
by
simonhamp
2y ago
|
0 comments
64.
▲
Show HN: Whizzy – build Laravel apps in seconds with AI
(whizzy.dev)
4 points
by
simonhamp
2y ago
|
0 comments
65.
▲
Pinkary: Like Linktree, but Better and Free
(pinkary.com)
1 points
by
simonhamp
3y ago
|
0 comments
66.
▲
by
simonhamp
3y ago
And yet Conway's Law still holds up surprisingly well One way or another, your app reflects the org chart. So either you force the split because of your architectural choice or it happens because of your org structure One way or anothe
67.
▲
by
simonhamp
3y ago
Yeh... and if you've got iOS and Android covered, then web is a different thing. Doesn't need to be an SPA, can still use those same APIs if that makes sense for your app
68.
▲
by
simonhamp
3y ago
Sure. But we're talking about needing the same API for two separate clients... That infers building both and I'm questioning why you would build both if they're identical. Just build one and get your users to use it
69.
▲
by
simonhamp
3y ago
If you're building an SPA that's identical to a native app, I think someone in the exec team is making poor decisions Either make a web app or a native app... don't do both
70.
▲
by
simonhamp
3y ago
Yeh I've seen some of those as SPAs... ouch Honestly, I'd rather not be presented with an empty grid of spinners tbh I think you can get something useful on first render and then dynamically update from there (either with polling,
71.
▲
by
simonhamp
3y ago
You're absolutely correct. Thanks
72.
▲
by
simonhamp
3y ago
Because they were entirely different applications. It was an API platform for a suite of applications There was almost zero crossover in functionality
73.
▲
by
simonhamp
3y ago
You can get offline support without an SPA. Of course, that may mean replicating some of your back-end behaviour in JavaScript, but that doesn't necessitate building an SPA, or the whole app in JS. Please do share which crappy SPAs you
74.
▲
by
simonhamp
3y ago
Thanks for the feedback. I will try to make this clearer in the article. While I state later that true decoupling isn't technically possible, it really only makes sense (to me) to attempt it when you've got larger teams split down
75.
▲
by
simonhamp
3y ago
> Secondly, if you can’t build a system that actually decouples the frontend and the backend, that’s a “you” problem, not a technology problem. You're right it's not a tech problem... it's a logistical impossibility. It is
76.
▲
by
simonhamp
3y ago
I'm a freelance consultant and a human person. I advise companies, especially early-stage startups, on this stuff. I'm writing about what I see, which is hundreds of hours being wasted on triaging bugs, meetings trying to align sm
77.
▲
by
simonhamp
3y ago
You still don't need an SPA for this
78.
▲
by
simonhamp
3y ago
I don't think this has anything to do with design tbh. You have developers who are comfortable with HTML/CSS/JS and those who prefer to stay clear of it. A lot of those HTML/CSS/JS folks happen to also really enjoy
79.
▲
by
simonhamp
3y ago
I've done this. I spent six years building and maintaining an API platform to support apps and websites. I'm fully aware of mobile and the need for those APIs. They just weren't sufficiently overlapping to be of any use to an
80.
▲
by
simonhamp
3y ago
Thanks for the feedback. Noted
81.
▲
by
simonhamp
3y ago
Can you give an example?
82.
▲
by
simonhamp
3y ago
No shaming intended. This is not meant to be applied retrospectively. I believe now that an SPA is unneeded, precisely because of how far the technology has come. And I believe that SPAs are the cause of a lot of that advancement and have
83.
▲
by
simonhamp
3y ago
All rendering, ultimately, is client-side. That's inescapable. So whatever mechanisms you choose to make adaptive designs, lower your throughput and account for slow networks can be done without an SPA.
84.
▲
by
simonhamp
3y ago
You can have great front-end experiences and great front-end-back-end developer relations without an SPA
85.
▲
by
simonhamp
3y ago
Really pleased that you've found a way to make it work. But do you need it?
86.
▲
by
simonhamp
3y ago
I feel like a lot of the commenters here have missed the point... in the title it says you shouldn't start with an SPA. I never say "don't ever use an SPA," just that I feel—more strongly than ever—that the kinds of en
87.
▲
You Shouldn't Start with an SPA
(simonhamp.me)
46 points
by
simonhamp
3y ago
|
128 comments
88.
▲
by
simonhamp
3y ago
`ssh ssh.resume.joe.codes` a TUI resumé
89.
▲
Interactive Resumé: SSH Ssh.resume.joe.codes
3 points
by
simonhamp
3y ago
|
1 comments
90.
▲
by
simonhamp
3y ago
The OG is an opinionated image generator that does away with the need for building a HTML template and installing a headless browser. It's for those times when all you want is to generate a decent-looking, dynamic image in milliseconds
More ›