Deprecated Ufront replaced with Tinkerbell HTTP

[Gama11]

I wonder if ufront should just be removed from the list entirely. Also, we should remember to add @haxiomic's dts2hx once it's ready. :)

[tynrare]

@Gama11 this is probably should stay for case someone will fix it. Not hard work comparing with library size itself, i guess. Hm, maybe we should add https://haxetink.github.io/tink_web/#/ in list?

[ibilon]

Thanks for the contribution, but I also think ufront should be removed, between requiring this warning and the several years old last commit, I don't think we should be recommending ufront anymore.

tink_web could be an alternative maybe, I'm not familiar with web libs. @back2dos @kevinresol what would you recommend?

[tynrare]

@ibilon @Gama11 well from perspective of "it just doesn't work" you both right. But there's great idea behind this lib and i hope someone will update it some day. Maybe there's list kinda "good but abandoned"? @ibilon tink_web small library, and works only with js and php targets, but only one i found.

@ncannasse what stack do you use for hosting CastleDB? I see hxnodejs in libs, does it mean you just host page from js.node.Http?

...

Well, actually, what stack haxe.org uses to host dev server? And also why hx3compat in libs of client.hxml? It's weird that site of language, written on that language, uses code, that removed from language.

[ibilon]

The haxe.org stack is described in the readme, it's a custom generator producing a static website, which is then deployed to aws, but we've done the same with github pages. There's no dynamic content so there's no need for a web library.

There's nothing wrong with using hx3compat, it's simply a library containing features that weren't considered to be relevant enough for the standard library, it's not removed from the language, just made into a library instead.

For CastleDB you are looking at the software dependencies, the website seems to be simply a static website stored in the www folder of the repository.

[tynrare]

@ibilon are you developer of haxe? Now i'm trying to create "best-practices" template for haxe and it's really important for me to understand this practices first. I understand deprecate word not only as "old" but also as "disapproved". So when i see "deprecated" somewhere in manual i think that i shouldn't use it. But if developer says that's ok - well, ok.

CastleDB is tool for editing files so it can't be just static site. Again, i assume it just uses hxnodejs. And here i have same issue - i don't like that i can't start server from neko (Aka -x Main in build.hxml) app, but if it ok for "haxe creator" - well, ok.

[kevinresol]

Remoting (+ a few other things) is removed from the std library, and becomes a standalone library (hx3compat). I don't think it is considered "deprecated", it is just a library now.

[tynrare]

@kevinresol i read "Deprecated: The remoting API has been removed from the standard library in Haxe 4. For compatibility purposes it is still available in the hx3compat library. " as "Do not use it in 4+. It saved in hx3compat in case you need it in old projects"

... Maaaaybe this question deserves some discussion in issues?

[kevinresol]

For new projects yeah you probably shouldn't use hx3compat. Not because they don't work. But because there are better choices out there.

Regarding this PR, I prefer removing Ufront altogether. My ufront tutorial has the same warning.

[tynrare]

Considering all your response i replaced ufront with Tinkerbell HTTP

[tynrare]

Well... Actually, i can't recommend any of tink libs. It's incredible bad documented, uses lots of inner deps which also undocumented. So for tink_web whole work is just running around between tink_core, tink_http, tink_io, tink_core, tink_web, tink_anything github repos. It takes lot of time to just understand what type function from basic example returns. It's waaay to bad experience for front-page sharing.

Well, after all day wasted for experiments, i can't tell that there's any alternative for ufront on haxe. But still, because Tinkerbell already exampled on haxe.org - it not for me to decide.

[kevinresol]

tink_web has documentation: https://haxetink.github.io/tink_web/#/getting-started/quick-start

[gene-pavlovsky]

@tynrare Myself I love tink libs. Once you get to know how to use them, they are fabulous. Having said that, when writing a project with tink_web, to get things working in the end, I've had to experiment, guess, pester Juraj and Kevin with endless questions etc. The first frustration I had was to just get a set up of library versions that makes an example project to compile. I think lix changed this behaviour but back in the day, when you install a library with lix, it adds also it's dependencies (and their versions). Then if you add a different library that has the same dependencies (but different versions), the version used will get changed. So, depending on the order you add all the required libraries to your project, you will end up with a different set of versions. That led to various compile error as the libraries APIs keep changing. But still I can recommend tink wholeheartedly, it's the best there is for Haxe in my opinion. Hopefully the community around tink becomes bigger, and people start pushing for (or contributing) more stability in APIs and betters docs / API references. Some tink libs are fairly well documented in "README" style, some of them even have a pretty good documentation websites (on github.io), but I do miss sometimes the luxury I've had when using FlashDevelop with AS3 - just activate code completion on some property or function, and you will see a description of what is it, the meaning of the function params, etc. Or press F1 and read the full reference for the particular thing (I used OpenTheDoc plug-in for this - well I still have this installed and working, just these days I do only a tiny bit of AS3).

[tynrare]

@kevinresol sure i've seen this docs. Basic example (and other examples) doesn't provide enough info. What methods has router for example? All fields generated by macros, it very hard to trace. No code documented. For library this size this frustrating a lot. Anyways. I has nothing to present except negative feedback, we can discuss it in another thread. If people love to use it, why not to present it.

[gene-pavlovsky]

@tynrare You're right, I wish macro-generated code would also contain macro-generated API docs :)