Background: I learned Javascript 1997 and kept up.
I have extensive experience in ES6/React for the browser and Java/Kotlin for Server-, Desktop- and Mobile-Apps.
A week ago I switched a fairly new project from the usual setup (react/babel/webpack) to Kotlin-code only. My IDE compiles the Kotlin to JS now and webpack serves it as usual.
Writing the react-bindings took me an hour, after that my productivity went up by about 10.000%.
It's finally on par with my productivity on server and desktop. No type errors, fast refactoring, no "undefined" errors and all the goodies (extensions) of Kotlin.
Removing the complex eslint settings and babel-setup from webpack and package.json felt triumphant.
My JSX looks like this now and is completely typesafe:
What advantages does this have over Typescript? The ecosystem and mindshare are overwhelmingly in TS' favor I would imagine.
For compile-to-js languages it seems most attractive to those that use the host language (Clojure, Scala, Kotlin, Haskell, etc.), whereas for would be js expats, Typescript seems like the natural choice given current trends.
I think for a compile-to-js language (vs. a transpiler like Typescript) to take off it's going to need at least:
Tiny generated binaries
Great js interop
Large ecosystem
Seamless cross compilation (e.g. JVM/JS)
Fast compiler
Reason + Bucklescript is the only combination I know of that could potentially pull off the above, blazing fast compilation and miniscule binaries being its greatest strengths at the moment.
Typescript still has some issues that only a "real" strongly typed language can fix. The biggest one is related to third party JS/TS libraries. If the object was 'any' at some point, if you make an invalid cast Typescript will trust you. If it's a union type, typically (Obj | undefined), everything will work fine until one day the object is undefined and everything blows up. You won't know because everywhere in your code the object can never be undefined.
Essentially Typescript Is too trusting. In Java or similar languages, if something comes in as Object you know all bets are off. If you cast and it succeeds you know 100% what kind of object it is. In Typescript it's possible for the type to look fine but be completely wrong, or worse, wrong in a subtle way. And there's no way to fix this without breaking interop with JavaScript.
Since Java has always been strongly typed and has a ton of libraries available this isn't an issue in Kotlin.
Java/Kotlin are just far better designed languages and no amount of banging on JS is going to make it as well designed. Look at PHP, after 10+ years of trying to make it reasonable it's only "okay", there's too much baggage.
The bytecode for Java/C# is much more compact than JS, the runtime is about 10x faster, they have far better standard libraries. They will compile down easily to wasm since their VM's essentially already compile down to native machine code on whatever platform they run on. It's as easy as adding a "wasm" machine target to their runtime and porting the garbage collectors.
I fully expect Wasm to wipe out front end development as we know it. Java and C# are far better suited for what the web has become, essentially an application platform. We've seen the future already, just 10 years too early, in Java applets.
> If it's a union type, typically (Obj | undefined), everything will work fine until one day the object is undefined and everything blows up.
Not if you set strict: true in your typescript options, or you can separately enable just strictNullChecks
> Essentially Typescript Is too trusting. In Java or similar languages, if something comes in as Object you know all bets are off. If you cast and it succeeds you know 100% what kind of object it is. In Typescript it's possible for the type to look fine but be completely wrong, or worse, wrong in a subtle way. And there's no way to fix this without breaking interop with JavaScript.
Instead of casts that fail, typically you would use type guards to deal with this. That way you can isolate unsafe casting code to a single place.
> Since Java has always been strongly typed and has a ton of libraries available this isn't an issue in Kotlin.
Kotlin's Any is pretty much the opposite of TypeScript's any. In TS it disables type checking completely (according to the docs). In Kotlin it's the top type (similar to Java's Object type), which anything conforms with, but doesn't expose any operations at all (except for the stuff that the JVM provides for free).
Yes, this is the effective difference between Typescript and typecasting in most other languages. Typescript, since it compiled to js, doesn't know the runtime type so it can't use reflection to make sure casts are valid. It just takes your word for it. If the cast isn't always correct prepare for a world of pain trying to track it down instead of getting an exception on casting failure
I encountered this the other day, while playing with typescript for the first time. Is there a good solution, such as a utility function that does a runtime check before casting? I suppose I could write one for each type cast, but it seems like I shouldn't need to.
I'm sorry to say but... This check won't help with accidental incorrect casts. Typeof in typescript is a pass through for the JavaScript function, so it only returns what the JS version does.
A check for a string or number will work, but a check against a typescript object or something complex like a union type will just return 'Object'
Note that Typescript tries to follow JS to remain a superset that easily compiles down, and the metadata API is currently a stage II Ecma proposal so it's marked experimental.
It should be fairly easy to build a types casting method using that.
> Kotlin's Any is pretty much the opposite of TypeScript's any. In TS it disables type checking completely (according to the docs). In Kotlin it's the top type (similar to Java's Object type), which anything conforms with, but doesn't expose any operations at all (except for the stuff that the JVM provides for free).
If you want top-type like behavior in TS, you want to use `{}` instead of any, since the language is structural. Anything satisfies it, but it exposes no members without a cast or guard to a more specific type.
Fwiw, microbenchmarks are not a good indicator of application perf in general. That said, nodejs is pretty fast. Also a memory hog, and doesn't support parallelization.
I always have a chuckle when JS fanatics talk about Java's "huge runtime" when Node and webapps use stupid amounts of ram. Java's memory efficiency is stellar in comparison.
No, Swift requires "any as? Cast" which returns "Optional<Cast>" (or you can use "any as! Cast" which at least crashes instead of happily proceeding with the wrong type).
Your critique is about JavaScript, not about TypeScript.
Your argument is that TS blindly trusts 3rd party typings, but Kotlin has the same exact issue! In fact the Kotlin docs say to use TypeScript typings, or "dynamic" (read: unsafe) mode for 3rd party libs. So I would expect the same level of safety between TS and Kotlin when it comes to 3rd party libs.
I personally prefer TS because it's safer: with literal types and mapped types, my code is far safer than the equivalent Kotlin. It will surprise you how often you use these features.
> Since Java has always been strongly typed and has a ton of libraries available
Means nothing for alt-Java languages' JS target. While the host language gets the Java ecosystem for free, to replicate on the client every Java library needs to be cross compiled.
It's a non-trivial endeavor, one that ClojureScript and Scala.Js can largely avoid due to their already having a rich set of cross compiled frameworks and libraries in their respective ecosystems.
Not sure what the story is with Kotlin here, seems pretty tightly coupled to Java.
The Java classpath (built in API) will be an issue possibly. It's easy to compile third party libraries statically with your app. Just build a fatjar with maven shade and strip it with progaurd. You application will be only the Java runtime and code you're actually calling.
I've tested this with Java console apps and it makes them very small. I'm guessing you could get your app size under 50kb
I think that ClojureScript fits this criteria as well.
1. The resulting file size is great, heavily optimized and tree-shaked with Goog Closure Compiler. It seems Bucklescript does even better in this regard!
2. It's there, easy to use, does what you expect. A++ would interop again.
3. The ClojureScript community has some of the best libraries for web development such as DataScript, Specter, Reagent, Re-frame, Om, Rum, etc... Not to mention all the other cool built in stuff. core.async, core.logic, core.spec have been invaluable to me.
4. In my experience, you can re-use most of your core Clojure code in CloureScript. Just put them in a .cljc file. There are platform specific APIs as well, and those will be specific to your platform of course.
The only annoying thing is that you have to define your macros in a different file as your .cljs if I recall correctly.
5. The compiler is fast, but to be honest it doesn't even matter because of the state of the art tooling and browser integration you get during development, you don't have to recompile the project after saving a file. If you think Webpack has nice reloading features and dev tools integration, wait until you connect to the browser via a Clojure REPL directly from your IDE (or terminal). It's just bliss.
So here's my take. From a *-to-js language infrastructure point of view, we already have multiple good choices. However, from a language design/culture perspective, both of these languages are esoteric and most likely always will be. They won't catch on, like TypeScript might. Lisp isn't new. ML isn't either. There's a reason they haven't taken over Java on the server side of things for example.
For the foreseeable future, these languages exist just for the minority of programmers who have decided they want something better.
You can have both, so the question is, what's your poison? LISP or ML?
Edit:
While I'm here, might as well link to the Simple Made Easy talk by Rich Hickey. The other thing (aside from inventing Clojure) that gave him prophet-like status in the community.
Rich Hickey is one of the rare breed of thinkers in the programming world whose ideas have great relevance even if you're not interested in the language he invented.
Any good tutorial for Kotlin as a JS replacement? I am one of those people hating JS (and I did some very advanced JS web apps pushing technological possibilities) and would love to have something sane before WebAssembly can completely obliterate JS and I can switch to whatever language I like. Thanks for any hints!
I never tried Kotlin, but I'm working with Scala.js since 1.5 years and am very happy with it: http://www.scala-js.org
This made me love the frontend again.
No, he means 10.000 which in parts of Europe is the same is 10,000 in the US. 10000 is the same thing as both. What's strange to me is that you seem to know this but still want to say something about it.
Its like an Englishman saying colour and you saying, "you mean color, right?" Just seems unnecessary.
>What's strange to me is that you seem to know this but still want to say something about it.
Because on a world-wide message board it's still inherently ambiguous. My comment was meant to serve two purposes. First, to draw attention to the ambiguity for others who use `.` as a decimal separator and read "10.000" as "10" (as I very nearly did). Second, to seek clarification because there is a non-zero chance that the OP is in fact a precision-minded person who saw a small productivity improvement when switching to Kotlin.
>Its like an Englishman saying colour and you saying, "you mean color, right?" Just seems unnecessary.
More like when an Englishman says "biscuit". in many contexts I would ask for clarification because my definition of "biscuit" is different from the common British usage, but it's also possible that the Englishman knows this and really does mean "American biscuit".
As an Englishman who still doesn't quite understand what an American biscuit is or why on earth you would put gravy on it, I second your defence too. It was a perfectly polite clarification.
If you've not actually experienced them in person, it might help to think of them as small savory (not sweet) cakes, typically served hot. Generally salty and fairly high in fat. They serve much the same role as croissant, but from an area where much of the flour was "pastry" flour which lacks the structure and tensile strength for yeast - raised bread.
An American biscuit is actually a Scottish scone.
(Note, not what most people in the US or England know as a scone but a specific item historically made in Scotland that is identical to the US biscuit).
Sorry I didn't respond very timely, but after considering the comment chain, I think perhaps you are right. The irony, now, is my comment was the unnecessary one.
I think you're reading into it wrong. 0xffff2 isn't correcting the parent, rather trying to clarify that by saying 10.000, that would be equivalent to 10000, since in America we use commas instead of periods for thousands denotation. We can't automatically know where people live and what standards they use, so we ask to clarify.
It's not a matter of geography. It's a matter of language. In English, a period acts as the radix point and a comma acts as a separator. It's a common error for people who learned English as a second language to use the convention of their native language when writing in English.
No, it's a matter of geography (or should I say locale). Raised in South Africa, we English speakers were taught to write "ten thousand and forty one-hundredths" as
10.000,40
which is exactly the opposite of the US based
10,000.40
So it's locale rather than language that determines this.
Honestly that doesn't look "completely typesafe": what are those "source"s? Don't they refer to another element? What happens if you make a typo there?
I wager there is type inference going on and that the IDE will supply red squiggly lines beneath the expression if the author were to supply something that would not one way or the other convert to the types that source can consume.
What will the compiler infer other than a value of type string?
> to supply something that would not one way or the other convert to the types that source can consume.
Well, clearly `source` takes a string, so it will happily accept "produckname" and blow up at run time.
Short of macros I know of no other compile time mechanism that would enable "safe" strings. The usual workaround is to not use plain string values at all and wrap in a sealed type.
Hey this sounds like a great setup. I've been wondering if Kotlin -> JavaScript could work for React. Do you have some more documentation or code that you could share on how to setup a project?
Given that this was merely a week ago and you had to write your own bindings, I'd wait a bit with your evaluation to see whether other annoyances come up. That productivity boost is not likely to remain that high :)
I saw the light last week as well. You can combine this with Quasar to get Erlang style concurrency. I wonder if you can somehow hook up, idk RxJS on the client with RxJava on the server for seamless integration.
The JSON story is also amazing.
This stack is gonna be the biggest deal in the world.
Not to mention that you can run it on Android and soon enough iOS. This is unprecedented.
Sorry, I firmly believe that nothing gets Erlang-style concurrency except Erlang. Other ecosystems may get something that mimics Erlang's concurrency, but the imitation is skin-deep.
a) they use the same method names like the `kotlin-html` package ("div{}" et. al.), only they create ReactElement instead of manipulating the dom. This could be confusing.
b) The type-safe scoping mechanism, so that each scope has it's correct prop-setters and won't inherit setters from a scope further up is rather complex. It uses extension methods with multiple receivers plus operator overrides for `invoke()`.
That is rather complicated to follow so I want to try it out for some time to check if there's confusion or subtle bugs.
c) I haven't optimised for (allocation-)performance yet.
d) I'm using an early-access version of kotlin 1.1.4 which isn't out yet.
With kotlin I seldom need a framework, because the standard-library is so rich.
In general, when I tend to follow a data-flow ("redux" for JS people) architecture, but have a different approach when it comes to side-effects:
My state is always a serialisable description including running side-effects.
So even network-requests can be reconstructed from a state-file.
Also I decouple View/React from the actual state via interfaces.
Meaning my state doesn't necessarily contain the data in the format my Views need, but it's able to supply the data via delegation.
Curious what the output of this is(photo), it looks like it would create something with the div/textfields? Is it an inline span element that is editable but not an actual <input type> ?
I'm behind on frameworks, I just build with html/css/js/php
There are a few concepts that I don't personally use but see on a page I can literally build anything drawn on a piece of paper (for web) but the question is how long will I take?
Also the security aspect and whatever with regard to using Laravel vs. using your own PHP.
While you can do Kotlin development in Eclipse (and others), IntelliJ is basically _the_ IDE for Kotlin, since they are both developed by the same company (JetBrains).
Because it's probably the most-advance virtual machine out there.
It has a massive ecosystem, many years of testing and battle-tested devops-tooling.
It has everything.
I get along with ReactNative, it's decent. The data-application part of my last android-app was already written in (JVM-)Kotlin and in the futures the UI will be as well. ;)
TL;DR: JS with a ton of make up and tooling to not write JS is not as horrible as it used to be.
Well. That doesn't make it awesome either.
You just traded some problems for others.
Like the damn source map never working correctly, the build time being longer and longer, and the never ending list of plugins you expend every day after stumbling on yet another small-minuscule-not-that-important-I-swear detail.
The tool chain you spend more and more time on, despite all the "5-minutes" bundles provided by facebook or on githubs.
Explaining things to new comers has never been as difficult as it is now. Teaching is a pain.
Choosing your stack is a dangerous bet, and the odds and steaks are changing all the time.
If you opt-in for a flux architecture, you will soon write Java-as-in-the-90 on the frontend instead of Javascript, with so many adapters and design patterns as layers you will become angry.
If you don't (you-totally-don't-need-redux-to-use-react-guys) then most documentations and tutorials will not answer your questions, and you are own your own solving every single problems. Even the simplest ones, like redirecting on a route after data changes and closing a panel at the same time.
"Libs, not framework" means you need to relearn everything, rewrite a lot of code, tests and doc and renew maintenance for each new project. Meanwhile nobody agree on what a the proper stack is.
JS, despite all the paint on the rust, still has the old gotchas. This is still weird. ";" is still auto inserted. "==" still compares like nothing else. Errors come in different so many different forms it's not funny. Basic maths assumptions like commutativity are out of scope. Still no namespaces, but instead we use monstrosity like webpack and incompatible import systems to encapsulate things. Stdlib still doesn't have essential things like hashing, string/date formatting or encoding. Even basic operation like removing an element from an array using an index is a pain.
No, I'm sorry, JS has not become awesome. We just arrived to a point were we accepted we have everything to built with it and agree to pay the huge price for it. That's all.
Projects like vue.js makes me think there is still hope we end up with elegant tools from people who care. But right now I just embrace the madness and make money with it: all those poor customers don't realize the trap the current mindset lead them to, and I have so many solutions to the problem they should never have had to sell them.
>No, I'm sorry, JS has not become awesome. We just arrived to a point were we accepted we have everything to built with it and agree to pay the huge price for it. That's all.
Yep, this is the crux. ES6+ has finally made JavaScript look more or less like the languages we were using in the mid-90s, so I appreciate that, but it's not like it's some glorious boon to the developer community.
Any gains from the new semi-tolerable semantics are quickly overwhelmed by requiring layer-upon-layer-upon-layer of crap, including hundreds of dangerous random modules from GitHub to compensate for the virtually non-existent standard library and a "build pipeline" that consists of several unrelated runners, bundlers, transpilers and transformers to make code that's actually usable in real environments.
JavaScript is a tragedy for the development community from start to finish, and its increasing prominence should disabuse us of the notion that development is dictated by meritocracy or any such fantastical nonsense like that. Marketing and groupthink have just as much pull here as anywhere else (if not more because so many of us egotistically believe we are immune to it).
Everyone complains about the build tools, but they simply haven't thought through the issues.
Let's say you were writing the web using Python. New browsers run v3.x, but old ones run 2.x or even 1.x. Further, features in newer versions of v3.x won't work on older versions of v3.x. New browsers could include all three runtimes, but old ones would be SOL.
How do you use v3 features and target v2 or v1? You must transpile knowing that newer browsers also have v2 and v1 engines included too.
You have hundreds of Python files in your system. Delivering hundreds of files is simply not practical on HTTP/2. You combine them and now you have webpack.
What about libraries? As big as the standard lib is for Python, it doesn't do everything. You use pip or conda and now have npm/yarn.
What about code consistency? The solution is pylint.
What about testing? Add that to your chain as well.
It's the unique issues of the web -- NOT Javascript -- that makes the build pipeline what it is. Until a few short years ago, these things weren't even possible. Today, if you know node/npm, webpack, babel, and eslint, you know the overwhelming majority of build processes.
I'd finally add that make, Jenkins, etc are far more complicated to learn than the JS systems.
The original crappy design is definitly a problem with JS: the typing/testing, the lack of namespace import, the emptyness of the stdlib. Half of the problems we have today are directly correlated with this.
Most of our tools are not here to make things better, but to avoid sucking too much.
So yes, forward compat is an issue. But that's hardly the one I'm complaining about. I'm really ok with not being able to use spread, but I can live with it. I'm not ok with having to use npm + webpack to download, install, isolate and bunddle a remote lib to do a leftpad.
I'd say you have one. If you had one before, you didn't know what really happened when you went `var that = this;` and aired your opinion about how `this` is being stupid. So you got the arrow function, where `this` acts the way you expected before, when you said it was stupid. You can't complain about both.
The scoping of `this` has never really been too hard to understand. I learned it my first week doing JS.
Agreed, I stopped recommending React to beginners. I still love it and think it's the future, but in the sense that it's the new low-level. Eventually I think it will be standard to compile futuristic, high level, built-for-apps languages into React code. But for now, makes sense to just use a batteries-included framework. I don't know what the most sure shot is there though. Ember? Vue?
Mithril. Much simpler than anything else and batteries included. It's a great way to get beginners into front-end frameworks and gain knowledge that transfers easily.
Mithril is nice. W.r.t. going for batteries included, it's still a bit minimal for my taste. Personally I would lean towards something more dogmatic, in the spirit of Rails. For example, things that I would miss from Ember: ember-data, models (with relations), controllers, opinions, integrated tooling, etc ... But Mithril looks cool I've been meaning to play with it too. You're right that skills gained from learning Mithril will be more widely applicable to general front-end dev than Ember.
Rails is great, but where it really shines is server side apps, content sites, blogs, CMSs, etc .. If you know you're building purely a SPA, Rails isn't really the right tool for that.
I'd argue that more than half pure SPAs do not need to be SPAs, and can be written effectively in Rails with someone who knows it well, in less time, with less bugs, and more test coverage.
If you insert the semicolons yourself and don't depend on the auto insertions, you don't have to worry about the edge cases where the lack of a semicolon would introduce a bug.
"==" still compares like nothing else.
Use === if you want to be explicit.
Errors come in different so many different forms it's not funny.
I agree, but this is only a problem with new API's like service workers, what where they (TC39) thinking when introducing unspecified errors !? That can't even be detected !! There's already a convention to use err.code to specify type of error, use that please!
Basic maths assumptions like commutativity are out of scope.
The commutativity is the same like in classic Maths I think, it's just he floating point errors that mess things up.
Still no namespaces, but instead we use monstrosity like webpack and incompatible import systems to encapsulate things.
The module system (require) in Node.JS comes from user-land, and can be implemented in pure JavaScript, so you can use it in the browser too!
Stdlib still doesn't have essential things like hashing, string/date formatting or encoding.
We have .toString, parseInt, atob, btoa, etc. The rest can be implemented in user-land: var md5 = require("md5")
Even basic operation like removing an element from an array using an index is a pain.
I think it's fine. If you use a named list {} you can "delete foo[bar]"
Besides, JS is the only language I know where half of it is recommended to not be used.
> If you insert the semicolons yourself and don't depend on the auto insertions, you don't have to worry about the edge cases where the lack of a semicolon would introduce a bug.
But that's not the point. The point is my students will forget the semicolon in some code that is not properly checked, and it will work. Most of the time. Until it doesn't.
> Use === if you want to be explicit.
No shit sherlock ? But again, half of the language is forbidden. And you know somebody is going to write != instead of !== one day, tired.
> The commutativity is the same like in classic Maths I think, it's just he floating point errors that mess things up.
Nope. Nope. Nope. Nope.
$ node
> [] + {}
'[object Object]'
> {} + []
0
> We have .toString, parseInt, atob, btoa, etc.
Come on, you never used Java, Perl, Ruby, Python? Any language with decent string formatting ? That doesn't need a leftpad dependancy ? That can format date without importing 34ko of moment.js ?
> The rest can be implemented in user-land: var md5 = require("md5")
And then you get the current 3Mo pages we all hate. Are you even serious with your arguments or is it trolling ?
> I think it's fine. If you use a named list {} you can "delete foo[bar]"
A mapping is not a list. It doesn't perform the same. You can't push and unshift. You can map on it without Object.stuff. Length is a costly operation. Concat without spread is a pain. And how do you get the "next 3 elements after the 2nd" ?
> JS is the only language I know where half of it is recommended to not be used.
Jamie Zawinski (who else) about C++ in 'Coders At Work': When you’re programming C++ no one can ever agree on which ten percent of the language is safe to use.
> And how do you get the "next 3 elements after the 2nd" ?
.splice(2, 3) (am I missing something?)
> > The rest can be implemented in user-land: var md5 = require("md5")
And then you get the current 3Mo pages we all hate. Are you even serious with your arguments or is it trolling ?
md5 node lib is 32kb unbundled. If you meant 3Mb pages that's ridiculous. Modular necessity at the hands of the user is good, and it's something that's been present in every project i've worked on in a less granular fashion than modern npm-driven apps can deliver.
well, objects are not iterables... ??? unless you decide you want them to be, in which case you can make them such and design them in a way that they work as such?
The least elegant way is Object.keys().map(key => etc) which is really not that hard to work with
edit: it's a phony premise to begin with actually. Iterables have order, objects have mapping. I am less experienced with other languages so I probably don't understand OP's statement clearly. I just think OP's context is lazy thought rot about what's becoming a fairly elegant language. BUT I'm a noob.
> Besides, JS is the only language I know where half of it is recommended to not be used.
That's what you get for having backward compatibility I guess. If the standards committee would break my old code I would probably quit and start a sect. I would call it "ReactReduxReduce" (RRR).
> The point is my students will forget the semicolon in some code that is not properly checked, and it will work. Most of the time. Until it doesn't.
Some people prefer writing JavaScript without semicolons. How do they not have bugs all over the place ? :P
> Some people prefer writing JavaScript without semicolons. How do they not have bugs all over the place ?
The same way that people who write with semicolons avoid lots of bugs: linters and transpilers and tests.
That said there is only one rule to remember when not writing semicolons, the easy to remember "winky frown" rule: all frowns must wink if they start a line/statement. ;( ;[ ;`
Our projects' linting rules specify no semicolons, except when necessary; this means that we will _very rarely_ write something like this when we want to iterate over a small literal array:
;['foo', 'bar'].forEach(function (f) {
it(`has an ${f} field`, function () {
expect(......)
})
}
That said, we tend to use that construct extremely rarely, such as in a few test cases where we are doing the same kinds of things on two groups of items that need different descriptions.
It's amusing how my karma went up and down depending on whether the given person had understood the joke or not; eventually normalising at exactly 1. Nevertheless - I can't blame them as there is no way to tell the irony on the net.
Who I can blame is the original parent of this post who was quite confidently stating that omitting semicolons never causes any issues in his code (which is either a statement bounded by scale at which it works for him or it is not error-prone only in specific situations); and then just edited it so that it did not contain that specific line.
>Besides, JS is the only language I know where half of it is recommended to not be used.
Then you probably have never heard of the most successful (by the number of infrastructure written in it with amounts to almost everything in commercial OSes, network services, Google's search backend, most games, most commercial applications, databases, compilers, the JVM, all browsers, etc) -- C++. Where "half of it is recommended to not be used" also.
>No shit sherlock ? But again, half of the language is forbidden. And you know somebody is going to write != instead of !== one day, tired.
No shit, Einstein. That's why people use linters. In C you can corrupt memory with a stray ++ or alter flow with = instead of ==, fuck things with & instead of && and more. If we threw languages because they allow for errors, we'd have no language left.
>Come on, you never used Java, Perl, Ruby, Python? Any language with decent string formatting ? That doesn't need a leftpad dependancy ? That can format date without importing 34ko of moment.js ?
So? You've never heard of a language without "batteries included"?
>And then you get the current 3Mo pages we all hate. Are you even serious with your arguments or is it trolling ?
Are you? Before the problem was that there's no hashing support, now that hashing support is third party and makes pages bigger. As if a language should include everything in its standard library. I assure you most of the "3MB pages" is assets like images, not JS.
C++ also gets a lot of hate for half of it being forbidden to use.
"If we threw languages because they allow for errors, we'd have no language left."
Correction: we'd have Ada, some of those "prove your program is formally correct" metalanguages, and possibly Rust. Probably some others with which I'm not familiar.
It's a cargo cult/myth that was circulating from back when I was in university that Ada is some super fault tolerant language because they use it for rockets and stuff and because they designed it to be super secure.
It was indeed designed to be more secure than C and to be an official government/military use language, but no "super secure" and allows for errors just fine.
Besides, they do rockets in C just as well (with certain rules).
Although the source of the Operand Error has been
identified, this in itself did not cause the mission to
fail. The specification of the exception-handling
mechanism also contributed to the failure. In the event
of any kind of exception, the system specification
stated that: the failure should be indicated on the
databus, the failure context should be stored in an
EEPROM memory (which was recovered and read out for
Ariane 501), and finally, the SRI processor should be
shut down.
In any case, I'd argue that converting a 64-bit float into a 16-bit integer is a much different class of problem from mixing up assignment and comparison operators. But yes, you're right, even Ada is not perfect.
"Besides, they do rockets in C just as well (with certain rules)."
Yes, they do. Those "certain rules" are codified in the MISRA C standard (or derivatives thereof, like with the JPL and JSF coding standards). Said standard is way more strict than the sort of thing normally implied by "C programming".
>In any case, I'd argue that converting a 64-bit float into a 16-bit integer is a much different class of problem from mixing up assignment and comparison operators.
Is it though? Because in the end it's the same issue of conversion between types (coercion vs casting, but still).
A linter solves 100% of the "issues" you describe related to ASI and type coercion. Every single major editor or IDE has support.
> [] + {} '[object Object]' > {} + [] 0
The first case deals with an array, an object, and a concat operator. The second case deals with an empty code block, an array, and a unary math operator. None of that has anything to do with commutative properties because neither unary operators nor string concatenation are commutative in ANY language.
> Come on, you never used Java, Perl, Ruby, Python? Any language with decent string formatting ? That doesn't need a leftpad dependancy ? That can format date without importing 34ko of moment.js ?
The standard date object sucks, but that's no huge wonder because they were required to make it behave like Java (it even has an old Java Y2K API bug where it returns only the last two year digits).
We used to have horrible proceedural, class-based math libraries. Next we moved to underscore. That was replaced with a much faster lazy libraries. The current trend is toward even faster transducer-based solutions with more functional options as well. Which would be the correct language standard?
Having been bitten by bad APIs in the past, there's been reluctance to move too quickly in adding extra APIs to the core language. I think the current solution of adding good primitives and leaving the rest to good libraries is an ideal solution (after all, JS can add things, but old mistakes are forever).
> And then you get the current 3Mo pages we all hate.
We had a multi-MB page. Tree shaking got rid of most of it. Moving the biggest libraries to shared CDN versions that lots of sites use gets rid of a lot of load time as well. Using webpack to chunk your site also reduces the payload to a manageable size.
> A mapping is not a list. It doesn't perform the same. You can't push and unshift. You can map on it without Object.stuff. Length is a costly operation. Concat without spread is a pain. And how do you get the "next 3 elements after the 2nd" ?
A sparse list uses a map (in fact, Array is defined as a special case of a standard Object -- JITs simply optimize to more efficient data structures when your data allows). Further, if you start deleting in the middle of a list, it will not be optimized past a linked-list anyway (in ANY language).
If I were needing to do a bunch of item removal, I'd use this.
var removeNth=(x,s)=>x.splice(s,1); //a bit faster
var removeNth=(x,s,e=s+1)=>x.splice(s,e-s); //a bit more flexible
Array.prototype.removeNth=function(s,e=s+1){this.splice(s,e-s)} //a bad idea, but possible
> If you insert the semicolons yourself and don't depend on the auto insertions, you don't have to worry about the edge cases where the lack of a semicolon would introduce a bug.
I think this is not correct. It will still insert a semicolon where you don't want one. It's not like there's a compiler flag to turn insertion off.
I just tried to get the linter (JShint) to break some valid code, but it didn't. So you can actually rely on the linter to insert the semicolons for you. It would be interesting to find out if there are any cases where the linter will insert the semicolon in the wrong place.
No. If it's missing it's inserted obviously. That's why you shouldn't omit it.
Here are the rules for parsing if you're interested
When the program contains a token that is not allowed by the formal grammar, then a semicolon is inserted if (a) there is a line break at that point, or (b) the unexpected token was a closing brace.
When the end of a file is reached, if the program cannot be parsed otherwise, then a semicolon is inserted.
When a "restricted production" is encountered and contains a line terminator in a place where the grammar contains the annotation "[no LineTerminator here]", then a semicolon is inserted.
> If you opt-in for a flux architecture, you will
> soon write Java-as-in-the-90 on the frontend
> instead of Javascript, with so many adapters
> and design patterns as layers you will become angry.
That's not necessary. It depends where you're working.
I agree that teaching the complete stack is a pain. I guess there is `create-react-app` to help you there, but its scope is very small: you're not going to get static typing for example.
Well, if you want routing, you need a provider, and if you want to pass your store to a component, you need a container, and if you want to react to store change, you need a reducer, and if you want to make async action with your store...
There is an "-er" somewhere at every step.
You pass callbacks here and props there, and then reference them the other way around. And then you plug stuff in your componentWillReceiveProps, or is it in compomentWillMount or componentDefinitlyDidMountISwear ? But wait this is a new style class, so you have to call super(props) in constructor insteat of getInitialState unless you have a super Esx plugin but then remember that your onClick callback need to rebind this otherwise you'll get 'attributeOnThis' is undefined somewhere in your bundle and you'll have a fun time.
When you come from flask, Django or Ror, having to deal with such API feels like going back to before the 2000 bubbles, where corporates tried to port their knowledge to the Web.
I'm sorry but a `reducer` isn't a 90s-era Java concept at all [0], and you don't actually need to use any of those other things. This is beyond ridiculous.
You write syntactic sugar <div className="foo">abc</div> to turn into React.createElement('div', {className:'foo'}, 'abc') which generates an object {...stuff, tag: 'div', attrs: {className: 'foo'}, children: 'abc'}. Your final object is then compared to the previous object and any differences are manually written to the DOM in an efficient order.
My biggest problem is "the complete stack." Which one? How many months will it be the blessed way of doing things?
As soon as I get some work outsourced, here it comes yet another build system and yet another complete stack I have to get expert at.
Javascript lacks a standard library (a mistake from the beginning) as well as standard tools (can't blame Netscape for this, but today we could totally come up with something more definitive.
If JavaScript had a standard library from the beginning we would be replacing it now because it wouldn't support Unicode or promises or async or whatever is coming next.
The w3c cannot break the web. Once something is in the language a certain way, it stays (technically, there have been a couple small breaking changes, but the fact that you don't hear about them speaks to their size and impact)
We don't have precognition. It is not safe to pick a brand new framework for an important project right away, we have to wait a bit first to make sure it is being maintained well.
Note that that has nothing to do with math. It has to do with braces being used for both blocks and object literals.
Of course, I'm not too happy about the automatic coercion of everything and anything to either strings or numbers, but if you want consistency, try parentheses, or a + [], where a = {}.
plain old javascript is perfectly fine. es6 is better. if you can't write good apps with js it is because you aren't a good programmer and you wouldn't be able to write good apps in any language.
Omg, so this guy thinks he knows why I'm hating Javascript? Well, it's definitely not because of the lack of types, or because without Prettier my code looks shit, neither would it be the lack of E6/ES7 features since I'm using Coffeescript 2. No, I hate Javascript especially for it's conitnuously changing ecosystem being forced upon you. You named Dan Abramov? Ah, the guy who deprecated almost all flux in favor of his own idea (Redux), or by deprecating React Mixins, because he thinks Mixins are bad, Higher Order Components is the new holy grail?
If I am looking for a job as a Javasript developer at the moment it is not about my coding skills, it is about my willingness to adopt all those hyped technologies, and the author of this article is just making it worse.
I also hate Javascript for all those people reading this that think I don't understand it yet, and are going to explain me how great ES6/ES7, Promises, and/or Typescript are. Please don't.
> Ah, the guy who deprecated almost all flux in favor of his own idea (Redux), or by deprecating React Mixins, because he thinks Mixins are bad, Higher Order Components is the new holy grail?
How dare the man spend hours and months creating something others ended up finding so valuable they discarded their own things.
If you really prefer the bug-inducing mess that were mixins, you can still use React.createClass (with full mixin support) by using the react-create-class module: https://yarnpkg.com/en/package/create-react-class
Which, by the way, is maintained by the same people you are so upset with. For changing their mind about the API of something they gave you for free.
> If I am looking for a job as a Javasript developer at the moment it is not about my coding skills, it is about my willingness to adopt all those hyped technologies
If you're looking for a job as a developer I hope it's always about your ability to adopt to changes and new technologies. Because that's what distinguishes a developer from somebody's "nephew who's really good with computers" and is willing to work for scraps.
Any formal education worth its salt is about giving you that ability rather than just teaching you the status quo. If you want a stable ecosystem that doesn't change, try specializing in legacy technologies. There's still a ton of software written in languages that are well past their prime and large companies will pay good money for people willing and capable of working on that.
Maybe you should stay away from JavaScript for the next 20 years and come back when people consider it quaint and archaic and don't try to apply new ideas to it anymore. This isn't hyperbole, this is an honest suggestion.
Sure, but adapting as a JS developer is mostly about relearning how to do the same thing using different libraries and frameworks.
As an embedded developer I am able to build upon my existing knowledge and am deepening my skills in embedded, Linux, C++, etc.
I'm not learning new programming languages and operating systems every couple of months.
And this is how it should be, otherwise you'll end up being always average, no matter how much you learn.
> relearning how to do the same thing using different libraries and frameworks
This is hell to me, such nausea-inducing inefficiency. I feel like I'm wasting my time and cluttering my brain needlessly in those scenarios and it drives me mad. What if you were a woodworker and every few months all the tools and equipment in your shop changed in various subtle ways? It makes very little sense to me in the long run. True mastery depends upon some amount of consistency in your environment. It's the only way you can build on what you knew before (because it didn't change when you weren't looking) to do more complex and interesting things.
Direct DOM manipulation. Event delegation. MVC. MVP. MVVM. Component trees. These aren't libraries, they're not unique to JS.
I've been doing frontend development since the 1990s and in many cases I could still solve the same problems very similarly to how I solved them 10 years ago (except I would probably forego jQuery and use the web APIs directly thanks to widespread browser support).
The reason I instead spent my time learning Backbone and Knockout and Angular and React is that the kind of problems I'm solving has changed over the years.
Your characterization is also hyperbolic. You don't learn an entirely new way to do exactly the same thing and throw all the old knowledge away. Learning Backbone informed how I used Knockout, learning Knockout helped me better understand Angular, having used Angular I know what problems to avoid in React. All of it helped me build intuitions about possible caveats when looking at new tools and libraries.
I mostly don't write Angular code anymore. I haven't touched Knockout in years now. My contact with Backbone is also fairly minimal these days. But learning each of them made it easier both to learn new things in general and to understand other libraries better.
Also, React is the odd one out here. To fully understand Angular (1.x that is), I had to learn about its internals and unique concepts and terminology that are mostly orthogonal to my application but vital to avoid certain mistakes. With Backbone and Knockout the overhead was smaller but a lot of the effort in gaining proficiency was spent learning their quirks and idioms. With React there was some of that initially but all effort beyond that went into language features that come in handy outside of React and concepts that are useful beyond React or JavaScript.
When wasn't it like this.. raw js, NN4 DOM, IE4 DOM, W3C DOM, Prototype.js, mootools, jQuery, extjs, etc.
C/C++ also haven't sat still either, there are always new hotness in any language. For a language that interacts with UI asynchronously, JS has moved in a direction that tends to make it easier to user, even if it changes in the common use case. I remember the bad old days in the mid-late 90's, I'll take today's JS ecosystem.
Dude, Django and Rails have basically improved in their tech while staying conceptually sound and approachable.
This is a cop-out. You pretty much have to relearn the JS environment every other year. It's a colossal waste of time that only junior people would be willing to tolerate for a marginal (if any) productivity gain.
Django's deprecation policy is practically the same as React's, except React provides codemods for every release, allowing you to automate code migrations.
And if you think Rails hasn't changed, you've probably not been using it long enough to remember the early drama. Not to mention Django's Python 2/3 conundrum (also class-based views). Heck, Django's development on top of Python's is aptly comparable to e.g. React's on top of ES.
So what? React is one library in the ginormous pile of tiny little dependencies that come with any JS project that's large enough, and those don't have the same policy and are subject to the incessant churn of the ecosystem.
I've been using pretty much the exact same packages for a 5-year-old Django project with no need to migrate needlessly.
I've had to migrate JS apps that were just one year old and tiny, and the amount of pain was far larger than upgrading a 50k LOC Django project.
You've somehow managed to put down the hard work of community leaders from your hind-sight high horse, and at the same time, disown responsibility for the choice of library/language your software was built on. Implying the fault is on them for doing their best to push the community forward, rather than on you for shipping software built on presumably new, unproven, and highly volatile foundations. Impressive, sir.
Dan created Redux as a proof of concept experiment for a conference talk. I'm sure he did actually want people to use it, but based on comments he's made, he definitely had no idea it would became the de-facto standard state management tool for React apps. Frankly, he's spent more time telling people _not_ to use Redux if it doesn't fit their use cases than actually trying to advertise the library.
You don't have to use any of the gobs of new JS syntax, libearies, frameworks, techniques, packagers etc that come out on a regular basis. Just keep that in mind when you're reading about them and realize you can decide for yourself what to adopt after careful evaluation.
Exception being if you work on a team that has agreed to adopt something new together. If you're of a different opinion and lost the debate you pretty much have two options at that point!
If your only reason to hate a language is that it's making improvements (that you can't/won't keep up with), it would seem that language is doing something right
It's not that it's improving, it's that it's changing in every direction at light speed, and if you say went on holiday for a month offline when you come back the odds that you find the syntax and the ecosystem substantially different is very high. And whether all or most of these changes are indeed improving anything is doubtful. I personally can't follow JS anymore, it's a storm of not-so-news from every direction.
Since ES6/2015 the changes have been pretty minimal, so I disagree with your assertion. Since 2015 I find that async functions is probably the most alien addition... and the handful of others that are significant are mostly ignored or very natural extensions.
The shift from callbacks to promises is kind of alien, but frankly that was started well before 2015 even. The .babelrc I use for node projects is pretty simple as well, here's one I use for an AWS Lambda build...
So that's literally 3 things that aren't in spec yet, and a couple that work around the runtime not having them. Most of what's going in is already in, or relatively well established and on the way.
Now, you do have to include a lot more if you want IE11 support, but hey, that's a different thing. I'm not sure what exactly you're having a trouble wrapping your head around.
Don't compare JS (or any language) to any other language - or any language to another language. People wrote a lot about it (Your language sucks because... - type things). JS is just another language.
The JS ecosystem is wild and moving way too fast, but even that is not really the trouble with it: it's that it's being overused.
He mentions DHTML at the beginning, which was the perfect example of using too much of something: mouse trailing bouncy balls with falling snow, my, I don't really miss those days.
Yet we're here in 2017 and React & Co. is crippling the web. Plain simple news or a blog site rendering with JS? AMP, loading megabytes of Javascript, claiming to speed up the web? When your product is text, how about you serve text and maybe only boost it or do analytics with JS? I know it's not fancy, but for a lot of sites out there, JS based rendering is completely unneeded.
In case of web apps... A little while ago I listened to a talk of front end colleagues, claiming that we'll speed up the site by async calling some blocks, so the initial content will get down fast and the less important ones will follow. When I asked if we're measuring the very end render time - the one that heats the CPUs, because you offload the rendering to the client, which can get quite stressful - the answer was 'no', mostly because nobody knows how to do it. I also asked about how screenreaders will work with this, and they thought I'm talking about mobile, which is extremely sad, and no, I'm unaware of any screenreader-friendly JS based app. (Screenreaders are the programs literally reading out the text for visually impaired.)
Google and FB offers fallback, HTML-only solutions to their services, because the realised their things don't work on slow connections and/or slow devices. Maybe this should be taken as a sign.
- The paradigm shift in writing interactive web pages in the React "write your app like a game that re-renders every frame"-style is extremely compelling. You are correct that there are plenty of largely static sites that do not need JS-based rendering, but for people wanting to develop single-page web apps or other interactive content, that mindset is a godsend.
- We recently re-wrote an ecommerce site with React and it is WCAG 2.0 AA compliant. To our knowledge, and to the independent firms that have audited our application, screenreaders have no problem with it. You still have to go through the diligence of all of the standard a11y-friendly techniques like semantic markup and thoughtful keyboard navigation, but React at least does not get in the way.
Another compelling use-case of React is the ability to use it as a better templating language ― treating HTML as a data structure instead of a string, better composability of the units of your UI, and the ease of rendering to a string.
It's an interesting question whether the tendency to overcomplicate a largely static site by implementing it as a single-page app should be attributed to the average developer or to the creators of the library though.
They are blaming the carpenter. They're saying the carpenter is using a dovetail when they sometimes only need a butt joint. Of course there are cases when a butt joint is stupid, but using a dovetail everywhere is also stupid.
I've gone through the same experience this year, having picked up modern JavaScript, Angular2, TypeScript and RxJS for a project.
For me it was TypeScript that did it. I came to appreciate strong typing. And ES6, fixing the 'this' scope problems and with a conventional class syntax (I understand prototype inheritance is clever, but it's not the way I've been trained to think). I didn't get to use async/await for various reasons, but that looks to remove my third pain point (callback hell/promises/observables).
RxJS remains a mystery (I swear the API wasn't designed for humans) I use and hope it works, and combining code that use Observables with those that use Promises still wakes me up in a cold sweat.
But now going back to old territory (PHP, Symfony) I miss it. Yesterday's miss was union types. TypeScript has spoiled me.
I left React for Angular 4 this year, because I came to the realization that once I made the decision to leave the loosie-goosie world of default JS, there was no reason to have my framework be loose either.
I'm really loving the confines of a "one way to do it" framework like Angular 4. It makes teamwork much easier, speeds up development once you've gotten over the learning curve, and is damned impressive when it comes to app performance.
I'm really looking forward to the day when TypeScript platforms like Angular 4 compile down to WebAssembly and performance goes through the roof.
> We have spoken with the TypeScript team about this possibility and they have shown interest, but it seems like progress there is currently gated on adding typed objects into JS.
Once JS has typed objects, I think it can become as much of a valid compiled language as anything else. I'm still holding out hope.
> I'm really loving the confines of a "one way to do it" framework like Angular 4. It makes teamwork much easier, speeds up development once you've gotten over the learning curve, and is damned impressive when it comes to app performance.
I found thinking about apps easier in Angular too, being that bit more of a conventional system (for want of a better term) than React. Decomposing everything into a component (as I should in React) is a new skill, and will take some thought for me to get right. I started sketching it out for a personal project and went with VueJS so I could get it done quickly.
mobx fascinates me and I will be trying that - with Angular, with React, with anything it goes with.
We used Angular inside Ionic for an iOS app. Performance is OK, but I can't tell you if a different JS framework would be faster, or if it's a device/Ionic limitation. The main problem has been with rendering large sets of data (say 100+ items) in a scrolling list.
TypeScript also works wonders in React. Using a component that someone else made? TypeScript will make sure you are passing it the props it expects. Change the expected props for a component? TypeScript will immediately let you know what code you need to change for every component that uses that component.
Also NoImplicitAny and StrictNullChecks are two great tastes that taste great together. Everything in your code is now typed, AND TypeScript will now actually make you think about how you are handling (or not handling) null values. These two flags have basically allowed us to completely eliminate all the 'X is not a function of Y' and 'Z is undefined in this' errors - which is pretty amazing because for me at least these were probably the most common JS errors I get.
There is no callback hell if you're using promises correctly. While await is the best option, plain promises are pleasant to work with as well. Could you paste an example of how do you use them? If you're actually using them wrong, I'll gladly show you how to do it right.
Most of my projects I wound up switching from RxJS to xstream [1], for several reasons related to size/performance and synergy with a framework I heavily use (Cycle.js). It's RxJS influenced, but written from scratch in Typescript with a much simpler API surface and somewhat easier to reason with semantics (default "hot" and "shared" Observables versus default "cold" and "unpublished" Observables).
Also, Typescript now supports (since 2.3) downleveling async/await all the way to ES5, which is very handy.
> Typescript will give you compile-time type checking, but the actual runtime (javascript) is weakly typed.
Yes and this sucks. There have been a few bugs I've had (can't remember details) where the types or visibility looked OK in the editor but I was bitten at runtime.
No doubt due to my loose configuration - tightening up the linter would help and getting rid of null/undefined overlaps is my next move.
It looks like the author didn't mention the main reason many of us hate Javascript: weak typing.
Weak typing is great for small-scoped project without a lot of business logic. But when there's a lot of data, a lot of assumptions about it, and, most importantly, these assumptions change A LOT during development - which happens all the time in game development, for example - strong typing is a godsend.
When I make a change in a strong-typed language, I deliberately make it in such a way that the code won't compile unless I complete it. If I can make something a compile-time instead of a run-time error, I do it (and that's why I dream of switching to Rust one day - on some game engine two generations from now, unfortunately). When I refactor something, I know that compiler will let me know if I forget to change it somewhere.
Compiler is my dearest friend. Compilation errors are his gentle hints that make my code better and prepare it from failing in user's hands. Without it, I feel lost and always on my toes. I have to write tests instead. I have to launch the project (which, when it uses a lot of resources, always has overhead) and test everything by hand. When I write a big project in Javascript, I feel like a minefield, unsure of what's broken and what's not.
I can't understand how people write serious, big projects in weak-typed languages.
Me neither. It just seems really fragile and unwise.
I've had people tell me that tests deal with all the issues I would fix with a decent type system, but this seems to involve writing tests to see if things are passing the right types around, which is code the compiler of any strongly typed language already has in it that you don't have to write.
I don't even find dynamic languages faster to get started with, but maybe that's because I'm so used to static ones with good type systems. If you can call C#'s type system "good", that is. It's mostly adequate!
I was a Python developer for about 10 years before joining a startup that works almost exclusively in Javascript. I had to swallow my pride and make the best of it. I had a huge, smug chip in my shoulder.
ES6 has made the language tolerable. Enjoyable even. It has even been a decent medium for mentoring more junior developers who haven't had any exposure to functional programming in school. I can show them combinators, functors, applicatives without all of the usual ceremony in a more pure language. For that JS has been quite nice.
However for my own projects I just use GHCJS or Bucklescript and compile down to JS. Google Closure and Webpack are fine tools for shaking out the unused code and bundling everything up.
Current Python dev here. I've found the same thing. I really didn't like Javascript prior to using ES6. Now it's fairly tolerable. I'm currently building an app with a React based front end and a Flask-based API for data exploration and QAQC.
The "where does the semi-colon go" game is really annoying, but I'm getting better at it, and ESLint will let me know when I mess up. But I do enjoy a lot of the features in ES6 that make JS (EcmaScript will never sound right to me) nicer to write.
My huge pet peeve is that it feels like it takes so much work to set up an app compared to my experience in Python. But maybe that's tooling. I do have some boiler-plate code to get things working, such as setup.py templates and YouCompleteMe for code completion, and I use VirtualEnv and Pip to manage dependencies. I guess that's basically Webpack and NPM and package.json/webpack.config in JS development.
Who knows. My issues with JS/ES might be all in my head.
I'm one of those people that just trusts ASI. Once you stop inserting them you stop noticing so much.
After introducing an ESLint configuration to my team I still can't get the semi-colon lovers to consistently insert semi-colons. I made semi-colons a warning only just to see since ASI will insert them anyway. The worst offenders are the die-hards.
I was originally a semi-colon person but that's only because I listened to a talk by Crockford once and never thought to draw my own opinion. As a Python programmer I thought semi-colons were silly already and this talk only entrenched the unfounded idea that Javascript was bad in my mind.
I use them at work because when in Rome... but in my own projects there's no need for them.
Currying is a nice effect of the fat-arrow syntax for lambdas. Currying in JS is still neutered compared to OCaml or Haskell where it's the default but it's still nice. Function composition is greatly enhanced by it. Python requires special help to do currying.
As for tooling... it's the same deal in many languages despite all of the marketing. It might feel painful to get a good development environment set up for a Javascript project but it can be equally painful to setup a Python environment if you haven't done it before (or a .Net, Java, etc, etc). I'm not a huge fan of excessive configuration. But that's what you get with programmers. We're a fickle bunch.
What Python does well though is to absorb good ideas into the implementation. Function decorators, iterators, and soon mypy; when you go with the grain, Python is a wonderful language.
I disliked JavaScript, but then I read JavaScript: The Good Parts, and I saw that with a bit of discipline* there's something quite pleasant underneath. It's a book that, rather than being focussed on telling you what not to use, instead shows you various approaches to programming with what you should use. If nothing else it'll give you food for thought and unlearn you of your worst beginner habits. Mind you, it's a dated book and ES6 added a lot to the language.
*don't listen to every suggestion of Crockford though; e.g. having to hoist your variable declarations is as obnoxious an idea in JavaScript as it is in C
JavaScript in and of itself is just another little DSL, if you want to do sane things it rows your boat. What creates all the trouble is what people are trying to extract out of it and the usually inexpert community around the language (little amount of actual CS people). It would've been way easier if around 2007-2010 we added a new language to the browser, and had some standards for the average JS programmer. I haven't tried Dart at all, but if Google actually shipped it in Chrome, then others would have to follow. We'd all call them evil for that, but at the end we'd have all others follow and end up with (probably) a proper language to code in for the browser (well my actual thoughts about running that sort of code is rather unpopular and negative, but I'll keep it to myself here to not annoy anybody).
I usually find the people that complain the loudest about JS have been burned by their own ignorance.
I'll admit the learning curve for basic JS syntax can be a little high, but reading through and understanding most of Crockford's book will get you 80-90% of the way there. The rest is either ES2015 or framework-specific -- both of which build off of basic JS.
Hoisting variables is a nice practice and an easy way to enforce that variables aren't being defined in conditionals or loops and otherwise strewn about the function.
It mixes implementation concerns with functional concerns.
He recommends hoisting the declarations because that's how `var` scope works in JavaScript. Normally you'd want to introduce variables where they're actually used to provide context for them.
A variable definition at the beginning of a function implies the variable is important to understand the general flow of the function. This can be especially misleading for temporary variables like counters which only matter within a particular loop.
Additionally assigning values halfway into the function implies they had different values before, leading you to go back and check whether they were assigned anything else (and used for anything else) or just declared without a value.
Of course these problems can be avoided by simply using the new let/const variables which are block scoped, but even here Crockford would likely advocated for hoisting within the same block because of the Temporal Dead Zone (i.e. a block scoped variable exists from the start of the block but referencing it before it was declared is an error).
This is in line with his philosophy to eliminate things that produce little or insignificant value but is a potential source of bugs. In this case variable hoisting.
Of course you don't have to follow all his rules of what are good/bad parts, some of which feel a bit Byzantine at times, but he has a point and usually for a very good reason.
Check out the JsLint Google+ page for his views on more recent additions
Yes, but I thought it was pretty funny, so I forgive him his little commmercial.
Anyway, I doubt there's room in the world for yet another calendar app... so I also want to give him a break because I feel bad about him likely wasting his time.
My problem with the current Javascript culture (which definitely includes the React infospace) is basically the inverse how I felt about C++ back in the day. Then, in the early years of the second age, I felt that the libraries and frameworks I was using should use more of the then-current standard, like the STL, RTTI or whatever was hip and promosing back then.
These days, it seems that every feature that is semi-supported in at least one transpiler isn't just used (in various ways) but in fact begets a whole slew of libraries. Especially when we're talking about ways to circumvent the async-hole.
Other transpiled languages will either have the equivalent features, use lots of inline JS or ditch large parts of the ecosystem. While the latter would be possible if NewLangs standard library is big and good enough, I'm not feeling particularly optimistic about that.
Quite likely that C++ history will repeat itself: Just use the core language and a minimal library and do everything yourself (back then that was e.g. C++/Win32/ATL, not sure what it'll be for my future browser-based projects. Modula-3, I miss thee.).
I've gone through a similar experience with Rails 5.1 which has, having ditched jquery, gained support for webpack, babel, yarn, and vue.js (& react) instead; and thereby made writing JavaScript an order-of-magnitude less painful for me.
I feel that ES6 is a palace built on the ruins of a garbage dump and an odd stink still leaks through from time to time, but like the author, I can work with it now without loathing what I'm doing.
I primarily built frontend applications, so JavaScript is pretty much the only programming language I use on a daily basis. I'm not in love with it (although post-ES6 JS is quite pleasant to write), but I don't mind it as much anymore.
The reason? I feel like JavaScript is heading in the same direction as Java. The core language is highly flawed, which has resulted in the community developing build-time tooling and editor niceties to keep things sane.
In the future I expect to see more tools like Flow and Prettier, and existing tools and editors becoming smarter. I'm excited for improvements to JS as a language, but these days I'm more excited for new tooling.
This probably comes off as said from an ivory tower, but I don't think it's the people from other untyped languages who hate JavaScript nowdays. ES6+ looks pretty good compared to Python/Ruby/PHP perspective, and it works in the browser!
I don't hate javascript for its quirks or implementation details, I hate what it has done to the experience of browsing the web, and now what it is doing to desktop software.
Some of my hate has been lessened after looking at microsoft's own benchmarks. NodeJS performs much faster than ASP.NET 4.6 + IIS. Core improves on this, but the point is after all these years writing .net applications I knew they weren't native performance but they were good enough. I didn't know javascript was just as good or even better in some areas.
Now, implementing the entire browser rendering stack just so the dev can use css and html to develop the UI, that's a different issue, but not really a javascript issue.
ES6 is nice compared to PHP. It is not close to Python yet in terms of consistency and it-just-does-what-you-expect syntax. ES7 etc may get there but the standard library is also still lacking.
Also ES6 doesn't work in the browser (at least not reliably cross browser). We have to use it thought because it transpiles to something that works in the browser.
I think with another few years of the current progress javascript will be a good language - but there will still be a ton of old javascript to maintain which uses the principle-of-most-surprise syntax of older versions.
2011 called, they want their anti-Python nonsense back. Python 3 won. It's leaps and bounds ahead of 2.7 at this point and it's moving in a positive direction.
There are only two groups of people talking about this now, the poor folks who have to maintain and/or upgrade legacy software and you, people trying to stir things up.
Both these parties have existed in some form for absolutely every software upgrade ever so —as a community— we're past the point of caring. 6 years notice was more than generous and if they really want to drag it out longer, it's open source, but we'll be over here writing better, faster code.
Being fair, he is right. So grant him that. Python3 didn't really win. Lots of people jumped to TypeScript, Go and other stuff as a result. I wouldn't say you're writing better code, faster code either. Python2 supported unicode if that's the concern, and as of today the 2.7 interpreter is still faster than 3.6.
If you want to go on and use Python3, fine. But no need to lie about the facts on the transition and that Python3 is better. It's simply different, technical churn rather than innovation.
This is hilarious. How are you judging the quality or performance of my code again?
Being fair, you're wrong on all fronts.
Our code quality has increased dramatically if only by being able to replace swathes of thread and Twisted glue with asyncio. The very same upgrades saw a ×10 runtime speed-up in some claggy mixed-layer code.
But even just comparing runtimes, 3.6 isn't slow[1]. They're about the same.
If your only opinion of Python 3 is it does unicode and it's slow, you may want to read the first line of the comment you replied to. Your arguments may have applied to Python 3.3 but they hold little weight in 2017.
Unfortunately for you the facts aren't on your side. Python2.7 is still faster. People like you have said "your arguments hold little weight in 2013" too. Python3 was released in 2008, it's been 9 years and it's still a failure. The OP was correct and you were wrong. It's a shame that bothers you so much.
My experience is in predominately dynamically typed languages and I loathe JavaScript because of its implicit conversion of everything to strings, its substandard and clunky prototype object system, and that it's the only option that's cross browser compatible. For the record: I like Python, have no experience with Ruby, and dislike PHP.
Dart is surprisingly nice, considering how little I hear of it. I picked it up recently as a target for my hobby project (a Clojure interpreter). Dart's VS Code integration is phenomenal. Its VM is pretty efficient from a resource consumption perspective (especially compared to the JVM). It's worth a look, for anyone who hasn't bothered with it yet.
I really enjoyed the writing style of the article - "hottest shit on the street", "It’s just a yarn install away", "DHTML was totally rad, like how the Budweiser frogs were rad."...just brilliant! Also gave me a good nostalgic feeling about DHTML..
Lots of people relate ES2015 to giving us a better javascript, but the core language remains the same; the changes are just additions.
Building a tool chain can be an extreme pain in the ass because everyone is still experimenting, and trying to make the web better. Things like web workers, hot module reloading, and code splitting are relatively new, and don't have mature tools or patterns. Yes it's hard to learn, and yes it takes a lot of time, but once you learn a few tools you can keep using them over and over. I've been using gulp and browserify since 2011, and recently switched to gulp+webpack for code splitting, and HMR, and the switch couldn't have been easier.
I'am huge fan of JavaScript and personally don't like both Ruby and Python, but would never write an article titled: "Ruby/Python for People Who Hate Ruby/Python". I just don't use them. Writing such a article is IMO arrogant and bad for your karma. I understand some programmers are forced to use JS against their will (because there is not other person for the job), but if you hate JS and you're not forced to use it, please just don't use it and then you don't have to write such a negative and opinionated articles.
JS is more on par with Ruby & Python these days feature-wise, but I just don't see why one would prefer it. Ruby & Python are better thought out languages from the get go. Go listen to Brendan Eich discuss how he had to rush JS out the door as compromise between Sun & Netscape, and then how he couldn't fix the language warts even before ECMA.
> Writing such a article is IMO arrogant and bad for your karma.
Works wonders for your clickrate and Reddit-karma, though.
After all, we're all here discussing this, rather than some other substantive content with a more sober title. It's the way human behavior works, and the reward system produces content accordingly.
I also started learning JS in the DHTML era and wrote small games and toys for IE4. I did PHP stuff for almost 10 years and it was my main programming language. But at some point I stopped doing webdev, since the whole thing was a big mess and didn't seem to get better. I hated it. After a long break I decided to do another web project again and worked with Scala in the backend and Angular and ES6 in the frontend (about 2.5yrs ago). At first it seemed to be a lot better, but we ended up with another working but unmaintainable SPA. Adding new features required a lot of knowledge and was a pain. In this project I tried and failed to implement a solid Graph Library in JS. This motivated me to look at ScalaJS and write this library part of the app in Scala. It worked very well and I was amazed by the JS interop. From this point on I develop new web-apps with Scala in the full stack and am very happy with it. I suggest to try it yourself for the frontend, since it has a very similar syntax to JS.
The type safety avoids most runtime errors and therefore painful debugging time. Compile times became a lot better recently.
The real power comes when you share your data structures and algorithms with the backend, get a type safe REST API and macro-based high performance json/binary serialization.
I've been using Node 8 again after a few years of staunchly avoiding it, and the pain of selecting the right kind of libraries to use async/await sanely without having to massage promises (and .then()) is still there - in that sense, I feel very much like that cat with the strawberry beret on the article heading...
I'm not bringing in libraries. I'm trying to put together a set of libraries that work well with async for my purposes (custom net I/O, databases, etc.) without having to wrap them or fiddle with resolving promises on my own.
Sorry, not trying to be a d*ck here but I don't get the point.
You said you don't like the NodeJS eco system as you need to install thousands of packages to get your work done whereas on the other hand, your find CRA which uses tons of NodeJS packages to get the work done.
Secondly, code splitting, Babel, bundling has nothing to do with CRA, they are just standalone packages which works well together.
Third, "What’s more, updates are great. It’s just a yarn install away.", Isn't this something which NPM does as well?
Syntax - Again, nothing to do with ReactJS, it's babel which comes with polyfills.
So am just curious here to understand that how exactly CRA changed your mind where 90% of what you are doing is pure JS and has nothing to do with ReactJS?
Interesting, because Create React App is fairly new tool, however Ember CLI gives you the same thing for years now... so JavaScript World was always cool, at least for Ember.js developers. ;)
Ember CLI is a cool tool that preceded CRA, since it was inspired by Rails' CLI tooling. Unfortunately that's the only good thing about Ember, since it comes with the "batteries included" mindset making it one of the most bloated JS frameworks.
One thing I like about the more quirky languages like JavaScript and PHP, or even the far less quirky but still dangerous C language, is that they force you to write good tests. You don't get the false sense of confidence some other languages give you. I'm still not positive if static types are a poor man's test suite, or if a test suite is a poor man's static types, but I find tests are far more flexible and great at describing intent.
The latest js tooling is certainly light years ahead of where it was last decade, but it's a double edged sword, because now it takes a lot more effort to get something going.
Indie hackers like myself are still better served by vanilla rails + turbolinks, it gets you something that feels fast wtih a lot less effort.
Javascript is only going to get worse. Much worse. TC39 proposal "process" is driven by a never-ending self-congratulatory circle-jerk. Any concerns are dismissed with "people on TC39 discussed it, they know better, how dare you question their wisdom".
While there's still time, escape to TypeScript (though it will be flooded by crap from TC39 soon enough), ClojureScript, Kotlin, Scala.js, Elm, Purescript
I'm disagreeing with the tone, but there's a lot of truth to this unfortunately:
1. ECMA has set themselves up for yearly ECMAScript updates. How that's considered helpful (to browser adoption that is, rather than job safety) remains a mystery to me. Right now we're in the habit of using javascript-to-javascript (babel) translation even for the most trivial of things; for example, Bootstrap 4's complimentary (now compulsory?) JS source requires it. Basically, we're suffering the worst of JavaScript (for webpack etc. alone, because browsers won't handle ES6 imports), without being able to enjoy JavaScript's strength (being able to run directly in the browser with a simple page reload).
2. Most newer ECMAScript features are refinements over earlier ones (eg. async/await, Promises). There's of course nothing wrong with that. But many idioms of modern JavaScript can only be understood if seen in context, and in the discourse of earlier idioms they're replacing. But this kind of iterative improvement will get us into a foobar'd web stack and just sets the stage for the next generation of web developers to reinvent the wheel.
I'm also questioning the way so-called "web standards" come into existence. There's no real community drive behind it; the standard bodies of old, such as W3C, are struggling apparently and leaving a void behind, and it's just Google et. al. dictating things. As a result, your new shiny React app runs only on Chrome. Now if you just want a portable app framework, there are much better options available; there was no need to pollute the web with it.
Edit: typescript, or any other compile-to-javascript language, isn't the answer
I usually find myself somewhere on your side of the argument, but I don't get it.
Re: 1. Do you mean to say that browser adoption of new language features is slower now that the language spec is moving faster? If anything, ECMA is putting the pressure on browser vendors to release features faster. There's always going to be some kind of lag between the spec being out and browsers implementations. Doesn't mean the spec can't continue making forward progress.
Re: 2. This point is over my head I think. Can you elaborate?
Re: React. My shiny new React app works in whatever browser I build it for. You know that Facebook itself is built in React right? You don't have to use async/await, or Promises if you don't want to. And if you have to, that's what shims are for.
Re: Google dictating things. I can't say I know who employs the people sitting on ECMA meetings. Would it be such a bad thing if some of them worked for Google? I for one, would welcome our new Google overlords. You know .. the people sitting at these boards are people who have a vested interest in the future of JS. They have an incentive to keep pushing the envelope. It's just how things work. And it's good for us too.
Re: compile-tojs language not being the answer: What?? It sounds like your problem is precisely with JS! Both as a language and an organization. Why wouldn't the answer be some other language that relieves you of those worries?
What I meant is that a JavaScript release cadence shouldn't be set ahead of time, but rather adapted to the state of actual implementations in browsers.
> Re: 2
Try training a beginner on JavaScript. I have (kids on simple games), and the language and environment is so idiosyncratic already that piling new abstractions, OOP, syntax sugar and grand aspirations onto it isn't a net win for me. My bad experience with teaching JavaScript was because of strange/heisenbug-like rAF async races and general quirkiness I could figure out as someone with compiler development experience, but had a hard time explaining to novices.
> Re: Google dictating things
The problem with Google is the dominance of Chrome/WebKit browsers, or rather the out-of-control complexity of "web standards". Creating a browser from scratch is considered economically impossible at this stage. Given that a good part of our daily communication and information is on the web, at a certain point you need to weigh how complex you want the web stack to become, when the price to pay is a dependency on a single party or single piece of software. Note I'm not saying this is an evil plan or something, it's just how things are developing on the web. From that point, it's not far for the web to become AOL 2.
> Re: compile-tojs language
But I like the practical and unassuming side of JavaScript, and would rather see JavaScript being used and improved for things it was designed to do. Basically, manipulating DOM items with direct namespace bindings into the language in response to user activity. I also like JavaScript's ubiquity and portability (the "Script" in JavaScript).
I see, thanks for explaining. I totally get the frustration with the complexity of the web platform. I don't like running into heisenbugs either, and explaining rAFs to someone who is still trying to grasp the fundamentals of coding sounds like a special type of hell to me. That's why I don't use those APIs. They are there for experts who know they need them, and are best ignored by everyone else. It's with this mindset that I say, "let them build the runtime the web deserves". It will be complex, but not needlessly. The complexity will be inconvenient to many until we abstract it away, and we will. Lots of progress already in terms of libraries (React and others) and languages (CLJS comes to mind).
Building a browser should be hard. It's really an OS. You don't hear complaints that Linux or Mac provides too many types of system calls or low level features. Unless you're a subject matter expert, but if you're teaching kids how to code simple games, you start with Python or something, not C or machine code. It's needlessly complex to build something useful using those languages. So if your point is that it's becoming needlessly complex to use JS on the web platform (whether your beef is with the syntax, or the APIs of the platform), why not use a language that removes all that complexity? There are beautiful solutions to precisely these issues. Speaking for ClojureScript here .. (but of course many more langs compile to JS). Moving to this lang will remove OOP, all the es6/7 syntactic madness, and any and all issues related to object instance equality. There is no such concept of an instance of an object in that language due to it's immutable, persistent data structures. Add the ground breaking core.async into the mix, and you have relieved yourself of all heisenbugs related to async stuff. You don't have to worry about what a Promise is, etc .. it's nice.
I get your sentiments toward the practical, scripty side of JS. But I think it's reasonable to say, either practice restraint and _only_ use those good parts, or if that proves to be difficult, it's time to move on to a better, higher level, more safe and fool-proof language. And you can still interop if you want. Either way, core language and platform innovation must go on.
Don't worry, Web Assembly (or something similar) will soon be ubiquitous and having one, thoughtlessly tossed together, horribly "designed" language which constantly receives updates that are wholly ignored where it really counts will no longer be the reality of web targeted development. If there is one good thing about web dev today it's that adoption of new tech in the client space is really fast.
Of course, personally, I solve this problem by refusing any job that requires me to use JavaScript more than twice per complete solar eclipse. That's worked quite well now for over a decade.
> ...refusing any job that requires me to use JavaScript...
I'm getting jealous. Most job offers I see conflate software development with web development and even jobs earmarked “backend” come with JavaScript baggage.
Native mobile app development is the exception here if you can weed out the "we need an iOS developer with a strong understanding of Angular.js and HTML5" jobs or the React Native jobs that some consulting company talked a hiring manager into thinking they need.
I get to write our internal web apps in seaside (Smalltalk framework. It's awesome in ways most people can't even imagine) and let colleagues that actually like web development fix any serious UI issues.
I don't think so. To survive web development I have just accepted that I am standing on one toe on a ship of abstractions upon abstractions trying my best not to fall off.
What do you do? I was a Windows application and back-end developer for a long time, with only occasional forays into web. Took a job at a consultancy about 8 years ago, and it's been all web-dev ever since.
That's a more interesting question to me right now because I was actually wondering exactly what the answer was myself. I've been thinking of looking for a new job since my current employer grows ever more ... shall we say, unstable, over time. Really it's the market, and at least they are trying to adapt... But, anyway, I've been here a long time though, and it's mainly because I've had the pleasure of moving across many projects with enough variety and newness to keep me interested. Oh and they are extremely flexible with my work schedule and situation (WFH, set my timeframes 99% of the time.)
So I made a list. In 15 years as a working pro, across 3 corps, I've worked on 18 substantial projects.
There has been something of a theme with almost every project I've spent my time on. It's pretty generic sounding, but, data integration is probably the best term for it. The one project I spent the most time on and dug my hands into the deepest was a home grown message queue/pubsub middleware system, with some business specific semantics built in at the protocol level. I've worked on large scale vertical integrations for state compliance (basically, getting a bunch of data out of an extremely semantically burdened personnel db transformed and delivered to a state entity for compliance with reporting laws. Constantly, streaming style.) And also some cool small scale apps purely for doing research, which is where I fell in love with Spring Boot. I was so shocked at how fast we could have a serious Java app platform up and running with everything required for the whole stack using that tool, and that was like 4 years ago.
Anyway, all my projects kinda look like this. It's easy to call most of them ETL implementations, I guess, but they always have some particular complexity that keeps them from being solved with off-the-shelf tools, or at least, not completely solved.
The only time I have had to do web development in the last, say, 8 years, has been propping up dead simple UIs to some of the unfinished systems just to drive some user flows, UIs that are inevitably replaced by something "good" by someone else later, or a CLI even. And to be clear, I've got no qualms implementing services to be consumed by the front end. It's the forced dependency on tools I view as ill suited to reliable software production and collaboration (mainly JavaScript, in all its forms) that bug me. And while it's admirable that so many people keep trying to "solve" this, the real solution is for browsers to stop demanding we target JavaScript, and instead, target a language agnostic platform how we developers best see fit. Frankly, I think we'd be far better off if browsers exposed the friggin .NET CLR as their lingua franca. Could always use Mono or hell, Roslyn now, I guess. That's why I'm hopeful for WebAssembly.
You know, 48 hours ago I had never used Scala or Spark (directly) before, and now I've got a brand new 1.0 code-baby (Scala spark app running on AWS JavaScript, and instead, actually represent a real platform to be targeted EMR via Data Pipeline) transforming a few 100 gigs of internal analytics data dumped into S3 on a daily basis so it can be accessed efficiently with Athena for my tiny internal data analysis prototyping team. So it's certainly not about fear or inability of learning new tools.
It's just that at this point in my life and career, I have a much clearer understanding of the sort of languages, tools and libraries that make my job smoother, easier, and more successful. Things that reduce risk in the shipped products, improve the experience of working with others both new and experienced with the code base, and of course, things I personally like. To me, it's worth being adamant about not wasting my time with garbage, and sadly the entire web environment is built on a trash foundation. One that's bled into the server space, wasting a ton of time and power.
Luckily out of everything you can find jobs for, there are PLENTY of options that fit my criteria. It's not like strongly typed languages with good static analysis potential are rare. On the current TIOBE top 20, I'd take 7 or 8 without too much concern.
And some of the hot areas right now, the parts I'd be involved with, are implemented with good tools. Like Spark that I mentioned, heavily favored in "Data Engineering" tasks, is built with Scala, which is fine. More importantly, the true platform for it and nearly every single one of all the alternative tools in the space, is Hadoop, which is Java, which the place I have the most experience. So I think I'll probably be looking to expand my time in this part of the industry for my next job. Besides, it feels kinda cool to talk casually about how a terabyte of ram might not be enough for your next analysis task.
They had one job: Add type annotations. 99.99% of all issues I have with javascript would be solved with that, but I guess it just wasn't in the stars.
> While there's still time, escape to TypeScript (though it will be flooded by crap from TC39 soon enough), ClojureScript, Kotlin, Scala.js, Elm, Purescript
Nitpick: I'm guessing you mean 10,000% and English isn't your native language. In English the period "." is a decimal separator, not a thousands separator, so 10.000% means 10%.
EDIT: Holy cow, at least four downvotes so far. I hope the downvotes are for nitpicking and not out of disagreement. As cakemuncher seems to disagree (which doesn't mean they downvoted) this seems like a great learning opportunity about decimal separators and non-native speakers:
The parent is most likely German (the example code uses German so that usually means Germany, Austria or Switzerland) which uses the comma as decimal separator and period as thousands separator. I'm German too, so I'm sensitized to this mistake.
The US, the UK, New Zealand, Australia and English-speaking Canada all use the dot as decimal mark. South Africa is the only major English speaking country using a comma instead, but they use a space as thousands separator rather than a period.
The parent clearly intended "10.000%" to be read as "ten thousand percent" so that leaves the following list of countries which according to Wikipedia use a comma as thousands separator:
Argentina, Austria, Bosnia and Herzegovina, Brazil, Chile, Croatia, Denmark, Germany, Greece, Indonesia, Italy, Netherlands (currency), Portugal, Romania, Russia, Slovenia, Spain, Sweden (not recommended), Turkey
Exactly zero of these countries are predominantly English speaking. So in other words, in English 10.000% means ten percent (with a precision of three digits after the decimal point), not ten thousand percent.
Didn't downvote or anything, but come on .. we all know what he meant. This thread is not the place for a "a great learning opportunity about decimal separators and non-native speakers".
Why.. not? I mean, perhaps it adds too much noise to normal threads, but it feels to me you're explaining why we shouldn't be learning random facts here. Which is odd, because I appreciate learning, doubly so because I don't often seek it out.
Stopping someone mid conversation to correct grammar might be rude or whatever in person, mainly due to the "live" nature of in-person conversation. In a forum-like conversation however; it seems quite the opposite to me.
Well, not the OP, but for me, I clicked a link hoping to see some discussion about Javascript, and the first thread from the top is arguing about whether Number Separators of the World is a sensible topic of discussion. I mean, part of what I enjoy about HN is entertaining digression, but this may as well be an argument about varying aftermarket car part quality, as far as relevance is concerned.
And yes, I am adding to the noise; far too late now. How do you feel about car part quality?
I didn't know what he meant, and I am a dual national with a country that uses comma decimal delineation.
The problem is that an hour investment for a 10% increase in productivity would be a great thing. 10,000% is unvarnished hyperbole, so my brain interpreted as the reasonable statement.
Sure, eventually. But I had to parse that sentence three times to figure out whether he meant 10% or 10,000%. I'm a non-native speaker from Germany myself so I'm doubly careful about reading commas and periods in figures like that correctly. Adding extra decimals for emphasis isn't exactly uncommon.
I only expanded my comment because of the downvotes. I actually made sure to keep it short and explicitly mark it as "nitpicky" (i.e. unimportant to the greater discussion) exactly for the reason you state.
Having your mistake corrected can be educational even when you were understood. In the future, inanother context, the same mistake could result in confusion.
Well since we're all being pedantic, OP means "Original Poster" which is the person who started the thread (page, not this particular thread, which you did start).
I think that the meaning of OP depends on context. In general, you're correct. But cel1ne can be reasonably be referred to as the OP in our convo, since our discussion really doesn't have anything to do with the content submitted by the Original Poster of the whole page.
I'm always tempted to downvote people who edit their comments, complaining about downvotes or demanding explanations.
You'll see this behavior occasionally on any "gamified" discussion forum. But HN culture is the most extreme about this, you see it in every other thread.
* People downvote grammar-nitpicks, and "Actuallllly..."-style smarmy corrections that are more about making the speaker feel superior than genuinely helping the recipient.
* They downvote criticisms of programming languages that are currently popular here.
* They downvote libertarian political views in threads where the liberals are dominant, and then paradoxically they downvote liberal views in the next thread where the libertarians are dominating. Human nature just like a winner.
* They downvote low-quality additions such as, "This!".
* They will almost certainly downvote this comment, because it's negative in tone and speaks to HN culture, which generally doesn't go over well.
Gamification of conversation can be harmful to your mental well-being. None of these "imaginary Internet points" mean anything. Try not to troll. Otherwise, just speak your truth and take any downvotes like an adult.
The problem is downvotes mean different things to different people. IMO a point based system for comments particularly one with downvoting is a sort of an aggressive one that may steer certain folks away when really good community shouldn't. It might even create a bad culture and attract hyper aggressive and deter more passive folks. There are other gamification systems that don't allow downvotes (e.g. Quora) which I think are better.
When I have been downvoted in the past for opinion things I'm immediately concerned that I have offended someone. It actually is painful not to know... did I say something factually wrong... is my comment being misinterpreted... am I coming off as offensive?
I'm sorry I'm not an "adult" but I need explanation as to why a comment is incorrect or why you might disagree otherwise I'm not going to sugar coat... it doesn't feel good to be downvoted and I'm sure others feel the same.
> I'm always tempted to downvote people who edit their comments, complaining about downvotes or demanding explanations.
Normally that happens because complaining about downvotes is in the guidelines. "Please resist commenting about being downvoted. It never does any good, and it makes boring reading." Personally I don't feel the need to police it, but the guidelines are clear.
> * They will almost certainly downvote this comment
Also in the guidelines: "Please don't bait other users by inviting them to downvote you or proclaim that you expect to get downvoted." You may get downvoted for ignoring the guidelines, rather than because of the negativity or speaking to culture.
> Gamification of conversation can be harmful to your mental well-being.
This is an interesting thought! I'd tend to agree, though I just stared to wonder if getting myself into arguments on Internet forums are the primary factor, and the gamification is secondary. Either way, my first thought is why participate in the gaming part if it's bad? I've never downvoted on HN yet, in part because getting downvotes makes me feel bad, so I don't like to inflict that on others. In part because they're unnecessary, I can upvote the things I like to make them bubble up, and I can use the [-] button to ignore threads I don't like. Anyway, "try not to troll" I agree with wholeheartedly, that's the main thing I learned during the period that I didn't have downvote privilege, and I imagine that was the intent.
That's why I made sure not to complain. I wasn't particularly angry, mostly just wondering what motivated people to downvote and expanding on my original comment based on the assumption that people actually disagreed or weren't aware of how decimal points work in different languages.
This issue can be avoided by following the ISO standards ISO-31 and ISO-80000-1. Under these grouping is done by separating groups by a small space (U+2009, THIN SPACE, is usually used, I believe). If there is a period or comma in the number, it is then unambiguously the decimal separator.
We should even already be used to that style, because those are the standards that cover how SI units are supposed to be written.
So just write it as 10 000% and everyone should be happy.
You'll love Apple's smart new "Touch Space Bar", which lets you continuously adjust the width, style and semantics of Unicode spaces from zero width, hair thin, various EM&ENs, to obesely fat, pregnant pause, breaking, non-breaking, numeric, oghamic, figure, ideographic, word, punctuation, visible, ␠ symbols, mathematical, poetic, scientific, pseudo-scientific, streaming, auto-repeat, lossless and lossy compression, deep, personal, safe, digital rights management, Mongolian vowel separators [1], etc, simply by swiping, tapping, crossing and snapping your fingers, while watching the mesmerizing colorful blinking graphical feedback provided by applications supporting the NSTouchSpaceBar API.
Microsoft also has a dog in the space race: see their "Space Characters Design Standards". [2]
OK, some do in this table, but I'm not sure how accurate it is.
It lists my country as one of those countries, and we definitely don't use space as thousands separator (we use period).
Perhaps what the table shows is just that this is the "SI style", and assumes that countries whose scientists and units follow the SI also follow this way of thousands separators, but we don't. We just use the SI units -- and even our scientists use period for the separator.
When I read 10.000%, I though he was being reasonably realistic about the magnitude of his increase in productivity (a 10% increase is great, nothing to scoff at), but wildly exaggerating about the precision by which he measured his productivity, to three significant figures!
But if you're German, isn't that the kind of hyperbole you most appreciate, since you love making precise measurements, no matter their magnitude? ;)
> Exactly zero of these countries are predominantly English speaking. So in other words, in English 10.000% means ten percent (with a precision of three digits after the decimal point), not ten thousand percent.
I posed a question about this a week or so ago,and got some interesting responses.[1] This one might be illuminating:
In mainland Europe we only use the metric system, even when speaking or writing English.
Also it is common to stick to the comma as decimal separator and dot as thousands separator when writing English. This convention is independent of the language used.
Same goes for date notation, dd-mm-yyyy is used (almost) always.
In Windows or Linux for example you can select the English language with Dutch localisation. It's used by almost all software developers I know.
So the answer is that countries that use a period as a thousands separator may by convention happen to continue doing so when using English. Whether you think this is appropriate is likely tied to whether you think localization applies irrespective to language or not.
I think you misread the thread you're responding to.
The OP used a comma as decimal point, not to as a thousands separator. GP likely meant they know of no English speaking country that uses the comma as decimal point. Your example doesn't contradict or add to that.
Curious, do you read your post back to yourself after posting, and think "hmm that might make me come across as overly sarcastic and mean rather than simply conveying I don't see the point of what he went to all this effort for" or do you just not care about that kind of thing?
I agree with this. When the library docs and examples are in the native language (ES*) it's easier for developers unfamiliar with the code base to get on board.
We've switched to Typescript for our React projects because we've found it's the sweet spot between developer perks (type checking, static analysis, intellisense, inline lint errors) and abstraction of the actual code running in production. It's also a lot less of a readjustment to make if you need to dive into the transpiled source to track down a subtle or unusual bug.
I have extensive experience in ES6/React for the browser and Java/Kotlin for Server-, Desktop- and Mobile-Apps.
A week ago I switched a fairly new project from the usual setup (react/babel/webpack) to Kotlin-code only. My IDE compiles the Kotlin to JS now and webpack serves it as usual.
Writing the react-bindings took me an hour, after that my productivity went up by about 10.000%. It's finally on par with my productivity on server and desktop. No type errors, fast refactoring, no "undefined" errors and all the goodies (extensions) of Kotlin.
Removing the complex eslint settings and babel-setup from webpack and package.json felt triumphant.
My JSX looks like this now and is completely typesafe:
I even get compiler-errors when I nest HTML-tags the wrong way (h1 inside h1) or so.I couldn't be happier. I'll never touch plain ES6 again.