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

Elbowing JavaScript out

blog.ikura.co

Post reply on HN
Print view View original

51–60 of 100 posts

Re: Elbowing JavaScript out

#51

Post by gedrap »

binarymax wrote: post #47
hhsnopek wrote: post #41

Earlier quoted context omitted.

Right so in reality this works for small applications that have a decent amount of traffic, but your site will soon crumble under the server side rendering of things and you might have to spin up more servers to handle the load. You're implementation is perfect for personal blogs and small applications, but at scale it's going to turn into a hassle of managing the monkey patches and scaling issues while still keeping…

You are making incorrect assumptions that everything is fragile and hard to do. Servers are cheap. Load balancing and caching are easy. It is worth it in many implementations. I worked in a team that supported this type of architecture in a research platform serving thousands of concurrent users with a single server. It scales if you do it right. --EDIT-- I'm going to give you a great example. This very site. HN rend…

Totally. I see this argument about offloading the load to the client so often, that I am left thinking whether I am the only one here working on a project with less than a few thousands of requests every second :)

It's good to have performance and scalability in mind but so often it just doesn't matter.

Re: Elbowing JavaScript out

#52

Post by spriggan3 »

CalmStorm wrote: post #46

Pure server rendering will work for webapp. But if one day the client decides to have iOS/Android apps, the backend will need to be updated to provide Rest APIs. It is possible to do, just additional work. SPA with client side JS will not have this problem.

> the backend will need to be updated to provide Rest APIs

In this day and age of micro-servicing everything, the backend should have a front-end for webpages that uses the same Rest API as mobile devices.

Re: Elbowing JavaScript out

#53

Post by hhsnopek »

binarymax wrote: post #47
hhsnopek wrote: post #41

Earlier quoted context omitted.

Right so in reality this works for small applications that have a decent amount of traffic, but your site will soon crumble under the server side rendering of things and you might have to spin up more servers to handle the load. You're implementation is perfect for personal blogs and small applications, but at scale it's going to turn into a hassle of managing the monkey patches and scaling issues while still keeping…

You are making incorrect assumptions that everything is fragile and hard to do. Servers are cheap. Load balancing and caching are easy. It is worth it in many implementations. I worked in a team that supported this type of architecture in a research platform serving thousands of concurrent users with a single server. It scales if you do it right. --EDIT-- I'm going to give you a great example. This very site. HN rend…

My justification is that not everyone will implement the scaling properly - we do have a lot of server-side apps that properly scale, but depending on the operation it seems the client-side is a better suited pattern

Re: Elbowing JavaScript out

#54

Post by masswerk »

I'm coding JS now professionally for 20 years (so, quite from the beginning) and I love the language.

That said, I think, current frameworks are, with all due respect, rather over-engineered. – A tool chain consisting of at least 8 items, a multiline CLI command to compile a hello world that comes at a mere 19.500 lines of code? (Some may remember when early Java versions were made fun of for a 2MB hello world object code.) I would love to see JS back in its core domain which is / has been (choose your own) real-time interaction. I dare say, we haven't seen much of this lately, at least not in creative and novel ways.

Re: Elbowing JavaScript out

#55

Post by [deleted] »

binarymax wrote: post #47
hhsnopek wrote: post #41

Earlier quoted context omitted.

Right so in reality this works for small applications that have a decent amount of traffic, but your site will soon crumble under the server side rendering of things and you might have to spin up more servers to handle the load. You're implementation is perfect for personal blogs and small applications, but at scale it's going to turn into a hassle of managing the monkey patches and scaling issues while still keeping…

You are making incorrect assumptions that everything is fragile and hard to do. Servers are cheap. Load balancing and caching are easy. It is worth it in many implementations. I worked in a team that supported this type of architecture in a research platform serving thousands of concurrent users with a single server. It scales if you do it right. --EDIT-- I'm going to give you a great example. This very site. HN rend…

[deleted]

Re: Elbowing JavaScript out

#56

Post by balls187 »

badusername wrote: post #32

Could someone link to examples of her work? The article reads as if it's more of a fashionable contrarianism, mostly for the sake of it. I would like to experience her work in detail tho. Sadly, a clever name like 'Amy G Dala' fools google and doesn't turn up anything.

Is the interviewee a real person? My interpretation (based on the name) was that it was a fictitious interview to make a point.

Completely offtopic, Amygdala was the boss that gave me the most trouble in Bloodborne. https://www.youtube.com/watch?v=Njmz1MbwOiM

Re: Elbowing JavaScript out

#57

Post by Roboprog »

ldehaan wrote: post #26

more people complaining about a language they don't understand, js should be more like y language is something I've been hearing for years. it's inane and shows a deep lack of understanding of programming languages specifically, and how computers work in general. I have been writing apps in all js for years now, there are issues with the language as there are with all languages. over all if you spend the time to lear…

CSS? Now that's hard.

I love both the dynamic and functional aspects of Javascript. See my comment elsewhere about currying as a frequent substitute for constructors/setters, abstract base classes and AOP.

Re: Elbowing JavaScript out

#59

Post by gedrap »

masswerk wrote: post #54

I'm coding JS now professionally for 20 years (so, quite from the beginning) and I love the language. That said, I think, current frameworks are, with all due respect, rather over-engineered. – A tool chain consisting of at least 8 items, a multiline CLI command to compile a hello world that comes at a mere 19.500 lines of code? (Some may remember when early Java versions were made fun of for a 2MB hello world object…

But maybe it comes down to the fact that many developers simply like over engineered solutions and sprinkle some complexity to often boring problems? Not saying that it's always the case but surely many of us can recollect related stories :)

Re: Elbowing JavaScript out

#60

Post by binarymax »

hhsnopek wrote: post #53
binarymax wrote: post #47

Earlier quoted context omitted.

You are making incorrect assumptions that everything is fragile and hard to do. Servers are cheap. Load balancing and caching are easy. It is worth it in many implementations. I worked in a team that supported this type of architecture in a research platform serving thousands of concurrent users with a single server. It scales if you do it right. --EDIT-- I'm going to give you a great example. This very site. HN rend…

My justification is that not everyone will implement the scaling properly - we do have a lot of server-side apps that properly scale, but depending on the operation it seems the client-side is a better suited pattern

Straw man. Using a client side approach does not automagically grant you scalability.
Post reply on HN