Live data from Hacker News

Launching NginScript

nginx.com

111–120 of 131 posts

Re: Launching NginScript

#111

I can't help but think this is a bad idea. Jamming more stuff into what is a great tool puts nginx on a slow path to a bloaty death. Am I incorrect in assuming that you could implement your entire server-side js app now as an nginScript module? Do people think that is a good thing? Not to mention that putting more interpreters and more end-user code into a system that has access to your service's private key might no…

> Am I incorrect in assuming that you could implement your entire server-side js app now as an nginScript module? Do people think that is a good thing?

This is kind-of already possible with OpenResty: https://openresty.org/

You can also use Lua, a programming language more than capable of producing efficient web application backends, directly in Nginx config files: https://www.nginx.com/resources/wiki/modules/lua/

So...in a way, this has really been possible for a long time. I'm not disagreeing with you, because personally I'd much rather build my web app in a language and toolchain that's easier to work with, but I find it interesting to read about.

Re: Launching NginScript

#112
post #17

Earlier quoted context omitted.

It is. But JavaScript is the new assembly language, all you need is a Lua to JS compiler or a whatever to JS compiler.

Last I checked Javascript implementations were slower than LuaJIT. Cost of implementing Lua tables, meta-tables, co-routines, etc. in Javascript will be rather high. Anywhere between 2-50x. If native Lua engine is removed, you can just forget about it then. So what you're saying doesn't make any sense for anything remotely performance sensitive.

> Cost of implementing Lua tables, meta-tables

Tables and meta tables are nearly identical to objects and prototypes in javascript. Why would the cost of implementing them be high?

Re: Launching NginScript

#113
post #64

I think Nginx is open source crippleware. All the goddies are in the closed Nginxplus. Http2, load balancing with monitoring with application health checks. Do you get the source code of the closed features? Nginx already has LUA scripting support.

tengine fork has application health checks, although I'd still probably recommend haproxy

Re: Launching NginScript

#114

It's sad to see lua get slowly replaced by javascript.

I think is is sad to see anything replaced by Javascript. Unpopular opinion I guess. So many better choices out there.

I'm totally with you. JS is such a bad language, might get better in the future with ES but I guess not. It has many quick hacks (in the bad sense), admitted by it's author.

Interesting pattern I see lately is industry pundits on the CIO side advocate Javascript for inhouse tooling. I guess they have not much experience with programming languages.

With JS making inroads into CIO territory, we'll see a much higher usage in the future. And a much larger fallout with tons of unmaintainable legacy code.

It's like the times when everything needed Java, like Oracle added Java into their DBs for stored procedures. I guess Oracle will add JS too (or have they already?).

Re: Launching NginScript

#115
I can understand the appeal, marketing Javascript to CIO/CTO is much easier than marketing Lua today.

(Which obviously is sad as in my humble opionion for various reasons Lua is the better embedded language. I hoped it could become a widely adopted standard, we had great success with Lua in Redis in the past).

Re: Launching NginScript

#116

This seems like massive overkill. Instead of adding a limited domain-specific language which is tuned to nginx's requirements, they've added the behemoth that is JavaScript, along with all its flaws. A turing-complete behemoth, at that.

It's a subset of javascript, with a subset of flaws. The wiki entry specifically mentions that eval and closures aren't supported.

closures as in "first class function values"? Or closures as in scope that follows a function from where it was defined?

Re: Launching NginScript

#117
post #85
post #47

Earlier quoted context omitted.

The usefulness of this is not to turn nginx into an application server. Although there are already frameworks for this using ngx_lua ( http://leafo.net/lapis/ ), I don't find them very interesting except for the technical aspect. The point is to make nginx's configuration dynamic and prevent bloating applications with stuff that belongs at the (lets call it) devops level. Now, I also don't think nginScript is such a…

"The point is to make nginx's configuration dynamic and prevent bloating applications with stuff that belongs at the (lets call it) devops level." No, let's not call it that, because I have no idea what you mean when you say that.

Throttling, request routing, security workarounds, integrating multiple applications under a single nginx reverse proxy, ...

If you do ops or interact with an ops team, I'm sure you can find many more examples.

Re: Launching NginScript

#118
post #17

Earlier quoted context omitted.

Last I checked Javascript implementations were slower than LuaJIT. Cost of implementing Lua tables, meta-tables, co-routines, etc. in Javascript will be rather high. Anywhere between 2-50x. If native Lua engine is removed, you can just forget about it then. So what you're saying doesn't make any sense for anything remotely performance sensitive.

> Cost of implementing Lua tables, meta-tables Tables and meta tables are nearly identical to objects and prototypes in javascript. Why would the cost of implementing them be high?

JavaScript objects are indexed by strings. Lua tables are indexed by arbitrary objects. In JS a[1] and a["1"] are the same element but they are different in Lua. In Lua a[{}] is a new element indexed by the identity of the new object literal, and will be a different element every time the expression is evaluated.

Re: Launching NginScript

#119

A web server with a JavaScript engine. What could ever go wrong? My eyes start to bleed when I imagine what some cowboys will implement on top of that.

Netscape Enterprise Server included server-side JavaScript in the 1990s.

Re: Launching NginScript

#120
post #3

Earlier quoted context omitted.

I'm not sure if this is great idea. Use of reverse proxies has lots of benefits. You can manage load balancing, SSL Termination, serving static content (much faster), caching, compression, centralized logging, and using different applications on the same ur space (foo.com/app1, foo.com/app2). They also have the added benefit of another layer of security (look for and prevent various HTTP exploits and prevent them fro…

I use nginx at Neocities to serve all our static sites, and as a proxy for our front site. I like nginx, but it has way too much of a sacred cow treatment by the dev community. It has plenty of problems, the configuration is a psuedo-language that doesn't always make the right choices and is difficult to heavily customize, and I've gotten to it be -very- unstable under certain circumstances, including really bread-an…

One of the things I don't understand about nginx is why a HTTP daemon still contains a mail proxy today!
Post reply on HN