jlesk

Thanks for the comment.

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 really like the line art logo on the site, but it's 2.4 MB (avatar.png).

Might want to size it down and run it through TinyPNG. :)

If you're into this kind of thing, I made a similar Turtle clone with a simpler syntax:

http://prismaco.de/

But I also like the approach here of using Turtle as a way to introduce JavaScript syntax. :)

Double-arrows let you signify that the tag is different with no extra effort because it's just an extra tap where your finger is already positioned.

It also has a right directionality to imply that it has scope until the end of the line.

Triple-arrow is the same idea, but uses the convention that triple-characters are common for delineating multi-line blocks.

Hi, thanks for your feedback.

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.

Thanks!

I've used Node for many years, but I do find it too complex for some of my projects.

Sometimes you just need a handful of dynamic pages that you want to put up on a shared host somewhere. PHP is great for that.

Douglas Crockford also has a good article on how to implement Pratt parsing in JavaScript:

https://crockford.com/javascript/tdop/tdop.html

I referenced it often when I implemented THT. (https://tht.help)

Netflix employee here. You can find out a lot about our culture from our culture page:

https://jobs.netflix.com/culture

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.

Hope that helps.

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."

https://jobs.netflix.com/culture

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."

https://jobs.netflix.com/culture

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.

https://tht.help/tutorials/language-tour#lock-strings

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.

The project is at https://tht.help if anyone is curious.

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.

Good luck to you guys!

Do you also own recievd.com? I'm sure a lot of people forget "I before E, except after C."

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.

Related to D&D and startups, my current project is a web-based virtual tabletop for roleplaying, built on node. =)

http://tabletopquest.com

After doing it the longhand way for over 10 years, I will never go back to that after using Haml. It just feels like the right solution to the problem of dealing with lots of nested markup. It might not be obvious what a benefit it is until you try it. I actually use my own custom-rolled flavor of Haml that is less Ruby-like, and I think it maps a bit better to the stylesheet and javascript.

On the topic of javascript templates, I tried Jaml for a while because I really wanted to have templates that could be cached on the client-side, but the function-based approach was really cumbersome. I ended up creating a server-side pre-processor that converts Haml to vanilla javascript functions that just build the output using string concatenation. These are called at run-time by underscore's template function. Overall, I'm totally happy with it so far.