On Tue, 26 Apr 2016, ra...@openmailbox.org wrote:
> If you want to make a dynamic "web application" then consider using
> ur/web [1]. The programming language itself protects against SQL
> injection, XSS attacks, CSRF attacks.
I hate to bring the bad news, but this language / framework has close to
zero chances of being used in a commercial product.
- ML / Haskell are too abstract for the 99% of Python/Ruby/JS/NameIt
programmers out there. You or me love ML, the next guy will run away.
- The website itself looks horrible. You or me don't mind, because we
focus on content and not presentation, but we're not in the 99%. Also
it takes actual effort to make a website look this horrible...
- The documentation is lacking horribly. First off, these days if your
TLDR to a "200 OK Hello world" is not in 10 lines and on your landing
page, you probably have already lost 90% of the potential audience.
The remainder got lost in incomplete examples and a terse reference
manual.
- Nobody is interested in writing the most elegant qsort, because
Python/Ruby/JS/NameIt already have a working implementation in their
standard libraries. They also focus on helping you solve more real
world problems (pushing HTML or JSON to browsers), which, skimming
over the docs, I didn't see explained.
Sorry, but few people today judge a product based solely on its
theoretical merits; they need a toy to play with, and to see that it can
help them solve their problems.
A "half-secure" product that is easy to use, is more secure than a
secure product that nobody cares to use, because it provides a typical,
real-world user with a viable, real-world alternative over a completely
insecure product that is also easy to use.
> String based scripting languages like {node, php, python, perl, ruby}
> have added on frameworks that try to 'prepare' sql queries or template
> HTML to get it to do the various different levels of quoting for you.
> It's possible to make secure sites in them if you do everything right.
> problems still slip through.
Not necessarily. Consider a function prototype:
query(template: string, param1: mixed, ...) -> result: mixed
Whether this function is correct or secure or not, does not depend on
the language it was implemented or used in. Using it securely is still
up to the caller. Good interfaces can help good programmers write good
code, but you can't stop a bad programmer from writing bad code...
> That's why I recommend a programming language designed to remove these
> issues entirely by parsing and understanding the sublanguages involved
> in making a website (instead of having them as strings in your code).
Context-sensitive templating languages are a thing in mainstream tools.
I'm not a frontend web developer, but some quick googling brought this
up:
http://www.slideshare.net/adonatwork/efficient-contextsensitive-output-escaping-for-javascript-template-engines
K.
