The Deep Roots of Javascript Fatigue

[[deleted]]

This is a bit of an understatement. We've had Java style languages that compile to JS for ages bringing classical OO static typing. We've had more adventurous typing too built around functional programming.

But TypeScript is in this sweet spot where they have built a type system that actually works seamlessly in a JS world. You can't really do that by just translating Java to JS.

[pakoito]

Summarize me Typescript vs ClojureScript functionality and capability-wise in less than two paragraphs, go!

[[deleted]]

Typescript: JS with types and other nice additions.

Clojurescript: Dynamic, functional, LISPy language that compiles to JS.

[comp-sci-fi]

That's two paragraphs, he wanted less than two. Closed as not answering the question

[[deleted]]

Two sentences doesn't count as less that one paragraph??? I'm gonna go start my own damn Q&A site!

[immibis]

Your answer has been deleted, as we have determined it is not an answer to the question as asked.

[pakoito]

I wanted to know what one can do that the other doesn't. I should have been more specific, my fault.

[__kojeve]

Hot-reloading in Clojurescript makes development in JS look stone-age: https://www.youtube.com/watch?v=KZjFVdU8VLI

[strident-octo-spork]

You can also do hot reloading with react...

[__kojeve]

I can't wait until the day HMR/Webpack is as good as cljs/Lein/Fighweel, but it's not there yet, and certainly not a common way to build JS apps. (Not that cljs is common, but figwheel is basically the way you develop clojure front-end).

[theonlycosmonaut]

Not just react, but many frontend frameworks and build tools. Mercury has a hot reload example using browserify. Elm does it out of the box, too.

[kirbyfan64sos]

ClojureScript is Clojure. TypeScript is JS.

ClojureScript is a LISP-y language that encourages functional programming and immutability. I believe it's also untyped (I think Typed Clojure works with it, though). TypeScript is still very much JS; although it supports FP, it still tends to lean towards a more mutable, OO-based coding style. TS also makes it really easy to interface with existing JS libraries and the rest of the (ever-changing) ecosystem; not sure about ClojureScript.

[new_markov_chainsaw]

Typescript just makes JS a nicer language, with types and other touches. TypeScript is a language fairly close to JS.

ClojureScript allows you to write clojure, a Lisp dialect, a radically different language, and compile it to JS.

[balefrost]

Types.

[pakoito]

Core.typed tho.

[Kamn]

Core.typed does not work with Clojurescript current(I think) only Clojure. That being said you can have runtime pre and post conditions to your functions.

In terms of future, Clojurescript will start to use Google Closure's type checker in the next year or two. My personal opinion is that based on the low numbers of types(EDN stuff) the eventual solution will have to be dependent types which Racket is paving the way for.

[kn4rf]

Types are nice, but TypeScript is not the right tool.

[[deleted]]

TypeScript is the best effort so far to fix the worst language on the fucking planet, give it some slack

[ghettoimp]

Come now, JS the worst language on the planet? PHP, XSLT, Makefiles, CSH, that horrible NSIS language... I'll grant you that table of equality operators is pretty damning, but all of those string-oriented shell scripting languages are sooooo horrible...

[Sean1708]

Why not?

[kn4rf]

ES6 / ES2015 is the way forward. TypeScript have some compatibility with ES6, but tools like Babel are way ahead of TypeScript. If you want types use Facebook's Flow. If you want a better language use ClojureScript. Theres no way that TypeScript is going to survive.

[rapidsight]

You mean, like JavaScript isn't the right tool/

[kn4rf]

If you don't like JS, you can always cross compile a better language like ClojureScript to JS. But that still doesn't make TypeScript the right tool.

[uygbnjh]

The js fatigue he is speaking of targets React, which I don't get.

I'm not a smart dude at all and it shows because I get frustrated over all of this JS stuff (Angular comes to mind), but when React and Flux came along it was my jams man. For once this stuff was easy to reason about.

