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

Server-side rendering is a better choice for many applications (2020)

timr.co

Post reply on HN
Print view View original

61–70 of 286 posts

Re: Server-side rendering is a better choice for many applications (2020)

#61

Post by dools »

chrisco255 wrote: post #51
dools wrote: post #42

Earlier quoted context omitted.

To which I would of course reply that they are not money ;)

To which I would reply that money is defined by three properties: 1. Store of Value 2. Unit of Account 3. Medium of Exchange Of which it's fair to say that several crypto currencies fit that bill.

I disagree with that definition of money. I don't think it actually defines what money is or what it does. I think that if you want to think of money in terms of "value" that rather than a "store" of value, it is a "record" of value.

If you want to think of it as a unit of account, it has to be a state unit of account in order to actually function as money.

And finally I think that the function of money as a medium of exchange is actually a side effect; that is to say that money is the most liquid asset because it is created by an obligation in common to all citizens of a sovereign entity. As such, it is the most likely medium of exchange because it is universally accepted.

However, anything can be a medium of exchange. Hot rocks can be used to heat a room, but you wouldn't call a pile of hot rocks a heater. In the same way, virtually anything can be a medium of exchange, but money (by virtue of being created by the imposition of a tax liability) is the most effective medium of exchange.

My definition of money is: a credit that can be used to extinguish a tax liability imposed by a sovereign. Everything else is a commodity.

Re: Server-side rendering is a better choice for many applications (2020)

#62

Post by datastack »

DarkNova6 wrote: post #59
datastack wrote: post #46

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…

> I'm glad we now have things like single page apps and client site interactive applications, because some apps were really not possible with server side rendering And maybe server side rendering is just the right answer for websites which are not the two you mentioned.

that's the point, glad you understood

Re: Server-side rendering is a better choice for many applications (2020)

#63

Post by superb-owl »

The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice).

I don't think CSR is going anywhere, mainly thanks to Conway's Law.

Re: Server-side rendering is a better choice for many applications (2020)

#64

Post by ninkendo »

nvm0n2 wrote: post #32
dools wrote: post #13

First I’ve heard of this interview question but if anyone is wondering here is a guaranteed way to fail a job interview with Thiel by answering the question thusly: Money has never existed without taxation

He would undoubtably respond with, "What about cryptocurrencies?".

Try investing in them and not paying taxes on the gains, and see what happens.

Re: Server-side rendering is a better choice for many applications (2020)

#65

Post by dools »

bradleyjg wrote: post #48
dools wrote: post #13

First I’ve heard of this interview question but if anyone is wondering here is a guaranteed way to fail a job interview with Thiel by answering the question thusly: Money has never existed without taxation

I’ve never met the man, but in my experience with more locally famous/infamous people with roughly similar reputations is that there are few things they love more than a really strong intellectual sparring partner. Of course many boring posters on HN will never accept that because their models of the world only allow for 1 dimensional villains on the other side of any ideological disagreements.

Maybe you've never tried to tell a tax-is-theft libertarian that money only exists as a result of taxation.

Re: Server-side rendering is a better choice for many applications (2020)

#66

Post by mattgreenrocks »

mg wrote: post #50
ransackdev wrote: post #43

Earlier quoted context omitted.

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…

You don’t want to deal with ... Well, I do all that and it works just fine for me. All my projects are 100% my own code down to the core. No frameworks, nothing. There might be some traces of jquery in there from when browsers were more unreliable. I don't even use that these days. To get to know those frameworks, I built some projects with Symfony, Laravel, Django and some others. But it didn't stick. They are too a…

I’ve yet to find a framework that I really like. Ironically, most Python frameworks feel like they force way more coupling on your code than necessary, which is awful considering they are a dynamically typed language. So it feels like the worst of all worlds: Python performance, high coupling to something you don’t control, and dynamic typing.

I understand why these are designed that way, but also don’t enjoy using them. Frameworks can feel very narcissistic in that sense, all the code is about them, despite their promise that you’ll focus on your domain more.

I need to play with some of the Kotlin web libraries more, such as ktor or Javalin. There has to be something better out there.

Re: Server-side rendering is a better choice for many applications (2020)

#67

Post by kmeisthax »

chrisco255 wrote: post #51
dools wrote: post #42

Earlier quoted context omitted.

To which I would of course reply that they are not money ;)

