8 ms·

Elbowing JavaScript out

61 points by ljoshua 11y ago

JamesBaxter 11y ago
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?
- petepete 11y ago
  Basic client-side validation is possible with HTML5 inputs and attributes, but for anything more involved you need to use JavaScript.
atomi 11y ago
I don’t even mind it living in the backend You lost me there.
- sheeshkebab 11y ago
  same here, stopped reading after that
amelius 11y ago
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.
- cdmckay 11y ago
  Doesn't WebAssembly allow them to bring their creations to the web?
  - tyingq 11y ago
    Maybe, someday. The current course will only allow for statically typed languages, and does not allow direct dom access.
- izym 11y ago
  How does WebAssembly not acknowledge that?
  - JBReefer 11y ago
    No support for multiple returns, for one
    - sunfish 11y ago
      WebAssembly will support multiple-return functions, just not in the very first version.
    - deleted 11y ago
      [deleted]
    - icebraining 11y ago
      Assuming you have tuples, does it matter? Python doesn't have multiple returns either, but it fakes them convincingly.
- LewisJEllis 11y ago
  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.
lcfcjs 11y ago
Yes please stop trying to be JS devs. Leave it to people who know the language. Someone who comes from Java or Python can just make monstrosities of code and then hate working on it again. What a surprise. These are the people responsible for coffeescript, typescript, yourmumscript that won't exist in a year or so.
sanjeetsuhag 11y ago
I hate the font on this page.
larrykubin 11y ago
"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.
drewpc 11y ago
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.
- cpeterso 11y ago
  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.
  - bobwaycott 11y ago
    Could it be any other OTP in context? That was right after mentioning Phoenix, wasn't it?
  - moron4hire 11y ago
    OTP means Online Transaction Processing. It's a fancy name for "no caching, no data warehouse, we do everything live."
hutzlibu 11y ago
So his solution is, to do everything on the server. Great.
- extropic-engine 11y ago
  Her name is Amy. It's right there on every paragraph.
  - spriggan3 11y ago
    She might identify as a man, you don't know that.
  - balls187 11y ago
    I seriously doubt the interviewee's real name is Amy G Dala.
binarymax 11y ago
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.
- PaulHoule 11y ago
  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.
brlewis 11y ago
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.
- nvader 11y ago
  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.
ebbv 11y ago
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.
- Roboprog 11y ago
  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.
hhsnopek 11y ago
(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.
- binarymax 11y ago
  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.
  - hhsnopek 11y ago
    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.
    - binarymax 11y ago
geggam 11y ago
We can only hope more people lose javascript. Please ?
- Roboprog 11y ago
  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.
  - geggam 11y ago
    not worried about complex... i miss being able to surf the internet on smaller systems than it takes to run entire clouds stacks on
    - Roboprog 11y ago
      Ah. Gotcha. E.g. - a newsletter doesn't need to be an "app".
  - wtbob 11y ago
    > 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.
    - Roboprog 11y ago
      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.
drubio 11y ago
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/ https://www.typescriptlang.org/) and Google is also behind Dart (https://www.dartlang.org/ 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.
- Roboprog 11y ago
  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-typescript-and-a-release-date-123674.html 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.
- eosrei 11y ago
beaker52 11y ago
"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 https://en.wikipedia.org/wiki/Amygdala
- roywiggins 11y ago
  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 https://github.com/jbochi/gifstreaming
ldehaan 11y ago
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
- Roboprog 11y ago
  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.
WalterSear 11y ago
There are many reasons I would welcome an alternative to javascript on the front end, but sophomoric contrarianism isn't one.
moron4hire 11y ago
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.
jameslk 11y ago
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?
shoemai 11y ago
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.
- jrickert 11y ago
  Indeed, Hacker News' one piece of JavaScript is for the upvote mechanic.
- roywiggins 11y ago
  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.
badusername 11y ago
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.
- balls187 11y ago
  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 https://www.youtube.com/watch?v=Njmz1MbwOiM
azag0 11y ago
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.
- bobwaycott 11y ago
  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.
sickbeard 11y ago
is "Amy G Dala" a fake name? I put it in google and got "The amygdala is an almond-shaped structure in the brain". Coincidence?
- elbigbad 11y ago
  Of course it's not a coincidence. It's some pen name of some author trying to be clever while chuckling to themselves about their high-brow inside joke.
draw_down 11y ago
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.
jasode 11y ago
>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-a-config-file-become-a-programming-language http://stackoverflow.com/questions/648246/at-what-point-does... [2]Donald Knuth: http://maps.aanhet.net/maps/pdf/16_15.pdf 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.
Scarbutt 11y ago
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).
CalmStorm 11y ago
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.
- spriggan3 11y ago
  > 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.
- wtbob 11y ago
  > 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).
gedrap 11y ago
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.
- mooseburger 11y ago
  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.
  - gedrap 11y ago
    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.
masswerk 11y ago
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.
- gedrap 11y ago
  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 :)
  - masswerk 11y ago
    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.
- spriggan3 11y ago
  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.
jordanlev 11y ago
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!"
- tyingq 11y ago
  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.
- underwater 11y ago
  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.
  - roywiggins 11y ago
    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.
bricss 11y ago
What about writing web-apps with zero Java, Scala, C#, Ruby, Python, PHP ??
- ArbitraryHobo 11y ago
  So, writing your web application in Node?
