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.
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.
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.
"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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
"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.
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.
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 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.
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.
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.
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.
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.
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.
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.
>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.
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.
99 comments
[ 3.0 ms ] story [ 168 ms ] threadYou lost me there.
There are things like client side validation that I don't know how you'd do another way?
These are the people responsible for coffeescript, typescript, yourmumscript that won't exist in a year or so.
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.
Great.
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.
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.
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.
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.
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.
--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.
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'd like to see a trivial app implemented in JS and then re-implemented using Dala's method.
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...
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.
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.
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:
https://github.com/jbochi/gifstreaming
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.
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.
These aren't really GOOD ideas, but someone who really, really doesn't want to use Javascript has options.
Completely offtopic, Amygdala was the boss that gave me the most trouble in Bloodborne. https://www.youtube.com/watch?v=Njmz1MbwOiM
"The amygdala is an almond-shaped structure in the brain".
Coincidence?
Oh, weird, that stuff uses JS. Huh.
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.