Elbowing JavaScript out
blog.ikura.co
blog.ikura.co
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 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.
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.
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.
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.
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...
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'd like to see a trivial app implemented in JS and then re-implemented using Dala's method.
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.
--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.
It's good to have performance and scalability in mind but so often it just doesn't matter.
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.
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
Or abuse GIFs:
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.
Further paralleling your own journey, I now reach for Mithril first too, and I can't recommend it enough.
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.
It was an interesting point about SPAs being partially a symptom of god-awful slow backends, fake article or not.
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.
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.
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.
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 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.
These aren't really GOOD ideas, but someone who really, really doesn't want to use Javascript has options.
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.
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.
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.
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.
var ping = new Image(); ping.src = node.href;
Technically, it might not be called ajax but the point is the same.
Completely offtopic, Amygdala was the boss that gave me the most trouble in Bloodborne. https://www.youtube.com/watch?v=Njmz1MbwOiM
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 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.
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.
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.
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.
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.
Oh, weird, that stuff uses JS. Huh.
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.
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).
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.
"The amygdala is an almond-shaped structure in the brain".
Coincidence?
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.
There are things like client side validation that I don't know how you'd do another way?
You lost me there.
Great.
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.
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.