supernintendo 11y ago
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.
- _greim_ 11y ago
  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.
luffy327 11y ago
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 11y ago
[deleted]
BFatts 11y ago
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.
m4nu 11y ago
>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.

61 points by ljoshua 11y ago

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?

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

atomi 11y ago

I don’t even mind it living in the backend You lost me there.

sheeshkebab 11y ago
same here, stopped reading after that

amelius 11y ago

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.

cdmckay 11y ago
Doesn't WebAssembly allow them to bring their creations to the web?
- tyingq 11y ago
  Maybe, someday. The current course will only allow for statically typed languages, and does not allow direct dom access.
izym 11y ago
How does WebAssembly not acknowledge that?
- JBReefer 11y ago
  No support for multiple returns, for one
  - sunfish 11y ago
    WebAssembly will support multiple-return functions, just not in the very first version.
  - deleted 11y ago
    [deleted]
  - icebraining 11y ago
    Assuming you have tuples, does it matter? Python doesn't have multiple returns either, but it fakes them convincingly.
LewisJEllis 11y ago
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.

lcfcjs 11y ago

Yes please stop trying to be JS devs. Leave it to people who know the language. Someone who comes from Java or Python can just make monstrosities of code and then hate working on it again. What a surprise. These are the people responsible for coffeescript, typescript, yourmumscript that won't exist in a year or so.

sanjeetsuhag 11y ago

I hate the font on this page.

larrykubin 11y ago

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

drewpc 11y ago

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.

cpeterso 11y ago
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.
- bobwaycott 11y ago
  Could it be any other OTP in context? That was right after mentioning Phoenix, wasn't it?
- moron4hire 11y ago
  OTP means Online Transaction Processing. It's a fancy name for "no caching, no data warehouse, we do everything live."

hutzlibu 11y ago

So his solution is, to do everything on the server. Great.

extropic-engine 11y ago
Her name is Amy. It's right there on every paragraph.
- spriggan3 11y ago
  She might identify as a man, you don't know that.
- balls187 11y ago
  I seriously doubt the interviewee's real name is Amy G Dala.

binarymax 11y ago

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.

PaulHoule 11y ago
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.

brlewis 11y ago

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.

nvader 11y ago
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.

ebbv 11y ago

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.

Roboprog 11y ago
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.

hhsnopek 11y ago

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

binarymax 11y ago
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.
- hhsnopek 11y ago
  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.
  - binarymax 11y ago

geggam 11y ago

We can only hope more people lose javascript. Please ?

Roboprog 11y ago
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.
- geggam 11y ago
  not worried about complex... i miss being able to surf the internet on smaller systems than it takes to run entire clouds stacks on
  - Roboprog 11y ago
    Ah. Gotcha. E.g. - a newsletter doesn't need to be an "app".
- wtbob 11y ago
  > 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.
  - Roboprog 11y ago
    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.

drubio 11y ago

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/ https://www.typescriptlang.org/) and Google is also behind Dart (https://www.dartlang.org/ 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.

Roboprog 11y ago
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-typescript-and-a-release-date-123674.html 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.
eosrei 11y ago

beaker52 11y ago

"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 https://en.wikipedia.org/wiki/Amygdala

roywiggins 11y ago
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 https://github.com/jbochi/gifstreaming

ldehaan 11y ago

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

Roboprog 11y ago
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.

WalterSear 11y ago

There are many reasons I would welcome an alternative to javascript on the front end, but sophomoric contrarianism isn't one.

moron4hire 11y ago

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.

jameslk 11y ago

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?

shoemai 11y ago

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.

jrickert 11y ago
Indeed, Hacker News' one piece of JavaScript is for the upvote mechanic.
roywiggins 11y ago
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.

badusername 11y ago

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.

balls187 11y ago
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 https://www.youtube.com/watch?v=Njmz1MbwOiM

azag0 11y ago

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.

bobwaycott 11y ago
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.

sickbeard 11y ago

is "Amy G Dala" a fake name? I put it in google and got "The amygdala is an almond-shaped structure in the brain". Coincidence?

elbigbad 11y ago
Of course it's not a coincidence. It's some pen name of some author trying to be clever while chuckling to themselves about their high-brow inside joke.

draw_down 11y ago

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.

jasode 11y ago

>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-a-config-file-become-a-programming-language http://stackoverflow.com/questions/648246/at-what-point-does... [2]Donald Knuth: http://maps.aanhet.net/maps/pdf/16_15.pdf 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.

Scarbutt 11y ago

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

CalmStorm 11y ago

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.

spriggan3 11y ago
> 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.
wtbob 11y ago
> 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).

gedrap 11y ago

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.

mooseburger 11y ago
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.
- gedrap 11y ago
  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.

masswerk 11y ago

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.

gedrap 11y ago
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 :)
- masswerk 11y ago
  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.
spriggan3 11y ago
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.

jordanlev 11y ago

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!"

tyingq 11y ago
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.
underwater 11y ago
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.
- roywiggins 11y ago
  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.

bricss 11y ago

What about writing web-apps with zero Java, Scala, C#, Ruby, Python, PHP ??

ArbitraryHobo 11y ago
So, writing your web application in Node?

supernintendo 11y ago

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.

_greim_ 11y ago
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.

luffy327 11y ago

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 11y ago

[deleted]

BFatts 11y ago

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.

m4nu 11y ago

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