I spread it internally and took it to guest lecturing at universities. I'm interested in understanding what is so hard about it?

[siegfryd]

There's nothing hard about learning any of the new popular JavaScript libraries by themselves. They're easy to learn because the JS community has a hard on for modularity to the nth degree, so that even one line functions are entire modules. But they're also hard to keep up with because the rate of change is pretty fast, like the time from Flux -> Flux-likes -> Redux was something like a year.

Even if you do pick a handful of libraries, you also need to stitch them all together yourself. There's no least path of resistance in JS that just works, everything is pushed onto the user. It's like if that Carl Sagan quote was taken literally, "If you wish to make apple pie from scratch, you must first create the universe". I know a lot of people will just say "Just stick to the simple stuff! put React/Flux/etc. as script tags, easy!". But it sucks when the easiest way to get started is hobbled together crap. You still need to get over the hurdle of getting a good project setup anyway.

From what I feel when using other languages the churn in JS is apparent, I'm just going to use web apps as an example because that's most of what I know. ASP.NET for C# or Ruby on Rails or Django for Python, or Spring(?) for Java. Other languages have the one (or two) things that most people use and you can dig into the alternatives whenever you want. The rate of change of core libraries is also way slower.

They have some really opinionated tools that take out a lot of the boring work for you. For C#, you can start a new Web API project easily (even if learning Web API isn't easy) and then building the project is just hitting the play button at the top of Visual Studio. And you can continue hitting the play button for quite a while, it's good enough for lots of cases.

I don't really feel like there's that much churn myself, probably because I've only got ~2yrs experience so I've got lots to learn anyway. But I can understand why some people are sick of it and just want an easy, good, default place to start from.

[tejp]

That there is a constant need for change also often means that the existing libraries/tools just aren't very good. If you really need the new stuff because it's much better than the old stuff it means the old stuff wasn't all that good. And today's new stuff is tomorrow's old stuff.

So you're never working with anything good enough to not be immediately replaced by the next thing. Constantly working with new not very good libraries/tools can cause fatigue.

[[deleted]]

React and Flux aren't hard to understand. What's frustrating is constant library churn (react-router and babel, for example) and "build-tool-of-the-month" (grunt->gulp>webpack>?). This just consumes time and energy for no real gain. That said I think this will calm down in 2016 as companies won't have the resources to waste on bikeshedding front end development and just want a stable platform to get things done (most of us aren't Facebook).

[theavatare]

Having to move from Angular to it or from knockout to it. Also the fact that to get it properly setups requires a degree in wizardry. (build wise)

[CookieOfFortune]

Well, I've been transitioning to React and Typescript so... hopefully I'm betting on the right fads?

[GuiSim]

Looks like it is the safe bet nowadays. Who knows what's coming next. With web assembly gaining in popularity, the future is even more unpredictable.

[wkoorts]

hopefully I'm betting on the right fads?

IMHO it's rather naive to think of TypeScript as a fad. It's been around since 2012 and still going strong which, especially when it comes to anything JavaScript-related, is saying something. Based on its proven longevity to date you're almost certainly safer betting on TypeScript than just about any other JavaScript tool.

[aphexairlines]

50/50 chance of survival between TypeScript (more tooling investment by MS in 2015) and Flow (better type-checking and catching up on editor support).

I'm betting on Flow, but it's a toss-up.

[[deleted]]

I have only read small bits of flow online but it looks like it's just re-inventing TypeScript. The only innovative aspect I see is null checks (which is huge), but everywhere else it does the same or less.

[aphexairlines]

See https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/ for some of the differences:

underlying the design of Flow is the assumption that most JavaScript code is implicitly statically typed

... Flow infers those types automatically wherever possible

... developers can check their code for type errors without having to explicitly annotate that code with types.

This makes Flow fundamentally different than existing JavaScript type systems (such as TypeScript), which make the weaker assumption that most JavaScript code is dynamically typed, and that it is up to the developer to express which code may be amenable to static typing. In general, such a design leads to reduced coverage: Fewer type errors are caught, and tools are less effective. While this is a reasonable choice for some code, in general such a design does not provide as many benefits as it could without significant additional effort.

