The benchmark might seem like apples-to-oranges, but they both do templating & routing, which is what is being tested.
I also address this on the benchmark page:
Why compare a language to a framework?
1) THT takes a “batteries included” approach by providing essential web framework features.
2) Some might be worried that running a transpiled language would be too slow to run in production, and Laravel is arguably the best example of a production-ready PHP framework.
Also, yes it is essentially a new language. I don't expect anyone to rewrite large PHP applications in it, but people might consider it for new projects.
Strangely enough, many countries also have cultural laws around what languages can be used for subtitles and audio tracks. For example, IIRC there is a country in SA that doesn't allow non-Spanish subtitles if the primary audio is in Spanish.
There are all kinds of permutations like that which can look like arbitrarily bad UI decisions if you don't know the greater context.
I can understand that it might not seem useful to you if you already have a stack you've invested in, or it just doesn't fit the kind of projects you are working on.
But I just wanted to respond to a few things. :)
> A) Come from a javascript background
It targets all web developers, who are all generally familiar with JavaScript. It aims to be another tool, not a total replacement for all projects.
> B) Want to deploy on cheap hosters where node isn't available?
Shared hosting is still a very popular way to run websites. And node is often overkill for basic CRUD sites.
> C) Don't care about performance
There is a big difference between not needing to support 100+ requests per second and "not caring". :) Out of the box, PHP is fast enough for a lot of apps, and the overhead of THT is not enough to be noticeable at that scale.
> don't mind the additional complexity of the transpiler
There are no build steps, so the extra complexity just involves running the initial setup script. After that, you drop in new files and update them like you would with PHP. Ideally, it won't feel more complex than any other framework.
> Can this even leverage the enormous PHP ecosystem?
This is on the roadmap. Though there are still plenty of projects that don't use 3rd party libraries and could be built with THT as it is today.
I personally have never needed to use composer, etc. in my projects, but it's still something I am looking to support.
It's not just marketing fluff. It really does a good job of reflecting what it's like to work there, and is taken seriously by everyone from the top down.
As I mentioned elsewhere in this thread, it's not a competitive environment, and I've experience very little politics and drama. Those things are explicitly counter to the culture.
As for long hours, while the work day can be pretty intense, the office is usually empty by 5-6pm.
As a Netflix employee, I wouldn't really describe our culture as cutthroat at all. My experience in 5 years has almost entirely devoid of politics.
For example, from our culture page:
"We have no bell curves or rankings or quotas such as “cut the bottom 10% every year.” That would be detrimental to fostering collaboration, and is a simplistic, rules-based approach we would never support."
Our culture can feel intimidating, especially if you have any degree of imposter syndrome, but with very few exceptions, my colleagues and managers have always been supportive and really great to work with.
Netflix employee here. We have a high performance culture, certainly, but it's not the singular focus. I have probably seen just as many people let go for their inability to work well with others as anything performance-related.
From our culture page:
"...there are no “brilliant jerks.” The cost to teamwork is just too high. Our view is that brilliant people are also capable of decent human interactions, and we insist upon that."
This is why I introduced LockStrings as a key feature of THT (a language that compiles to PHP). It takes the opposite approach to Perl's taint mode. You mark string literals as safe -- everything else is untrusted.
Functions that do risky things (Database, System calls, etc.) only accept LockStrings and are responsible for escaping, so all you have to do is provide the placeholders.
Most of the principles are always in tension to some degree, and come down to a design decision. In this case, the shorter, clearer term won out. The two terms are practically synonymous, so if you know what a "boolean" is, you probably know what a "flag" is.
In actual use, you rarely interact with the names anyway -- you use `true` and `false` as values like most other languages.
I've been a designer/programmer pretty much my entire career and currently work on a research-centric UX design team. So while I've been designing my own language (THT, a language that compiles to PHP, aiming to fix most of the issues with that language), I've been applying usability concepts to the design.
A few principles:
- Acknowledging that the user is probably familiar with other languages, so stay within those conventions when possible. This is inspired by Jakob Nielsen's maxim that web designers should acknowledge that their users send 99% of their time on other websites.
- Making the most common activities the easiest. Larry Wall refers to this as applying Huffman coding to the syntax itself.
- Safe defaults. Making dangerous operations less convenient than the safe path. PHP has pretty much the opposite behavior, where many of the default design choices lead to security issues.
- Cognitive Load. Minimizing visual noise and the number of micro-decisions the user has to make. i.e. There should be one (good) way to do it.
- Preferring shorter, clearer terms over technical jargon. e.g. I use the terms "Flag" instead of "Boolean" and "List" instead of "Array". One can get pedantic over the exact meanings of symbols, but during the actual act of programming, simpler terms can help reduce friction.
Nice work so far. There seems to be growing interest in online roleplaying, but most of the current offerings are lacking right now.
I personally launched Fabletop.com a couple of months ago, but the approach is a bit different, focusing more on a robust chat system, and less on the battlemat.
Normally I'd agree with you, for those exact reasons, and my first prototypes were all generally flat (also being a fan of the Ultima series.)
But when I tried the current isometric style on a whim, it managed to solve all of the problems I was trying to address. Probably because I use a hybrid approach: only the underlying battlemat tiles are isometric. The miniatures are flat, slightly-transparent stand-ups and always face the player.
All of the top-down approaches just look ugly to me. You're either looking at the top of people heads, or tokens of disembodied heads. This also gives it a pseudo-3d look, with a bit of clutter to add that homey tabletop atmosphere.
I learned a lot from playing D&D as well -- my interest in graphic/info design can be traced back to when I was designing my own charts and character sheets.
The benchmark might seem like apples-to-oranges, but they both do templating & routing, which is what is being tested.
I also address this on the benchmark page:
Why compare a language to a framework?
1) THT takes a “batteries included” approach by providing essential web framework features.
2) Some might be worried that running a transpiled language would be too slow to run in production, and Laravel is arguably the best example of a production-ready PHP framework.
Also, yes it is essentially a new language. I don't expect anyone to rewrite large PHP applications in it, but people might consider it for new projects.