Elbowing JavaScript out(blog.ikura.co)
blog.ikura.co
Elbowing JavaScript out
http://blog.ikura.co/posts/elbowing-js-out.html
99 comments
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.
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.
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.
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.
I don’t even mind it living in the backend
You lost me there.
You lost me there.
same here, stopped reading after that
The 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
WebAssembly will support multiple-return functions, just not in the very first version.
Assuming you have tuples, does it matter? Python doesn't have multiple returns either, but it fakes them convincingly.
[deleted]
Sorry, what? The relevant committee is a bunch of bright computer language designers, doing the best they can while navigating a maze of legacy, backwards compatibility, community, and bureaucracy concerns with every step they take.
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?
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.
I hate the font on this page.
"I have been wanting to try building a complex webapp that uses nothing but a backend, CSS, HTML5 for a really, really, really, long while"
Coincidentally, I am going in the opposite direction after having written many Python/PHP apps with only a little JavaScript. I noticed on my current project I was writing less backend Python code. Last night I decided I'm going to try building a complex "serverless" webapp using only Firebase and more JavaScript than I typically write.
Coincidentally, I am going in the opposite direction after having written many Python/PHP apps with only a little JavaScript. I noticed on my current project I was writing less backend Python code. Last night I decided I'm going to try building a complex "serverless" webapp using only Firebase and more JavaScript than I typically write.
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.
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."
Could it be any other OTP in context? That was right after mentioning Phoenix, wasn't it?
So his solution is, to do everything on the server.
Great.
Great.
Her name is Amy. It's right there on every paragraph.
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.
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.
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.
The 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.
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.
I just wanted to echo this sentiment. I also had a similar "aha" moment when a colleague introduce me to React, whereas prior to that I had invariably hacked interfaces together with very ad-hoc jQuery code. Since backend code is my bread and butter, my intuitions never had a chance to develop beyond "this feels error-prone and wrong" on their own.
Further paralleling your own journey, I now reach for Mithril first too, and I can't recommend it enough.
Further paralleling your own journey, I now reach for Mithril first too, and I can't recommend it enough.
This 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.
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.
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.
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.
(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.
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.
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 Java is mandated). I'll save the Java rant for another day.
Personally, I find that maintaining state about "workflow" in an actual data entry app is MUCH easier in a fat client than trying to preserve state while entire pages bounce back and forth between client and server. Webflows (Spring/JSF)? Therein lies madness...
And it is pretty cool that our server app has simply became a pile of REST services with default client app resources bundled in. We already prototyped an integration with another system a few months ago that demoed very well.
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 Java is mandated). I'll save the Java rant for another day.
Personally, I find that maintaining state about "workflow" in an actual data entry app is MUCH easier in a fat client than trying to preserve state while entire pages bounce back and forth between client and server. Webflows (Spring/JSF)? Therein lies madness...
And it is pretty cool that our server app has simply became a pile of REST services with default client app resources bundled in. We already prototyped an integration with another system a few months ago that demoed very well.
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...
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...
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.
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 simpler.
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 simpler.
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.
I'd like to see a trivial app implemented in JS and then re-implemented using Dala's method.
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.
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.
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.
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.
--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.
Totally. I see this argument about offloading the load to the client so often, that I am left thinking whether I am the only one here working on a project with less than a few thousands of requests every second :)
It's good to have performance and scalability in mind but so often it just doesn't matter.
It's good to have performance and scalability in mind but so often it just doesn't matter.
[deleted]
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.
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.
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.
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.
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 JavaScript, should say a lot about JavaScript's stickiness.
I actually find it amazing all the effort that has gone into TypeScript and Dart, which just produces more JavaScript, instead of creating a new language from scratch. It really looks like even Microsoft and Google prefer to deal with JavaScript 'as is' going with language supersets and languages that output more JavaScript than launching a new language.
In a few years JavaScript will most likely be the 'bytecode' of the web, you won't have to use directly, but it will just be there, produced by higher level stuff like TypeScript or Dart that produces JavaScript.
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 JavaScript, should say a lot about JavaScript's stickiness.
I actually find it amazing all the effort that has gone into TypeScript and Dart, which just produces more JavaScript, instead of creating a new language from scratch. It really looks like even Microsoft and Google prefer to deal with JavaScript 'as is' going with language supersets and languages that output more JavaScript than launching a new language.
In a few years JavaScript will most likely be the 'bytecode' of the web, you won't have to use directly, but it will just be there, produced by higher level stuff like TypeScript or Dart that produces JavaScript.
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.
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.
> In a few years JavaScript will most likely be the 'bytecode' of the web
All major browsers are working on WebAssembly as a bytecode for the web: https://webassembly.github.io/ I expect we will skip JavaScript for TypeScript/Dart -> WebAssembly in the future.
All major browsers are working on WebAssembly as a bytecode for the web: https://webassembly.github.io/ I expect we will skip JavaScript for TypeScript/Dart -> WebAssembly in the future.
"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...
This realtime graph is the only clue that this interview wasn't conducted in the mid-2000s.
Edit: Are we being trolled? https://en.wikipedia.org/wiki/Amygdala
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...
This realtime graph is the only clue that this interview wasn't conducted in the mid-2000s.
Edit: Are we being trolled? https://en.wikipedia.org/wiki/Amygdala
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
Or abuse GIFs:
https://github.com/jbochi/gifstreaming
more people complaining about a language they don't understand, js should be more like y language is something I've been hearing for years. it's inane and shows a deep lack of understanding of programming languages specifically, and how computers work in general.
I have been writing apps in all js for years now, there are issues with the language as there are with all languages. over all if you spend the time to learn it, don't use pre processors, and stick to the known patterns for js development you will have zero issues with the language.
the bugs I run into nowadays are usually related to parsing incoming data that is not formatted logically for best use in js. it is best to get your js objects as flat as you can on the server side before sending them up to be iterated over in your frontend app.
most of the applications I build are data heavy with charts and such. I routinely get 100ms or better load times on huge amounts of data because if you do it right, JS is really fast and flexible.
my wife is a designer and I've learned that CSS used correctly with js is all you need. if you can't do the graphics with CSS then js is fine, but do all the work on your Dom object before injecting it into the Dom.
read JavaScript the good parts by Douglas Crockford
I have been writing apps in all js for years now, there are issues with the language as there are with all languages. over all if you spend the time to learn it, don't use pre processors, and stick to the known patterns for js development you will have zero issues with the language.
the bugs I run into nowadays are usually related to parsing incoming data that is not formatted logically for best use in js. it is best to get your js objects as flat as you can on the server side before sending them up to be iterated over in your frontend app.
most of the applications I build are data heavy with charts and such. I routinely get 100ms or better load times on huge amounts of data because if you do it right, JS is really fast and flexible.
my wife is a designer and I've learned that CSS used correctly with js is all you need. if you can't do the graphics with CSS then js is fine, but do all the work on your Dom object before injecting it into the Dom.
read JavaScript the good parts by Douglas Crockford
CSS? Now that's hard.
I love both the dynamic and functional aspects of Javascript. See my comment elsewhere about currying as a frequent substitute for constructors/setters, abstract base classes and AOP.
I love both the dynamic and functional aspects of Javascript. See my comment elsewhere about currying as a frequent substitute for constructors/setters, abstract base classes and AOP.
There are many reasons I would welcome an alternative to javascript on the front end, but sophomoric contrarianism isn't one.
NOTE: I do a LOT of JS development. Just check my profile.
This is how the vast majority of web apps were built for the vast majority of the life of the internet, and likely probably still are, considering the vast, invisible depths of internal enterprise development. It's not surprising that it can be made to work well. It's what HTTP is built for.
This is how the vast majority of web apps were built for the vast majority of the life of the internet, and likely probably still are, considering the vast, invisible depths of internal enterprise development. It's not surprising that it can be made to work well. It's what HTTP is built for.
I'd really be curious what the end result looks like from a UX perspective. A full page reload for everything seems a bit crazy. Perhaps these clients of hers didn't care so much about the experience?
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.
These aren't really GOOD ideas, but someone who really, really doesn't want to use Javascript has options.
Indeed, Hacker News' one piece of JavaScript is for the upvote mechanic.
Could someone link to examples of her work? The article reads as if it's more of a fashionable contrarianism, mostly for the sake of it. I would like to experience her work in detail tho. Sadly, a clever name like 'Amy G Dala' fools google and doesn't turn up anything.
Is the interviewee a real person? My interpretation (based on the name) was that it was a fictitious interview to make a point.
Completely offtopic, Amygdala was the boss that gave me the most trouble in Bloodborne. https://www.youtube.com/watch?v=Njmz1MbwOiM
Completely offtopic, Amygdala was the boss that gave me the most trouble in Bloodborne. https://www.youtube.com/watch?v=Njmz1MbwOiM
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.
Yes! Do use reddit and craigslist. Vote up some stories. Peruse some comments, maybe collapse the threads you don't find interesting. Do a search and see craigslist fill in potential matches for you. Hunt for places to live and notice that it gives you a nice map you can zoom and pan with.
Oh, weird, that stuff uses JS. Huh.
Oh, weird, that stuff uses JS. Huh.
>Then observe how much javascript it actually used. It’s used a ton because we have been given the tool, and in having this tool, we use it.
I'm not convinced of this reasoning. I think computing history has shown repeatedly that many ideals of declarative purity will give way to something that becomes Turing Complete. (E.g. config files with IF-THEN/GOTO[1], SQL that includes "stored procedures" with loops, TeX typesetting language adds Turing-Complete programmability[2], etc)
Thought experiment... imagine a different starting point of browsers where there was only HTML/CSS but no Javascript engine. Wouldn't the pent up desire for some "programmability" in web pages eventually lead one of the browser vendors to add new HTML "logic" tags that have if/else/goto/loop? Or a vendor adds CSS "extensions" with eventual Turing Complete power? Once one browser adds it, the others copy it and we have the same situation of "program code" on the client browser. Maintaining 25 years of no programming logic power on browsers since the 1990s Mosaic browser does not seem realistic. In other words, if it wasn't Brendan Eich's Javascript to dynamically mess with the webpages, it would have eventually been something else to provide similar powers.
>The 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. Is there any other place in the stack where we architect code to work like this?
I don't know what is meant by "other place in the stack" but in the wider computing world, MS Windows Forms (WinForms) works like this. You have ".frm" files with the "declarative" widget placements and then C#/VB code that can hide/unhide, resize, add GUI elements, etc. Other GUI toolkits (C++ Qt) work the same way.
>But the frontend? So I’d agree that it’s here to stay. But I don’t think we have to embrace it for all web stuff as much as we have.
With mobile phones and many desktops experiencing 100ms to 500ms network latency, what's the alternative? If a web surfer updates a shopping cart from quantity of 2 to 3, is it really the best practice to have the server rebuild the entire page and resend the result of "subtotal=price x quantity" to the client just so we maintain ideological purity of no Javascript on the web browser? Most users would find the constant page refreshes to be sluggish and not user-friendly.
[1]http://stackoverflow.com/questions/648246/at-what-point-does...
[2]Donald Knuth: http://maps.aanhet.net/maps/pdf/16_15.pdf
excerpt: In the 70s, I had a negative reaction to systems that tried to be all things to all people. Every system I looked at had its own universal Turing machine built into it somehow, and everybody’s was a little different from everybody else’s. So I thought, “Well, I’m not going to design a programming language; I wanted to have just a typesetting language.” Little by little, I needed more features and so the programming constructs grew. Guy Steele began lobbying for more capabilities early on, and I put many such things into the second version of TEX, TEX82, because of his urging. That made it possible to calculate prime numbers as well as do complicated things with page layout and figure placements.
I'm not convinced of this reasoning. I think computing history has shown repeatedly that many ideals of declarative purity will give way to something that becomes Turing Complete. (E.g. config files with IF-THEN/GOTO[1], SQL that includes "stored procedures" with loops, TeX typesetting language adds Turing-Complete programmability[2], etc)
Thought experiment... imagine a different starting point of browsers where there was only HTML/CSS but no Javascript engine. Wouldn't the pent up desire for some "programmability" in web pages eventually lead one of the browser vendors to add new HTML "logic" tags that have if/else/goto/loop? Or a vendor adds CSS "extensions" with eventual Turing Complete power? Once one browser adds it, the others copy it and we have the same situation of "program code" on the client browser. Maintaining 25 years of no programming logic power on browsers since the 1990s Mosaic browser does not seem realistic. In other words, if it wasn't Brendan Eich's Javascript to dynamically mess with the webpages, it would have eventually been something else to provide similar powers.
>The 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. Is there any other place in the stack where we architect code to work like this?
I don't know what is meant by "other place in the stack" but in the wider computing world, MS Windows Forms (WinForms) works like this. You have ".frm" files with the "declarative" widget placements and then C#/VB code that can hide/unhide, resize, add GUI elements, etc. Other GUI toolkits (C++ Qt) work the same way.
>But the frontend? So I’d agree that it’s here to stay. But I don’t think we have to embrace it for all web stuff as much as we have.
With mobile phones and many desktops experiencing 100ms to 500ms network latency, what's the alternative? If a web surfer updates a shopping cart from quantity of 2 to 3, is it really the best practice to have the server rebuild the entire page and resend the result of "subtotal=price x quantity" to the client just so we maintain ideological purity of no Javascript on the web browser? Most users would find the constant page refreshes to be sluggish and not user-friendly.
[1]http://stackoverflow.com/questions/648246/at-what-point-does...
[2]Donald Knuth: http://maps.aanhet.net/maps/pdf/16_15.pdf
excerpt: In the 70s, I had a negative reaction to systems that tried to be all things to all people. Every system I looked at had its own universal Turing machine built into it somehow, and everybody’s was a little different from everybody else’s. So I thought, “Well, I’m not going to design a programming language; I wanted to have just a typesetting language.” Little by little, I needed more features and so the programming constructs grew. Guy Steele began lobbying for more capabilities early on, and I put many such things into the second version of TEX, TEX82, because of his urging. That made it possible to calculate prime numbers as well as do complicated things with page layout and figure placements.
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).
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.
> the backend will need to be updated to provide Rest APIs
In this day and age of micro-servicing everything, the backend should have a front-end for webpages that uses the same Rest API as mobile devices.
In this day and age of micro-servicing everything, the backend should have a front-end for webpages that uses the same Rest API as mobile devices.
> 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).
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).
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.
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.
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.
var ping = new Image(); ping.src = node.href;
Technically, it might not be called ajax but the point is the same.
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 code.) I would love to see JS back in its core domain which is / has been (choose your own) real-time interaction. I dare say, we haven't seen much of this lately, at least not in creative and novel ways.
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 code.) I would love to see JS back in its core domain which is / has been (choose your own) real-time interaction. I dare say, we haven't seen much of this lately, at least not in creative and novel ways.
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.
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.
But maybe it comes down to the fact that many developers simply like over engineered solutions and sprinkle some complexity to often boring problems? Not saying that it's always the case but surely many of us can recollect related stories :)
For me, its more about the frameworks shoving between you and the presentation layer. It's not realtime and interactive anymore (rather about packed and delayed update/repaint cycles). Consider what could be done alone using the canvas 2d-context with the current API. There isn't a visual thing that couldn't be done with this. Some may remember the creative wealth of CD-ROMs in the 1990s – we may have all of this, but better. Instead, it seems more about a glorified mark down presentation layer. We really could do better.
P.S.: Maybe, this is just an old man's rant about the old days like when PostScript was all written by hand and typo came in stars. But I'm really underwhelmed by the state of creativity on the web.
P.S.: Maybe, this is just an old man's rant about the old days like when PostScript was all written by hand and typo came in stars. But I'm really underwhelmed by the state of creativity on the web.
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.
What about writing web-apps with zero Java, Scala, C#, Ruby, Python, PHP ??
So, writing your web application in Node?
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 bad parts, is the sort of blame-shifting we should try to avoid as developers. "Never use X" might be a solution to a problem but it won't necessarily guide you to good design patterns.
We've all heard the old adage "use the right tool for the job" but its just as important to do a good job with the tools you have. It's possible to write pages that use CSS and JavaScript to enhance your users' experience while also being small and rendering perfectly in Lynx. If you're having so much trouble with JavaScript that you eschew it completely, maybe there was an issue with how you approached the problem rather than with the language itself.
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 bad parts, is the sort of blame-shifting we should try to avoid as developers. "Never use X" might be a solution to a problem but it won't necessarily guide you to good design patterns.
We've all heard the old adage "use the right tool for the job" but its just as important to do a good job with the tools you have. It's possible to write pages that use CSS and JavaScript to enhance your users' experience while also being small and rendering perfectly in Lynx. If you're having so much trouble with JavaScript that you eschew it completely, maybe there was an issue with how you approached the problem rather than with the language itself.
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.
It was an interesting point about SPAs being partially a symptom of god-awful slow backends, fake article or not.
The entire argument against JS fell apart in the last paragraph. As long as it's not me who is writing JS but some 3rd party library which I just pass data along, then what I have is no JS.
[deleted]
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!"
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!"
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.
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.
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.
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.
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.
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.
There's also a framebuster, and onclick handlers for the search button.
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.
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.