Haxe remoting, SPOD, dispatch, ..., moved to hx3compat

1

Hej all,

With haxe 4, many of useful classes are moved to hx3compat lib.
I especially loved haxe for its simple use of things like SPOD, web.Dispatch and haxe.remoting that where well documented.
Now with the move to hx3compat I’m a bit confused because several people ask for their replacement and some people tell some libs that are not well documented, neither have basic examples, like tink_sql for SPOD, tink_web for routing, hxBit for remoting… The annoying thing with tink_sql and tink_web for example is that it’s all tink_core based, so where before I used just a simple package like haxe.web.Dispatch which is simple and understandable by every one, now I have to include massive lib well written (it’s not the question) but more difficult to understand and not very well documented.
I think it would be good thing to explicitly tell what would be their replacement and give a basic documentation where people can easily convert their existing code to the new one.

2

Why not to continue use those classes via hx3compat library?

3

Hej Michael,

Thanks for your reply.
Yes I continue using these classes via hx3compat for now but just now they are not maintained and I fear for the future it will be worst I think.

I also want to say that in the past I wrote many things about haxe and especially SPOD, Dispatch and remoting that was a great combo for websites building, it was really something interesting in using haxe and now, it all goes scattered, that’s pitty.

4

Cool!
About SPOD AFAIK it’s deprecated in favor to record-macros which have 0 run time overhead if I remember it right.

Also, if you are already use those libs and writing about them, why you not be the maintener?

5

Thanks Michael, you’re right about record-macros I already use it, forgot about that.
I have no more time to contribute and I think I’m not good enough :confused:

6

As I’ve explained elsewhere there’s nothing wrong with just using the stuff from hx3compat if that suits your needs. But: all those solutions have serious limitations and you can’t lift those without compromising on simplicity.

So I guess the remaining question is whether or not this “stack” should stay in the standard lib.

My impression is that nobody on the compiler team likes it or uses it, which seems enough of a reason to move it out. Additionally, it’s doubtful that today it should be the suggested solution for people who come to Haxe (when these solutions were new they were absolutely amazing, but things evolve while no part of this stack caught up). Dispatch’s inability to route based on verb pretty much promotes unrestful RPC-ish interfaces, haxe.remoting is a custom protocol that is not exactly easy to interface with from other languages and as for SPOD it is pretty much ok, but it doesn’t work on node, and is overall quite limited.

That is not to say that this you shouldn’t be using this stack if it serves you well :wink: