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

71–80 of 100 posts

Re: Elbowing JavaScript out

#71

Post by smadge »

hhsnopek wrote: post #41
binarymax wrote: post #25

Earlier quoted context omitted.

Not using javascript is not a terrible move by default. In fact, I can think of many cases where it would drastically simplify things. A stateless resource model with a distinct separation of concerns and components, that operates in a non-CPU-intensive fashion, can make life much easier on your designers and testers. When serving things like content and straightforward CRUD, your architecture can be made much simple…

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…

Let's think in orders of magnitude here. Will moving template rendering from the client to the server increase server load by an order of magnitude?

I might be wrong here, but if more than half your request is spent in a templating engine, something is seriously wrong.

Moving your code to the client side seems like an incredibly lazy way to shave a few milliseconds off your request time. Not to mention your doing so at the expense of increasing initial page load for the user, and breaking the semantic web.

Re: Elbowing JavaScript out

#72

Post by jordanlev »

I feel like I'm in a bizarro world reading this "interview"... they're just describing web sites before "web 2.0" (around when Google Maps, Prototype, jQuery etc. came along), but talking about it as if it's a new thing.

Maybe I'm missing the joke, except none of the comments here on HN seem to give any indication that anyone is aware that you can build websites without javascript (and in fact that's how most websites were built, and some still are). Everyone's talking like "in the beginning, there was javascript... but now we have these new things called HTML and CSS which let you finally get away from it!"

Re: Elbowing JavaScript out

#73

Post by _greim_ »

_qbjt wrote: post #63

Judging from Ikura's web page as well as the lack of Internet presence and name of the interviewee here (Amy G. Dala... Get it, amygdala?), I'm inclined to think this interview is fake. In any case, I've noticed a tendency to conflate JavaScript with what I'll call "JavaScript abuse". I'm guilty of JavaScript abuse and I'm sure many of you are as well. But to attribute this to any programming language, regardless of…

If a tool encourages bad habits, it is in some sense the tool's fault. On the other hand, overuse of JavaScript isn't encouraged by JavaScript-the-language so much as by how it fits into the overall web platform.

It was an interesting point about SPAs being partially a symptom of god-awful slow backends, fake article or not.

Re: Elbowing JavaScript out

#74

Post by mooseburger »

gedrap wrote: post #50

Why be on the extreme? [0] Programming is very, very often about the balance. I can understand some frustration with thick clients - including the fact that there are so many frameworks being released now and it's hard to decide what to use. But at the same time, taking extreme approaches can be and is hurting the users. For example, Ajax requests (is there a way to do it without JS? Doubt it but who knows) can actua…

Now that you mention Ajax, I don't see where HN does ajax when voting. The only javascript on the page is for hiding the vote icon after voting.

Re: Elbowing JavaScript out

#75

Post by tremon »

binarymax wrote: post #60
hhsnopek wrote: post #53

Earlier quoted context omitted.

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.

Indeed. It does allow you to offload the scalability problems to your users though, and they won't easily tie the draining of their batteries to your site/app.

Re: Elbowing JavaScript out

#78

Post by tyingq »

jordanlev wrote: post #72

I feel like I'm in a bizarro world reading this "interview"... they're just describing web sites before "web 2.0" (around when Google Maps, Prototype, jQuery etc. came along), but talking about it as if it's a new thing. Maybe I'm missing the joke, except none of the comments here on HN seem to give any indication that anyone is aware that you can build websites without javascript (and in fact that's how most website…

Felt the same way. I suppose the article could have cited recent changes in CSS that allow you to eliminate pieces of javascript, but that didn't seem to be the point.

Re: Elbowing JavaScript out

#79

Post by spriggan3 »

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…

JS is evolving so developers want to take advantage of new features while still supporting old browsers, which makes complicated pipelines mandatory. Should developers stick with ES5 instead ? I personally like using classes instead of prototypes as it makes my code more readable. fortunately I can develop with a browser that supports a lot of ES6 features so the pipeline is only mandatory for staging,testing on old browsers and production.

Next working with Raw DOM nodes when you have to develop a complex single page app isn't really efficient. You need a way to write reusable components, these components need to be composite, and need to take care of their own life cycle ( registering, unregistering event listeners,...) . So basically it means creating a component system on top of the DOM. The DOM wasn't created to build complex applications, therefore it needs to be abstracted in some ways.

The alternative is to do everything on the server, and fetch HTML fragments to update the page through ajax when a specific event is dispatched. Sometimes that solution scales, sometimes it doesn't.

ES6 by the way makes working with the DOM a bit easier, and ES6 modules will help developers moving away from monolithic frameworks.

Re: Elbowing JavaScript out

#80

Post by BFatts »

It's never about it being "better," it's only about it being "different." In a world of cookie-cutter web devs, how does one stand out? By trying something difficult, succeeding, and then saying it's the "better" way. Same reason we have so many damn programming languages - they each claim to do something the "better" way.
Post reply on HN