raquo

TBH, You don't use scala.js to write hello world apps. I'm much more curious how Scala.js handles a 100Kloc app, but I haven't seen any data on that.

So wait, that means USSR had no coin valued at less than today's $1.5 by purchasing power (assuming the 1/2 kopek coin existed at the time)? Interesting.

I feel that car license plates are a reasonable compromise.

A car provides you with an ability to inflict a lot of damage AND with an ability to escape from the scene quickly. Think hit and runs, road rage, dangerous driving, drunk driving, driving without license, etc.

I'll definitely take lack of anonymity when driving over having to deal with the millions of unaccountable assholes.

Indeed, I don't have a good understanding of the JVM ecosystem. However:

Google is tentatively on the hook for $9B for... essentially implementing its own JVM... or something. Doesn't matter to me, end result is that the future of Java on Android is far from clear. They're allegedly looking into using Swift as the next generation Android language.

RoboVM, one of the better / more popular ways to write iOS apps in Java was close-sourced, then acquired by Xamarin, then Microsoft, then shut down.

Oracle charges licensing fees for using JVM in embedded devices and kiosks.

To summarize, there's an incredible amount of tools and libraries for Java, but I don't like where Java's mobile story is going in general.

As far as I know the number of viable JVM machines you could build a business on is maybe... 5 at most? They're all experimental and/or abandoned.

Meanwhile, node / JS / ASM.js / Emscripten and friends are only getting better, faster and more widespread outside of the web.

Either of those technologies is good enough technically for my purposes.

However, I have much more confidence in node's new governance (and therefore its bright future) than in Oracle. Oracle essentially has a monopoly on Java. And they're not nice guys. I don't feel comfortable building a cross platform application on Java no matter how much momentum it has gained historically.

The reason I'm going with Scala.JS is to have UI code shared by web, mobile and desktop platforms. ScalaFX needs JVM for UI code, so it can only run on desktop and possibly Android.

Building cross-platform apps with the same codebase is gonna be ugly one way or another. This particular method is interesting to me personally because I'd rather depend on node.js than Oracle's JVM.

It's worth mentioning that Scala might get a native backend soon, partly built on the same infrastructure as Scala.js – that could give you a migration path from node.js/Electron to a truly native app with a simple WebView for UI. See https://www.reddit.com/r/scala/comments/4ftcx4/scala_native_...

I like the storm of Scala.js comments on the article. It's definitely game-changing for the Scala ecosystem. You can run Scala on node.js now, and by extension you can package desktop apps written 100% in Scala.js using Electron.

I'm just starting to fiddle with it, but Scala.js on both the backend and frontend seems like a great combination – lets you use the same language and packages throughout your application, and frees you from the JVM.

People are always gonna be getting video content from somewhere, and they're not gonna be paying for it enough to make it ad-free, so they're gonna see ads regardless of the medium.

The problem seems to be that a slightly indirect variation of bribery (aka lobbying) has been legalized in the first place, not that such bribery is hard to detect.

If there was any political will to solve this problem, it would have been solved long ago.

Criminals will always have encryption, regardless of any laws, so your dichotomy isn't really correct.

For particularly bad problems, after exhausting standard methods, I start writing a stackoverflow question or a help request to someone on my team. I barely ever have to send it, this just forces me to spell out an exhaustive list of things that I've tried (or forgot to try). Eventually I figure out what I've missed, and if not, I have a help request all ready to go!

Good.

> A lot of times, lawyers will send out letters without caring how the recipient responds -- they only need to have sent the letter at all to have covered their bases.

That is not what happened here though.

Looks like a good punch right into one of Facebook flow's advantages. Very glad to see both static typing alternatives for JS evolving.

> how many layers of abstractions built on top of other (redundant) layers of abstraction really make sense?

As many as needed. This is a political problem, not a technical one.

OSs don't want to provide one common framework for writing and distributing sandboxed one-click-install write-once-run-anywhere applications. So browsers are solving this problem on their own.

Maybe you don't care about this, but users, developers who need to write universal apps, and their marketing managers definitely do.

This exists for a reason. If you do this in HTML:

    <li>Hello</li>
    <li>World</li>
    <li>!!!</li>

You now have text nodes containing a space in between the <li> elements. These will subtly affect how the elements are rendered. In HTML, if you want to get rid of those text nodes, you have to write the elements on one line:

    <li>Hello</li><li>World</li><li>!!!</li>

Or use float: left|right styles to push the text nodes out of the way. Both are ugly solutions. With JSX, I don't have to think about that.

I've never even ran into your issue because I use React for web app development and so use translation strings (i.e. function calls) for pretty much all user-visible text. If you ask me, the trade-off React chooses here is adequate.

If the array does not change over time, using array indices is perfectly fine. You can use anything as a key as long as you guarantee that it stays the same for that specific element. If you don't change or reorder the array, the element's index does give such a guarantee.

> So lets avoid bringing up someone's race when trying to explain their behavior and/or intentions

Normal people already do that most of the time, because most of the time race, ethnicity, or culture does not matter for whatever you're talking about.

However, a blanket statement that such things never explain anything is false. A person's upbringing and environment influences them tremendously, and it does correlate with ethnicity, nationality, country of origin, socioeconomic status, and many other variables.

For example, an average russian doesn't like gays. That's a fact. There are cultural reasons for that, it's not just something that happened randomly. If I want to explain to someone why my russian friend doesn't like gays, I will tell them that it's because he's from Russia, where it's normal.

Here, I've used ethnicity to explain someone's actions. In America this would cause hysteria, and I would be branded a racist, because in America every statement that involves race is racism thanks to the argument you're promoting.

