On Tuesday, 25 March 2014 at 10:28:51 UTC, Nick Sabalausky wrote:
On 3/24/2014 6:49 PM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
On Monday, 24 March 2014 at 22:23:50 UTC, Nick Sabalausky
wrote:
Using the same language on client/server is indeed quite
nice, partly
because of less mental context-switching, and also because of
increased code sharing (which also makes it easier to move
things
between client vs server if you need to).
Yes, especially for data models. It is always annoying to
modify several
different layers just to add some fields to a database entry.
Not a big
deal, but so… pointless.
Yea, common data models was a very big use of shared
server/client code for me, too.
using Haxe pretty heavily for a good while. Haxe is a rather
"ok"
language, which is practically high praise coming from me -
I'm
typically very critical of languages.
I've looked at Haxe from time to time, and I like the
approach, but it
has never been sufficient to solve any issues in any real code
I've
worked on.
For me, the killer features were:
- As mentioned already, shared server/client code.
- Being able to run code on any commodity PHP servers I was
required to support, without having to actually *write* any PHP.
- (Note this was several years ago:) Being able to generate
Flash applets without having to actually use any of Adobe's
horrible toolchain.
- The language itself *didn't* totally piss me off. ;)
So yea, the Haxe language itself wasn't really a key thing for
me, just what it allowed me to *avoid* doing. But even those
reasons are loosing their bite for me now, since Flash has
pretty much become legacy, vibe.d has appeared, and I'd just as
soon avoid the entire PHP runtime as a whole.
Yeah, that's where I am at now too. So currently I deal with
Python,
Dart (working hard to get rid of Javascript) and C++ (and
dabble with
XSLT, Java and Objective-C). But I'd rather use something more
clean and
strongly typed like Go and D, but with Pythonesque terseness
and
functional style list processing hight level cleaness.
Unfortunately
both D and Go lack production level support. And even with
production
level support they still lack production quality libraries for
excel
handling, pdf generation etc.
Heh, I guess that's where we differ ;) I'm...not exactly a big
Python fan, and I find D totally production-ready. I generally
avoid client-side JS - when I do use it, it's just a
sprinkling. If I need to do anything else Flash-like in the
future, I'm looking more at Unity3D (esp. the v5 on the horizon
with asm.js support) rather than doing HTML5 directly or via
things like Dart or CoffeScript.
In semi related news, have you guys seen Cmsed? Built into the
data model registration is generation of javascript models which
tie into the restful routing to give you (if I finished it) the
same level of interaction with the database as you would in D.
And yes you're in control of the security of each data model for
each operation type.
I just think thats a neat little feature.
