91–100 of 286 posts
and before you black and white nerds jump on me, Im not talking about biotech and healthcare!
Earlier quoted context omitted.
He would undoubtably respond with, "What about cryptocurrencies?".
Try investing in them and not paying taxes on the gains, and see what happens.
Earlier quoted context omitted.
Ad-Hom is generally frowned upon in this establishment.
I mean it's not really as hominem is it? I'm not arguing the point at all. I just mean that invoking a controversial like Thiel for something as reasonable as discussing the merits of server side rendering is a very odd choice.
> users would prefer your app as a website I hope by app you mean "webapp", because I sure don't want all my apps becoming websites. That's how Electron becomes more prevalent. Also, great to see a shout-out to D :)
> What important truth do very few people agree with you on? Seems like answering with SSR would fail a Thiel interview for two reasons: 1. It's not important (in the grand scheme of things) 2. It's not a view that very few people hold. SSR was the standard way to do things for a couple of decades up until frameworks like React, and React itself now implements SSR, doesn't it? Thiel uses this question to try and dete…
SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a surface that is small.
Whether you're doing server rendering or client rendering, you need to separate markup from business logic. Modern architecture fashion tells us that we need to use micro services. So even if I generate markup on the server, I need to talk to micro services using HTTP to get data. So the question is: which technology provides best tools for writing server-side rendering module? My wishes: 1. Strict-typed language. 2.…
I can only hope that this is satire
Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack. It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering n…
There is an echo chamber where this happened:
* Facing massive datacenter costs, Google and Meta realized that if they could hand off rendering to the client, they could have smaller datacenters and save a lot of money. Things like React and Angular were born. Other companies with large datacenter costs followed suit, many monies were saved.
* This is when things started to get a little crazy. VCs started pushing heavy client-side SPA this and that because if anyone knows how to cargo cult, it's VCs. Devs started pushing it because it was a hard way to do things and if anything improves your salary, it's being involved with the hard bleeding edge stuff. Also inventing another JS framework turned out to be a great way to pad your resume. Design and UX people realized this was a whole new can of worms they could get paid to open, and dug right in. (In all cases note that the original point, saving money on compute at massive scale, was totally lost, and people just made up new reasons.)
* Outside of this echo chamber which is utterly convinced it's filled with the smartest people in tech, life has actually gone on pretty normally for the rest of us, we're still doing stuff on the server whenever we can, and caching the hell out of everything we can, and being judicious with fancy client side frosting because complexity is generally the enemy. That said, it's definitely true that an entire generation of young web developers has been lost to madness because young web developers also like to cargo cult a lot, and the damage will take years to repair.
But yeah, not really a Thiel truth
> What important truth do very few people agree with you on? Seems like answering with SSR would fail a Thiel interview for two reasons: 1. It's not important (in the grand scheme of things) 2. It's not a view that very few people hold. SSR was the standard way to do things for a couple of decades up until frameworks like React, and React itself now implements SSR, doesn't it? Thiel uses this question to try and dete…
I honestly wonder if everything that is a best practice on the backend and frontend these days is a net negative compared to "Write your own PHP or Python code which outputs your own HTML+CSS+JS". Especially for indiemakers and startups by technical founders. All the frameworks add so much complexity and confusion. And I have seen several startups fail because when the developer was confronted with breaking changes o…
I’ve rolled my own mvc framework before, In php even! This was years ago when CakePHP was the new hotness and Laravel didn’t exist. Take it from someone who had your mentality and set off to make a tiny and no bs mvc that just gets the job done, the amount of work these frameworks are doing for you (backend frameworks) that you don’t consider, is why you should run a framework. You don’t want to deal with processing…
The Golang stdlib does all this for you, no framework needed :)
I honestly think Golang SSR with html templates + a sprinkling of Javascript to enhance is an extremely pragmatic way to go.
You build your entire service into a single binary (assets included with go:embed).
You shed the complexity of the framework AND the web server AND deployment in addition to React etc.
> It's cheaper > You will need a backend anyway. It'll need to expose data to users. Exposing it as HTML is no harder than doing it via JSON or GraphQL Sure, if your "app" is just buttons and UI that interacts with a backend DB, I agree. However, many PWAs and native apps do lots of heavy lifting on the client side, and loading the backend with that is not cheap at all!
Yeah, I don't get how it'd be cheaper at all. Yes you need a backend anyway, but unless you're not paying for usage and have spare CPU cycles and bandwidth available, it's not cheaper. It's cheaper to send your frontend html+js and let the browser cache it so it's only sent once, and let the frontend pull only the data it needs to render the html. The backend isn't having to process a template, or resend similar html…