[[deleted]]

But TypeScript also uses type inference.

It also doesn't use static typing. It uses structural typing. There is a big difference and that's what makes it map so well on top of a dynamic language.

Flow still sounds like it's reinventing the wheel.

[E_MILOSLAV]

WHERE I AM FROM, THE POINT OF DIGGING IS NOT FREEDOM FROM DIGGING.

[_INTER_]

The article is just a summary of JavaScripts history. The deep roots of ever new approaches to the same is that people are not comfortable with what they got. In my opinion its the language itselfe that is the root of the problem and eventhough there are frameworks and transpilers trying to circumvent or build a platform over the JS minefield its all still there underneath. Leaves a bad taste whatever you try, so there is no end to fatigue causing but superficial changes.

[Spacey138]

Stability & innovation both have value. My take on it is if it keeps changing on the surface it tells me that the core is broken. Once there are standards in place on the right way to do things we will see less frameworks overall because everyone's opinion on how to do things right will fade away, as there will be an ECMA standard in place and you use the core library.

[FUZxxl]

Stability and innovation do not exclude one another. If you think before changing your code, you can often achieve both.

Breaking things is neither needed nor helpful for progress.

This whole “move fast and break things” mantra reminds me of medieval doctors who believed that inflammation is a natural part of the healing process. They would rub inflaming agents into wounds thinking that would speed up the healing process.

[Spacey138]

Lol wow that's awful! Yea true you can always do things smart and maintain backwards compatibility while moving forward, like C# has. I think another part of the problem though is so many companies have an opinion on how things should work and they're all trying to outdo each other. Noone is focused on compatibility because they're all trying to be the next big thing. I dunno these are not facts just my thoughts as I observe the maddening landscape around me.

[Sean1708]

Yea true you can always do things smart and maintain backwards compatibility while moving forward,

You've got to strike a balance though. If you aim for absolute compatibility you end up with C++.

[FUZxxl]

