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 server-side)? I don't see the actual argument...just an interview. Too bad, because I think that this is a very important discussion in the industry today.
Elbowing JavaScript out
11–20 of 100 posts
Re: Elbowing JavaScript out
#12So his solution is, to do everything on the server.
Great.
Re: Elbowing JavaScript out
#13From 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.
Re: Elbowing JavaScript out
#14The page loads, then, afterward, you tell some scripts in the footer to observe the presentation in this pristine state, then to go around and mess about with it.
This is why with React-style views[1] I feel like I'm finally learning how to write web applications. The DOM is always in a pristine state.
[1] Specifically I'm using Mithril, but the architecture is the same in React, and similar now in Ember.
Re: Elbowing JavaScript out
#15This seems to me like someone realizing they've been using JS in really terrible ways and trying to stop that by just forcing themselves to not use JS at all. It's not JS's fault that people use it in terrible ways.
One page web apps aren't inherently bad, and neither are sites that don't use JS. It depends on what you're trying to accomplish. You can write a bad site with JS you can write a bad site with no JS.
I think the problem that this developer's "No JS" approach is forcing her to solve is the problem of not thinking through your architecture enough. By saying "I will not use JS", she is forcing herself to put more thought into how things are implemented and that's always going to result in something better than if you just slap something together.
But I think it's a mistake to think that JS is the problem.
Re: Elbowing JavaScript out
#16The worst part of JavaScript is that the relevant committee is simply failing to acknowledge that there are lots of bright computer language designers out there who'd love to have a chance to bring their creations to the web.
How does WebAssembly not acknowledge that?
No support for multiple returns, for one
Re: Elbowing JavaScript out
#17Re: Elbowing JavaScript out
#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 time. Now consider that we use a client-side application which only lives in the browser and contacts an API to confirm authorization to x, y or z. We not only decreased the load time of the site, but also allow everything to be done on their machine and not my server. My bottleneck becomes the my clientside logic and then the CDN I'm ruining my site thru. Mind you I can now have my CDN cache my site because everything is done on the client.
There might be problems and flaws with javascript, but disregarding a language just because of the server side pattern isn't right.
I'd like to see some implementations you've done that are better alternatives to using javascript.
Re: Elbowing JavaScript out
#19We can only hope more people lose javascript. Please ?
Re: Elbowing JavaScript out
#20This seems to me like someone realizing they've been using JS in really terrible ways and trying to stop that by just forcing themselves to not use JS at all. It's not JS's fault that people use it in terrible ways. One page web apps aren't inherently bad, and neither are sites that don't use JS. It depends on what you're trying to accomplish. You can write a bad site with JS you can write a bad site with no JS. I th…
If you, or more likely, your organization, does NOT want to learn / use Javascript, then this probably IS the way to go.
Not my cup of tea, but for many real world organizations, they have to restrict the scope of what the group will do to avoid chaos. Yes, this makes me sad, but it is what it is.