# "haxe.remoting" versus "tink\_"

**URL:** <https://community.haxe.org/t/haxe-remoting-versus-tink/1290>\
**Category:** Haxe\
**Created:** [November 20, 2018, 1:55pm UTC](https://community.haxe.org/t/haxe-remoting-versus-tink/1290 "2018-11-20T13:55:59Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![back2dos](https://community.haxe.org/user_avatar/community.haxe.org/back2dos/32/30_2.png) [@back2dos](https://community.haxe.org/u/back2dos)\
**Post date:** [November 22, 2018, 11:04am UTC](https://community.haxe.org/t/haxe-remoting-versus-tink/1290/2 "2018-11-22T11:04:23Z")

</div>

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 😉

---

_[View the full topic](https://community.haxe.org/t/haxe-remoting-versus-tink/1290)._