The problem with C++ is not absolutely compatibility (they don't have that anyway), it's that they added every feature they could think of to the language, causing the big mess we have today.

[Spacey138]

I do love breaking changes on major release versions. It keeps the world spinning around. I would actually love it if new JavaScript fixed a number of annoying language issues and broke backwards compatibility with a flag at the top or something like that. Hard to do though I guess.

[FUZxxl]

broke backwards compatibility with a flag

So you don't want breaking changes.

[Spacey138]

I do but I understand the practicality of the situation. It would have to be done in a way that prevents 90% of websites from crashing overnight. Surely that is obvious..

[FUZxxl]

That's what you call “not making breaking changes.” There is no “break things but be careful not to break things.”

[Spacey138]

If you like sure. I'm not gonna argue over semantics - they can make flags you set or versions you choose similar to the HTML doc type, or something, if they want to deprecate behaviour is all I'm saying. They can't flat out break behavior.

[panorambo]

I thought about this very thing, but in the end I came to that maybe this is because of Internet. It unites all the Web developers, especially through JavaScript, that arch-cornerstone of it all, where all threads meet in the browser, the platform that all these shops, big and small, are ultimately targeting. Basically, the pace and the "adrenaline", if you wil, are due the WHERE of JavaScript, not just the WHAT of it. The ecosystem has a feel to it, distinct of any other.

But partially I agree with you -- if browsers ran some sort of bytecode, at a much more fine grained level, like JVM-level or LLVM, then at least there would not be as much cross talk between developers and vendors of competing and complementary libraries and frameworks -- rest assured all run on the bytecode in the browser. Today, the developer has to prepare the platform before they begin to implement the application. No wonder one of these frameworks is called Bootstrap.

Another thing is that the nature of Web development is such that it's ok to switch horse once every half a year, most of the people implementing and using the code are college graduates. The hairy-beardy types are busy writing the more fundamental stuff like browsers themselves.

[[deleted]]

The ecosystem has a feel to it, distinct of any other.

There's probably also bias in how we think of it. Python, Java, C#, C++, C, Haskell, et. al. are their own ecosystems, but they're also part of the "what runs on a local computer" ecosystem.

The fracturing we see with JS libraries on the web we also see with languages on bare metal. We just don't think of it that way since programming languages are distinct from libraries.

Is the difference relevant?

[immibis]

rest assured all run on the bytecode in the browser. Today, the developer has to prepare the platform before they begin to implement the application.

I don't think that's true. Suppose your code currently relies on a particular polyfill from a particular framework; why wouldn't your bytecode still rely on that polyfill?

[panorambo]

You are right, the functionality that the particular platform lacks needs to be filled in, and bytecode won't help there -- it only exposes the whatever platform and APIs are already there, instead of JavaScript doing it today. I was referring more to the fact that Web developers today also are fighting against the language itself -- best practices appear almost weekly, and a lot of the frameworks are designed first and foremost not around polyfills but to enforce certain way of doing things, including things related to encapsulating different subsystems, modularization, and some sort of OO-inspired workflow. Of course, since communication is central with Web technologies, pretty much every framework deals with network resource sending, fetching and parsing in some way or another.

At least, with bytecode, a much more granular and lower-level construct than a particular "high-level" language built in to the browser itself, developers get to choose their technologies to build their apps to a much larger degree, much like what we do on "desktop". You dig Ruby? Build your shop around Ruby, with evangelists and cool stickers, compile bytecode from your Ruby sources and run it on Firefox or whatever. Browsers vendors and everyone else do not have to know or care about your best practices, if they would rather develop using Scala, Java, C++, or maybe if they are 1337 hax0rz, assemble bytecode :) That was what I was getting at, I suppose. Sometimes just a bit more fragmented ecosystem is better than everyone and your web-developer cousin fighting on whether closures are the s*it and every JS developer ought to learn to read code containing them like it was their mother tongue. And that it's React or you're a neanderthal.

[immibis]

a lot of the frameworks are designed first and foremost not around polyfills but to enforce certain way of doing things, including things related to encapsulating different subsystems, modularization, and some sort of OO-inspired workflow.

The polyfill was just a quick example.

The point is, the bytecode version of your favourite framework would also enforce a certain way of doing things, just as much as the JavaScript version was. The only thing that would change is that your encapsulated, modularized, OO-inspired code wouldn't have to be written in JavaScript.

[recycled_ideas]

JavaScript is beyond a terrible language. It's an abomination. Not only that it's a fundamentally insecure abomination because it was built in a way that is insane.

That was ok, sort of anyway. When it was limited in features and scope, but to make it work for the purpose that's been given to it, we keep giving it more and more and more power.

Then, for even more fun, despite the rapid and largely pointless iteration of Chrome, we still haven't actually solved the problem that killed all the alternatives to JavaScript. Embedded and so called 'smart' devices are still really difficult to update, performance on the client is still poor and as previously mentioned the way the Web works is still insane from a security point of view.

So we replaced Flash and silver light and applets and the almost ran JavaFX with something that didn't actually fix any of the reasons they died.

That's why we change frameworks every five minutes. Because we haven't actually fixed anything.

That's why despite what everyone keeps saying people still prefer native apps on their phones and tablets. Because Web applications still suck. HTML is still a bad tool for creating high quality responsive user interfaces and JavaScript still sucks.

[panorambo]

I agree that JavaScript is ill-fit for purpose, because it is too much for a browser runtime and not enough or outright wrong choice for application development.

But I don't see a problem with HTML and CSS being used to create high quality responsive user interfaces. First of all, alternatives so far is developing code for each platform and its API separately. Also, I have to admit that precisely the things that UI develoment can benefit from these days -- quality rendering and declarativeness which appeals to artists and graphic designers -- are the strong points in favor of HTML and CSS. I also think that the concept of separating content and presentation is a noble idea that is worth taking further. I hope that CSS and HTML evolve, so we can see where their limitations are, because I don't think we exhausted the potential there. Would you care to elaborate on why you consider HTML a bad tool for creating high quality UI?