However, there is no racism in my statement. It's factually correct – if my russian friend was raised in Canada, he probably would have internalized the normalcy of varying sexual preferences long ago. But he was brought up in Russia, where casual racism, sexism, and other assorted intolerance is the norm. My statement is also not judgmental. I'm just explaining the probable reason for a person's behaviour using information available to me.

But again, for the sole reason that it involves ethnicity, in America this valid statement is widely considered racism. Not to mention that if my statement was similarly correct, but involved blacks or mexicans or whatever other ethinicites are conversationally popular in America, I would be in even bigger trouble for no reason other than the reader / listener's prior experiences with racial issues, which are, I might add, dependent on the reader / listener's race, ethnicity, and country of origin (and here we go again...).

Your argument, the way I see it: "People say lies about race[0]. So let's not talk about race anymore". This is, appallingly, the current state of the art of racial discussions in the west.

Try to apply that logic to any other subject however, and the insanity will reveal itself.

"People say lies about used cars. So let's not talk about used cars anymore"

"People say lies about the mistakes of The One Party. So let's not talk about the mistakes of The One Party anymore"

There is no excuse for suppressing legitimate, non-racist speech on racial issues. Also, that kind of speech exists, and if you haven't heard it, that's because decent people around you are scared shitless of being labelled a racist for bringing up race, however innocuously. And actual racists don't care. Which exactly the scenario that your argument is designed to enable.

[0] every racist statement is by definition a lie. That's very important.

No thanks.

I'll talk about race the same way I talk about eye color.

I'll talk about culture the same way I talk about TV preferences.

Without hysteria.

Fuck racists.

Fuck spineless "don't you dare mention race" bullshit.

Both are equally cowardly.

Doesn't matter, the principle is the same.

You could just as well say that the cent that buys you a soda has a bigger marginal utility than the previous one. Sure, maybe in the context of that one transaction, but not in any general way.

Looking at job postings, angular does seem to br dominant, unfortunately.

I don't get the point of this article.

It posits the usage of small independent tools as a problem, and then provides solutions to the problem that are not much more than prepackaged combinations of these tools and therefore were made possible entirely by these tools being small and independent. But these tools are apparently also bad because you need to think to use them, and write config files to tell them what you want from them.

This doesn't make any sense. The ecosystem is working as it's supposed to be working.

Am I missing something here?

PS: Not sure why you would pick on React for tooling complexity. You can use it with one <script> tag and no JSX, just like angular or jquery or whatnot. If you also want to use ES6, JSX syntax, have your code linted, hot module reloaded, uglified, your sprites auto-generated, and all your assets packaged for efficient distribution that's not react, that's a lot of independent feature requests that require astonishingly minimal boilerplate to get running considering the value you're getting. All of that is completely optional too. If you look at how typical real-world react and angular projects look, they would be very similar in terms of build tools used.

So, once again, JSX is JS. You're free to write the exact same thing without XML syntax. If you don't like that either, then what you're really saying is "Don't generate HTML using JS". Why not? The benefits are obvious:

* With React & ESLint you get basic checks to make sure you're not passing non-existent variables

* Your IDE understands what you're doing and lets you jump to callback definitions

* You understand what you're doing because you have one obvious place where you do templating and data binding.

* Your actual behaviour logic is still separated from your template, living in some other JS file.

On the other hand, if you add event listeners to HTML from JS the classic way, you get other problems:

* You're querying the DOM tree by CSS classes or some custom attributes. It's surely a familiar way of doing things, but also fragile and unintuitive.

* It requires your JS to know the structure of your DOM to some extent, and that structure is defined elsewhere. So it's basically the same problem as with mustache templates – passing around magic strings – but the other way around.

* Neither ESLint nor IDE will help you do it.

> Putting behaviour in HTML is a bad idea

This is not what I'm doing. JSX is JS. I'm not putting any logic "in HTML". If I were able to express what I'm doing in mustache-style syntax, it would be:

    Blah blah <a onclick="{{ callback }}">Click me</a> Blah

Where `callback` is a reference to a JS function (rather than a string holding it's name).

What's your ideal way of registering an onclick callback?

JSX/createElement is not just syntax sugar though. It avoids the whole step of parsing the template. Because JSX is JS code, you can pass native JS values to it including callbacks. Whereas anything you could pass to mustache-style templates will be stringified.

So for example in case of parsed templates, to pass a callback to onClick you'd need to define a convention on how you're going to locate the callback by a given string (since you can't pass the function itself, you need to pass some "name" of that function). Whatever logic that will be, the result will not feel like React anymore because you're back to typical framework-specific template magic instead of using plain JS.

Your end product has both HTML and JS so there's no way around mixing them somehow at some point. You could do it by keeping them separate and linking between them by means of CSS classes and magic strings in HTML templates. Or you can generate the HTML using JS functions. JSX just gives that latter option a pretty syntax.

If you don't like mixing logic into HTML you're free to create dumb components that only contain as much logic as you would want to put in a template. Such a component would accept properties and output a representation of the resulting HTML. A smarter component that does not generate HTML will provide the logic required for the template to function. That approach actually encouraged and is the right way to do React.

The bonus of this whole generate-HTML-representation-with-functions thing is that you pass around native JS values instead of stringified values and magic strings. Want to provide an onClick callback? Pass a callback. Not some magic string that represents a key which holds the callback in some object defined by framework-specific convention. No, you just pass a raw javascript function that will be run on click.

This might seem like a trivial distinction, but it's the difference between writing native JS vs writing magic framework code. I vastly prefer the former.

I don't know whether TPP has such provisions, or if it's even common for such provisions to exist.

I sure hope the TPP isn't as bad as it seems.