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

41–50 of 100 posts

Re: Elbowing JavaScript out

#41

Post by hhsnopek »

binarymax wrote: post #25
hhsnopek wrote: post #18

(Not using javascript) This is a terrible move, consider this: Your web stack has many moving parts that can be adjusted on both client and server side. Now from what I'm getting from the article, all my websites are server side apps. This means I must run a server that I need to factor in scaling and performance. I need to know what my bottleneck is, which will likely end up being what I'm rendering at almost live t…

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 the solid performance you began at.

Re: Elbowing JavaScript out

#42

Post by PaulHoule »

Roboprog wrote: post #30
hhsnopek wrote: post #18

(Not using javascript) This is a terrible move, consider this: Your web stack has many moving parts that can be adjusted on both client and server side. Now from what I'm getting from the article, all my websites are server side apps. This means I must run a server that I need to factor in scaling and performance. I need to know what my bottleneck is, which will likely end up being what I'm rendering at almost live t…

This, minus the CDN - using compression and static file caching headers, only - is how we are handling a major app upgrade (pretty much a rewrite) at work. Of course, I flip flopped from hating Javascript to really liking it about 10 years ago. Now after having done most of my work in JS (plus Angular 1) the last year, I can't stand working in Java any more. So much blah blah blah to do anything on the server (since…

Sometimes CDNs seem like a scam to me.

I have been building "insanely fast" apps based on HTTP/2 and everything local. My experience is that every DNS lookup you add is a chance for somebody's web browser to go out to lunch for an unbounded interval. (Back when we got DSL in my neck of the woods, web browsing often was slower on DSL than dialup because the DNS service was so bad.)

As for the back end it is a matter of having a framework that works.

Unfortunately Sun, Microsoft and most legacy vendors have a history of hiring systems programmers instead of application programmers to develop frameworks, so the average back end framework is seriously flawed. For instance, Web Forms in .NET were a great idea, but had the fatal flaw that they did not work in an MVC environment where you might want to load a different template depending on the outcome of form processing.

Instead of fixing this, they build a new MVC framework that didn't learn from the mistakes of the last framework...

Re: Elbowing JavaScript out

#43

Post by ramy_d »

binarymax wrote: post #25
hhsnopek wrote: post #18

(Not using javascript) This is a terrible move, consider this: Your web stack has many moving parts that can be adjusted on both client and server side. Now from what I'm getting from the article, all my websites are server side apps. This means I must run a server that I need to factor in scaling and performance. I need to know what my bottleneck is, which will likely end up being what I'm rendering at almost live t…

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…

I think its a great idea to consider, a fresh perspective, especially when you consider how slow some sites can become for mobile users. Offloading trivial JS to the server and leveraging CSS/HTML, which would be better optimized on those devices, could be something to look into. Especially when you consider how slow some sites get on mobile just because of the JS they run.

I'd like to see a trivial app implemented in JS and then re-implemented using Dala's method.

Re: Elbowing JavaScript out

#44

Post by Scarbutt »

Regarding SPAs, is it worth it (besides learning purposes) if you are just writing a web interface/front end in the same level of complexity as github? github not being a SPA works pretty well and lots of it users like it (I know it adds javascript to some parts to enhance the experience).

Re: Elbowing JavaScript out

#45

Post by Roboprog »

drubio wrote: post #22

It's pointless to be a contrarian on JavaScript. It's here to stay, but it does appear there's a big push to be able to write something other than plain JavaScript (that produces JavaScript) to bring more sanity to the development process. That Microsoft is pushing a superset that produces JavaScript ( https://www.typescriptlang.org/ ) and Google is also behind Dart ( https://www.dartlang.org/ ) that produces JavaScr…

Hope that works for you (GWT sure didn't)

I'll be just a wee bit contrarian on this, as I started out in my career using a more or less dynamic language in the mid 80s (despite being schooled in Pascal and later, C, which deserves its own discussion).

"Better type-checks interestingly found only just a few bugs" - https://jaxenter.com/angularjs-interview-angular-2-typescrip...

I greatly appreciate the brevity of the JS code itself, though I do freely litter my code with JSDoc (or JavaDoc, on the back end) comments. Short code, long comments. Please, WWW entities, DON'T make JS into a Java-like, OOP only, monstrosity.

I seldom write real classes in JS. Its amazing what you can do with currying. Supply first few data args - don't need a constructor/setter(s) to configure a "one trick pony" class. Pass in and pre-bind a few function args - don't need an abstract base class. Wrap a function around an existing function - emulates OOP aspect orient programming.

I forgot to add, at least one IDE vendor, JetBrains IntelliJ (or Webstorm) does an excellent job of inferring types in Javascript, as is, and much of the autocomplete; find definition / usages; refactor stuff works just fine without jacking up the language.

Re: Elbowing JavaScript out

#46

Post by CalmStorm »

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.

Re: Elbowing JavaScript out

#47

Post by binarymax »

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…

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 renders everything on the server (in a dialect of Lisp!) and it's a pretty small cluster that is supporting more users than most webapps dream of.

Re: Elbowing JavaScript out

#48

Post by PaulHoule »

binarymax wrote: post #13

From what I gathered, the gripe is not with the JavaScript language itself, but the "thick-client" web app. The thick vs thin client trend cycle has already happened twice. When your network and servers are fast enough so everything can happen on the backend, it becomes a philosophical debate.

It's not just that.

It's possible to write a thick client which is reasonably lean, but to do that you have to plan and be careful about your dependencies. Most people aren't, and that is why it can be a 30MB load for some apps that could be done in a 300kb load.

Back end apps can be made insanely efficient in terms of how much data they transmit (lean HTML, lean SVG, etc.) and how fast they process data. You are forced into the model of "user clicks, send back one update" which has limitations, but also has the advantage that you don't get the massive number of round trips that happen in thick apps that are not carefully engineered.

Re: Elbowing JavaScript out

#50

Post by gedrap »

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 actually significantly improve the user experience. Imagine if the whole comments thread on HN reloaded every time you wanted to vote on a comment. That wouldn't be great. Tools such as google docs wouldn't even exist, really.

That being said, amount of JS at HN looks pretty great to me. Not much point to use it for posting replies (just open in new tab), but really helps with the voting. I'd rather take this approach than avoiding JS just for the sake of it.

[0] Except just out of curiosity, but they were talking about client work in the post so let's continue with it.

Post reply on HN