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

91–100 of 100 posts

Re: Elbowing JavaScript out

#91

Post by bobwaycott »

cpeterso wrote: post #65
drewpc wrote: post #11

I think I understand that this article was trying to represent an interview of someone who is successfully creating complex web applications without JS, but it was written as though all of the readers already understand how to do this. Where's the "why" and "how" behind this? What's the advantage of leaving out JS? How do I do client-side interaction without it (the interview seems to imply that we do everything serv…

For example, the article references "OTP" but doesn't define it. Is this Erlang's OTP? Apparently it is because Cowboy is an Erlang HTTP server.

Could it be any other OTP in context? That was right after mentioning Phoenix, wasn't it?

Re: Elbowing JavaScript out

#92

Post by roywiggins »

beaker52 wrote: post #23

"Don't use JavaScript if you don't have to." Sound advice But the article subject seems quite proudly dogmatic about avoiding it altogether but then goes ahead and scores this major own goal: > Regarding worst hack. That’s a hard one. In one of my javascript-free projects, I couldn’t figure out how to embed a realtime graph. In the end, I went with a 3rd party API solution, who probably do use javascript on their end…

Plus, there's a pretty easy way to do a realtime graph without javascript. You just embed it in an iframe; the iframe page needs a meta refresh tag for every few seconds.

Or abuse GIFs:

https://github.com/jbochi/gifstreaming

Re: Elbowing JavaScript out

#93

Post by bobwaycott »

azag0 wrote: post #33

To me as someone who writes a simple web app in Flask from time to time, web with and without JS feels like two orthogonal approaches. Without JS, you're just wrapping your data on the server in some nice html and sending it to render. With JS, you're building a client-side app that is using your server API to get the data and render it.

As someone who writes complicated apps with Flask from time to time, I like the approach of using JS merely to request a resource, rendered by the server, and replaced wholesale on the DOM.

Re: Elbowing JavaScript out

#94

Post by lhorie »

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…

There definitely are lean frameworks around. Mithril.js is a good example, being small and standalone itself, and having inspired several spin-off projects that share the philosophy of having simplicity as a goal.

Re: Elbowing JavaScript out

#95

Post by moron4hire »

cpeterso wrote: post #65
drewpc wrote: post #11

I think I understand that this article was trying to represent an interview of someone who is successfully creating complex web applications without JS, but it was written as though all of the readers already understand how to do this. Where's the "why" and "how" behind this? What's the advantage of leaving out JS? How do I do client-side interaction without it (the interview seems to imply that we do everything serv…

For example, the article references "OTP" but doesn't define it. Is this Erlang's OTP? Apparently it is because Cowboy is an Erlang HTTP server.

OTP means Online Transaction Processing. It's a fancy name for "no caching, no data warehouse, we do everything live."

Re: Elbowing JavaScript out

#96

Post by xellisx »

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…

Well 10 years ago, actually just a couple years before is when it started to sprout wings and mature. Long gone are the days of the "Fun Stuff" that you used to be able to do with JS. Thankfully Active Script died.

Re: Elbowing JavaScript out

#97

Post by wtbob »

Roboprog wrote: post #21
geggam wrote: post #19

We can only hope more people lose javascript. Please ?

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.

> Javascript is a great language.

I think you must be suffering a misunderstanding about the meaning of one of those words. JavaScript is a hideous, misdesigned, sad and ultimately embarrassing language. It's hideous: curly brackets and hieroglyphics galore. It's misdesigned: insane type conversions & implicit declaration — and don't even get me started about ===! It's sad: Eich originally wanted to build a Scheme; while I'm no fan of Scheme (at all: frankly, I hate it), that would have been a noble and good project; instead, we're left with a pathetic might-have-been perversion of good intentions. It's an embarrassing indictment of our entire industry that JavaScript is successful.

It has one virtue: it exists everywhere.

Re: Elbowing JavaScript out

#98

Post by wtbob »

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.

> 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.

Why not make the REST API the rendered API? Just render state to HTML instead of to JSON or whatever.

> SPA with client side JS will not have this problem.

Won't it? If the SPA wasn't designed to be RESTful, trying to graft a REST interface onto the backend will be a horrid exercise (albeit an opportunity for Learning).

Re: Elbowing JavaScript out

#99

Post by m4nu »

>the fact that it lives in the web stack right next to the presentation layer, really sucks (I think)

I can't see by what logic the interviewee arrived to this conclusion. How is the presentation logic out of place in the presentation layer? Modern API/consumer based architecture make way more sense than having MVC structures where business logic, storage logic and presentation logic intertwine.

Re: Elbowing JavaScript out

#100

Post by Roboprog »

wtbob wrote: post #97
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.

> Javascript is a great language. I think you must be suffering a misunderstanding about the meaning of one of those words. JavaScript is a hideous, misdesigned, sad and ultimately embarrassing language. It's hideous: curly brackets and hieroglyphics galore. It's misdesigned: insane type conversions & implicit declaration — and don't even get me started about ===! It's sad: Eich originally wanted to build a Scheme; w…

I don't know what your "language of choice" is, but here in the Sacramento area, the selection of languages which there are jobs available to be worked is somewhat limited.

Yes, ES/JS suffers from its "look like Javascript/C++/C" * heritage, courtesy of the usual suspects from a marketing group. But get past the cosmetics, and you can do some nice FP things with ES/JS.

* I'm in the camp that Modula / Delphi were MUCH better language(s) than C. But few groups were hiring for those skills back in the day - C and its spawn won out, sadly. At least C++ is pretty much dead outside of the video game industry. Good riddance.

Post reply on HN