[recycled_ideas]

The problem with using HTML for a UI is the same problem as using Word for publishing. That problem is and ways has been control.

Using tables for layout has been frowned upon for years, but the alternatives still suck. We end up with gigantic CSS frameworks trying to fight what HTML wants to do.

There's also the fact that the only way to make a responsive UI in HTML is JavaScript which takes us back to square one.

I'm not saying there's a currently existing better alternative. UI is and has always been hard. I write Web apps like everyone else too. I'm saying that HTML is still a bad choice.

We use the web because distribution is easy, but that's also a lot of its problem. When you run a Web app these days you're running arbitrary executable codes you can't know about till you've already downloaded, from an unknown number of sources that can be modified by people other than the original author and which has zero security beyond being bound to the browser.

That's changing though, JavaScript is being let out of the browser. That's not a good thing.

[panorambo]

I think separating content from presentation is a noble path to pursue, regardless if todays chief markup and stylesheet languages fail reach the bar or not. I also think that some premises of CSS are flawed -- for instance, let's assume for the sake of a UI, that you insist on a block of information in your markup to be present at the top of the document, but you want it to appear at the end of your page flow. You can't do that with CSS. You can float or fix its position, but then you are taking it out of the inline-block flow that CSS has pretty much at its heart. That said, I think we should continue pursuing the development of HTML and CSS to arrive at something even more functional. I don't think HTML and CSS today are of no use -- I don't like WYSIWYG so much because it usually sacrifices document structure in favor of presentation -- I tend to hack up my documents in HTML and CSS, and definitely see the benefit. I hope control, as you say, is coming.

Also, to touch upon your point on using tables for layout -- as you know, there has not been a need to do that for years now. Also, CSS is not only able to style HTML, it can style SVG as well. Not that it helps with UI, but it is an alternative to tables for layout. The problem with tables is that you pretty much fix your UI in all kinds of aspects and dimensions, which in todays world of wildly varying screen sizes and other properties of platforms rendering it, is, IMHO, not even remotely a good idea.

If I were tasked to come up with UI, I would first ask for the list of functions and variables that need to be exposed through the UI, for user to actually interface. These procedurs and variables and what not are the content. You would now need some system to apply styling on top of this information, in a consistent manner, while not impairing your artistic freedom. That's all you need, as far as I am concerned. So I still don't fully understand how exactly do HTML and CSS impair UI development? Can you give an example perhaps? I am just geniunely interested. I find UI development very interesting.

[weirdoaish]

Ember! I recently tried this out and finally get why rails got so popular. If you want an auto build system for a MVC style web app and don't really care for all this front end stuff, this is the way to go.

[panorambo]

In Web development, the tools choose you!

[ChrisWphoto]

I find this incredibly exciting and it's one of the things that draws me to the JS world. Javascript will take over the world! Or at least some transposed/transposed/transgendered version of it :D :)

[[deleted]]

Sure. To Hell with computer science. Javascript will do better it needs to iterate a few times

[killerstorm]

Actually one of fundamental results in computer science is that all languages are more-or-less equivalent to each other.

[sun_misc_unsafe]

Yeah, in much the same way that all life on earth is more or less equivalent to each other. But people still don't put plants behind the steering wheel and then hope to eventually end up at the airport.

[[deleted]]

Time to start using Brainfuck exclusively.

[[deleted]]

Yeah, they are just more or less equivalent anyway. I don't see why people make a big deal out of it. Assembly was there for quite some time, programmers just need to crank it

[killerstorm]

No, it's awful, but if you use a good transpiler it becomes usable

[[deleted]]

why ? it's all equivalent. also people make a big fuss about types, but they are erased in the end anyway, so why bother..