"haxe.remoting" versus "tink_"

1

i have heard about the change witch will happen in haxe 4 : “tink_” versus “haxe.remoting” but haven’t try it yet

this change would be against Haxe’ principle : KISS ( Keep It Simple Stupid )

“haxe.remoting” is intuitiv, easy to understand and to deploy

“tink_” everything isn’t

please, don’t let me learn a new API that already exists and works fine !

thank you,
michel

2

Well, first of all tink_web is not in any way the replacement for haxe.remoting. There are a number of reasons why haxe.remoting got moved out of the std lib:

  1. it’s not cross platform (e.g. no support for nodejs) and nobody seems to care enough to change that, so also it can’t be that popular - seems that for example nobody on the compiler team is seriously using it anymore
  2. it’s reflection based, which makes it slow, somewhat unreliable, potentially unsafe and unsuitable for minification
  3. it uses a non-standard protocol that is not particularly space efficient.

With practically no changes over the past 10 years (versus the underling haxe serialization which gets improved/adapted quite regularly and therefore is in the std library) I think there’s no reason to panic about haxe remoting now being in a library.

If haxe remoting works fine for you, you can continue using it. Other people have other constraints and everybody should use what’s best for them :wink:

3 Likes
3

hi Juraj,

a few days ago in Versailles, a scientific team deeply changed the ‘kilogram’ and the ‘ampere’
but they kept the names ‘kilogramm’ and ‘ampere’ ( the API ),
so poeple who use it don’t care;

a more than 10 years old standard part of Haxe is here simply ejected
( without replacement ?! : “tink_web isn’t a replacement” );
the end-user is wasted …

is ‘haxe.remoting’ using wrong concepts in its API ?

anyway, thank you having friendly explained your point of view

michel

4

The tink stuff is great, I’m only starting to scratch the surface but whilst there is a learning curve to some of it (some is beautifully simple to use and the more complicating things have that same air of simplicity but the lack of docs can trip you up a bit).

Any comparison between tink_web and remoting is a false comparison. I first used remoting with AS2 and flash, finding it in haxe was awesome and I used neko backends with flash and JS frontends on some stuff. Tink_web is not like for like at all, it can do what I used to use remoting for I guess, but it’s not the same concept of calling functions remotely, it’s handling requests and giving responses. Tink_web also does what the haxe.dispatch classes did in a much nicer way (to me) and like I say I’ve just scratched the surface with it.

I don’t think the tink world is pushing anything out, I don’t think it’s doing anything other than be incredibly useful if you want to start using it. It’s existence is only a good thing and it’s not doing any harm to anything else. I don’t understand why it should be treated as antagonising, it’s a tool, it’s different from the other tools being mentioned. I don’t get angry with my new socket set because I have some spanners that worked fine as well.

I’ve not used haxe 4, but if I did and I wanted to use remoting I could by just importing the classes from a different package. What’s the big deal?

5

Let’s not be dramatic. The code is now in a library that can be installed with one single command.

Yes and no. While it is pretty simple, it also has a whole range of issues (some of which I’ve mentioned) and the question whether it should be in the stdlib and thus the suggested way of communication between various parts of a Haxe app is a fair to ask.

Depending on the use case hxBit and tink_web each have their advantages. If you don’t need those, then you may well be better off by sticking to what you have.