To which I would reply that money is defined by three properties: 1. Store of Value 2. Unit of Account 3. Medium of Exchange Of which it's fair to say that several crypto currencies fit that bill.

Which ones? Every crypto that gets any amount of usage immediately hits up against deliberate scaling limits in the consensus mechanism[0] and stops being a useful medium of exchange. Cryptocurrency also has extreme speculative risks, which means that it's useless as a unit of account or a store of value.

Fiat currencies don't have these problems[1]. Because they are instituted by a government that forces people to use it, they have a large volume of economic activity which makes it harder for the currency to swing dramatically in value. The reason why Bitcoin can fluctuate so wildly is because few actually use it like a currency, so there's nothing to buffer against market manipulators and forex speculators.

[0] Because crypto needs global consensus over every satoshi in the system, all transactions need to be widely propagated to all full nodes, which imposes strict limits on how much transaction data can be processed at once. If the limits are too high then only large institutions can run full nodes which is centralizing.

Of course, literally everything else in crypto is centralizing, because centralization is the gravitational force of economics.

[1] No, Zimbabwe doesn't count.

Re: Server-side rendering is a better choice for many applications (2020)

#68

Post by joenot443 »

chrisco255 wrote: post #49
mg wrote: post #34

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…

Do they have a good success ratio? Do you have some data to back that assertion up where you've analyzed startup success by whether they used SSR or CSR? My own personal experience has been working at a large enterprise SSR app that ultimately failed to keep pace with increasing competition (but certainly achieved some success with basic SSR forms in the early 00s), then later worked for a team that had a $500M exit…

I'd be pretty surprised if someone had gone to the effort to organize startups by SSR and CSR and then tried to make an empirical point with it. Just seems like a fool's errand to me, too much noise to get a useful signal.

I have no doubt someone will bring up levelsio (hey Peter!) and his slew of wildly successful sites SSR sites powered by JQuery and PHP, but I've always felt his stack choice was secondary to his ability to market and quickly ship.

It's a bit of a truism, but I've really come to accept these days that the best stack is whichever one your team is most productive with.

Re: Server-side rendering is a better choice for many applications (2020)

#69

Post by pragmar »

ransackdev wrote: post #54
mg wrote: post #50

Earlier quoted context omitted.

You don’t want to deal with ... Well, I do all that and it works just fine for me. All my projects are 100% my own code down to the core. No frameworks, nothing. There might be some traces of jquery in there from when browsers were more unreliable. I don't even use that these days. To get to know those frameworks, I built some projects with Symfony, Laravel, Django and some others. But it didn't stick. They are too a…

How’s your vulnerability reporting process and how much experience do you have interpreting complicated pen tester bug reports about some buffer overflow zero day in your homebrew query string parser? Huge difference between working fine, and working right. The security implications of rolling your own, is why I say “you don’t want to…” Also, none of that code has anything to do with the product you’re actually tryin…

In the aughts, when everyone was rolling their own framework, security and maintenance were a nightmare. It's undeniable. We traded one problem for another, however, and we've gone too far. I think the question at hand is which is more secure/maintainable: 10kb of custom utilities or 100mb of mystery-meat modules that, let's face it, will never be reviewed. It's not a simple answer.

Re: Server-side rendering is a better choice for many applications (2020)

#70

Post by grumblingdev »

mg wrote: post #34

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…

100%.

People get so intimidated by these huge frameworks and get FOMO, that they never try to build something from scratch.

React seems simple, but if you tried to understand what is going on under the hood it would take you months.

Simple should be: can you trace through all the code yourself. Like Backbone.js for example.

Plus, there is already so much rendering complexity under the hood in browser engines. The DOM and CSS are already incredible abstractions available for you to use.

I really don't get what is so bad about just having some object to manage a dom element's rendering.

Create a single relational source of truth for your data. Then create some view models that listen to this source of truth. Then make your objects listen to these view models.

This vdom diffing stuff is so overated.

If you have a list of items, and a new item is inserted, I can just insert that directly into the dom. If I render a different entity and it uses mostly the same dom elements, it's really not that hard to tell say: here are some new props, compare them with your old ones, and do what you think is best. React promises this for the entire app but its all magic. I want control of my rendering so I can make things fast. Debugging perf issues in React is insane. Good luck debugging anything.

Post reply on HN