Earlier quoted context omitted.
I'm willing to bet it won't bring them any new business. And in the long run, it will encourage their existing users to dump nginx and use Node.
Isn't Node more of an Application server though? I don't see Node replacing Nginx in the roles it's normally used for (serving static resources, reverse-proxy). I can't think of a single upside
Launching NginScript
101–110 of 131 posts
Re: Launching NginScript
#102This 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.
Re: Launching NginScript
#103Earlier quoted context omitted.
So when are you going to release "node-ginx"? :)
You're on to me. ;) There is node-http-proxy available ( https://github.com/nodejitsu/node-http-proxy ), which also has some plugins available to do some of the advanced features nginx supports. I'll likely be writing a custom proxy server tailored to our needs such that it probably won't be useful as a general purpose proxy server, but if you're looking for something, that's a start. Making it more general purpose u…
Re: Launching NginScript
#104Re: Launching NginScript
#105HN and it's predictable level of antipathy is a constant disappointment. Hating is the norm, do better. Put more thought into your opinions. Personal feelings of Javascript aside (not my favorite either!), I think this is a great business move (adoption, excitement, blog-o-sphere marketing, even if some users shoot themselves in the foot), and I think it opens up exciting possibilities, including creating Nginx+ feat…
The antipathy is a symptom of our JavaScript disease. We have grown tired of this affliction. We understand now what makes it less great than we once thought. The churn of rapidly growing and devolving JS frameworks, the slog of awful design-by-committee processes putting the language together... it is nothing compared to Lua's simplicity.
And some clever fellows understood this long ago, on a site much like this one. Feel free to take a look. https://news.ycombinator.com/item?id=7890685
Re: Launching NginScript
#106Earlier 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.
Re: Launching NginScript
#107Re: Launching NginScript
#108We run a separate virtual machine for each request, so there’s no need for garbage collection I'm curious to see the impact of this strategy on performance.
I wondered about this sentence. If you would apply scripting functionality to serve long-running websocket or HTTP/2 connections I'm sure garbage collection would be necessary. However if the scripts are really per request and not per connection then it could work - but the capabilites would be much more limited then what you can do in other scripted-webserver-environments (e.g. node).
Re: Launching NginScript
#109Earlier quoted context omitted.
I have tried so hard to like Lua, but I prefer 0-indexed arrays and curly braces.
The comment syntax is really what gets me.
Although the same happens in JS with Regular Expressions :P