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

81–90 of 100 posts

Re: Elbowing JavaScript out

#81

Post by gedrap »

mooseburger wrote: post #74
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.

It's conventional way of doing it, but:

var ping = new Image(); ping.src = node.href;

Technically, it might not be called ajax but the point is the same.

Re: Elbowing JavaScript out

#82

Post by underwater »

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…

The article is specifically talking about web apps, not web sites. This usually assumes interactivity based on user interaction, which JavaScript certainly makes easier.

I don't know the specifics of the web app in question. But from the interview it sounds like a case of replacing fixation on one tool with another. For example she describes server generated HTML as a "pristine state."

No, JavaScript shouldn't be used for everything. But sometimes it is better than trying to abuse other technologies to do things they shouldn't do.

Re: Elbowing JavaScript out

#83

Post by hhsnopek »

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.

You're correct, as it does not grant scalability. Tho if my application lives on the client-side, I can distribute the cached application which contains all the user needs. This provides less worry when my server crashes and will still allow my users to access and use my site. Tho will fail if my API's are not accessible. Which then comes down to identifying and breaking the bottleneck. CDN's can also help with my scaling as I can just distribute the bundled up version and live beyond internet access so long as I've built application to be progressive (https://developers.google.com/web/progressive-web-apps) I can now just notify my application to update next time the user connects to the internet. Tho if my application where to only live with the server rendering my information, I wouldn't be able to periodically lose my "stable" connection and my application would be rendered useless.

Tho this solution is adaptable to server-side applications, you'll need to use javascript to do so. And I believe that settles why we need javascript in your applications. If I can't access your sever-side application because it's flooded with requests and the cached version of your site relies on the server then I believe you've failed your users.

The solution to scalability for both server-side and client-side applications are complex, but only one of them depends on a server being around while the other relies on a cached copy.

Re: Elbowing JavaScript out

#84

Post by roywiggins »

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…

I had the same thought. "Oh, we're rediscovering forms and iframes then?" Code like it's 1999! Not that that is a bad thing, but it is kind of funny to see.

Re: Elbowing JavaScript out

#85

Post by roywiggins »

underwater wrote: post #82
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…

The article is specifically talking about web apps, not web sites. This usually assumes interactivity based on user interaction, which JavaScript certainly makes easier. I don't know the specifics of the web app in question. But from the interview it sounds like a case of replacing fixation on one tool with another. For example she describes server generated HTML as a "pristine state." No, JavaScript shouldn't be use…

The "basic HTML" version of GMail still exists, it barely uses Javascript[1]. That counts as a webapp, right? That's how email "apps" worked on the internet for a decade before the one-page-app became feasible and popular.

It looks like crap by current standards, but it works just fine. I wouldn't call its scriptlessness an "abuse" by any means- that's just how it used to be done.

[1] there's a little bit that handles time zones, I think, but that's it... oh, and autocomplete and some alerts to catch you navigating away from an unsaved draft, that sort of thing.

Re: Elbowing JavaScript out

#86

Post by petepete »

JamesBaxter wrote: post #4

Generally I feel if I have a lot of business logic in Javascript than my view is wrong. There are things like client side validation that I don't know how you'd do another way?

Basic client-side validation is possible with HTML5 inputs and attributes, but for anything more involved you need to use JavaScript.

Re: Elbowing JavaScript out

#87

Post by tyingq »

roywiggins wrote: post #85
underwater wrote: post #82

Earlier quoted context omitted.

The article is specifically talking about web apps, not web sites. This usually assumes interactivity based on user interaction, which JavaScript certainly makes easier. I don't know the specifics of the web app in question. But from the interview it sounds like a case of replacing fixation on one tool with another. For example she describes server generated HTML as a "pristine state." No, JavaScript shouldn't be use…

The "basic HTML" version of GMail still exists, it barely uses Javascript[1]. That counts as a webapp, right? That's how email "apps" worked on the internet for a decade before the one-page-app became feasible and popular. It looks like crap by current standards, but it works just fine. I wouldn't call its scriptlessness an "abuse" by any means- that's just how it used to be done. [1] there's a little bit that handle…

There's also a framebuster, and onclick handlers for the search button.

Re: Elbowing JavaScript out

#88

Post by roywiggins »

shoemai wrote: post #31

If I'm on reddit and had to reload the page for every upvote/downvote, comment expand/collapse, show more comments, and reply the ux would be significantly worse. And thats not even a site that has that much user interaction.

You can do async upvoting without Javascript if you abuse a GET request loaded in an iframe. Comment collapse can be done if you abuse CSS and checkboxes.

These aren't really GOOD ideas, but someone who really, really doesn't want to use Javascript has options.

Re: Elbowing JavaScript out

#89

Post by bobwaycott »

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…

So, instead of tackling and solving performance issues with a known resource (your server hardware), the situation is improved by "solving" performance issues/concerns by dumping them on an unknown resource (your users' hardware)? That sounds like an awfully foolish argument and approach to me.

Re: Elbowing JavaScript out

#90

Post by Roboprog »

geggam wrote: post #70
Roboprog wrote: post #21

Earlier quoted context omitted.

Javascript is a great language. Transpiling another language to run on the browser (looking at you , zombie GWT!) will NOT make CSS and event handling any less complex.

not worried about complex... i miss being able to surf the internet on smaller systems than it takes to run entire clouds stacks on

Ah. Gotcha. E.g. - a newsletter doesn't need to be an "app".
Post reply on HN