Which JavaScript VM are they going to use?
From the article:
> I have a working prototype of a JavaScript VM that is highly optimized for NGINX’s unique requirements and we’ve begun the task of embedding it within NGINX Open Source.
NGINX Open Source: Reflecting Back and Looking Ahead
21–30 of 42 posts
Re: NGINX Open Source: Reflecting Back and Looking Ahead
#22td;rd: interesting things will move to the premium version, JS VM to power future versions, pluggable module API coming
That's not really accurate, and you kind of conflict with yourself. The JS VM will be part of Nginx Open-Source, as will the Pluggable Module API. Nginx Plus is a platform, not just a special version of Nginx open-source, where Nginx is a core component.
That's not how I read his comment, though re-reading his comment I see how you read it that way.
I read it as a list of hi-lights from the article, and I assume that's how he meant it to be read;
- interesting things will move to the premium version
- JS VM to power future versions
- pluggable module API comingRe: NGINX Open Source: Reflecting Back and Looking Ahead
#23Nginx Plus seems like they took a lot of the obvious feature upgrades, some which look fairly easy (remove cached item) and put them in a pay wall. Nothing wrong with that, just feels weird. And the pricing is enough to pay for a Windows license, not that IIS is even close to nginx (it's reverse proxy capability is terrible). I'm sad to hear about JS; I thought the work with Lua was going well and would be a better c…
Lua is a great scripting language in its own right, but the trouble is it's not JavaScript which at this time has an extraordinary amount of momentum behind it. You can use JavaScript inside Postgres, for example, which makes it extremely versatile as a glue language for back-end services. Lua has nowhere near the traction or support. Is there a C++ to Lua compiler that produces performant code when using an asm.js-l…
I didn't know a single Lua programmer, and then one of our software developers wanted to write some code to run in Nginx, and two hours later I knew a Lua programmer, and his solution works great in heavy production use. Seems pretty easy.
Re: NGINX Open Source: Reflecting Back and Looking Ahead
#24Nginx Plus seems like they took a lot of the obvious feature upgrades, some which look fairly easy (remove cached item) and put them in a pay wall. Nothing wrong with that, just feels weird. And the pricing is enough to pay for a Windows license, not that IIS is even close to nginx (it's reverse proxy capability is terrible). I'm sad to hear about JS; I thought the work with Lua was going well and would be a better c…
Lua is a great scripting language in its own right, but the trouble is it's not JavaScript which at this time has an extraordinary amount of momentum behind it. You can use JavaScript inside Postgres, for example, which makes it extremely versatile as a glue language for back-end services. Lua has nowhere near the traction or support. Is there a C++ to Lua compiler that produces performant code when using an asm.js-l…
Lua is already stupid fast, without needing super complicated runtimes. The language is easy and sane. I'm not a Lua programmer but I use it (even in a E9-1-1 related application) just fine.
This sounds like using JS just for ... technically unacquainted people to get their buzzword hit. Like XML was a while ago.
Re: NGINX Open Source: Reflecting Back and Looking Ahead
#25> we’re beginning the implementation of a pluggable module API
This is the most exciting for me, as I'd much rather install from a package than have to re-compile from source.
I've figured out how to make that easier in Debian/Ubuntu: https://serversforhackers.com/compiling-third-party-modules-..., but having a command similar to Apache to enable/disable a module will be really nice.
Re: NGINX Open Source: Reflecting Back and Looking Ahead
#26Nginx Plus seems like they took a lot of the obvious feature upgrades, some which look fairly easy (remove cached item) and put them in a pay wall. Nothing wrong with that, just feels weird. And the pricing is enough to pay for a Windows license, not that IIS is even close to nginx (it's reverse proxy capability is terrible). I'm sad to hear about JS; I thought the work with Lua was going well and would be a better c…
Lua is a great scripting language in its own right, but the trouble is it's not JavaScript which at this time has an extraordinary amount of momentum behind it. You can use JavaScript inside Postgres, for example, which makes it extremely versatile as a glue language for back-end services. Lua has nowhere near the traction or support. Is there a C++ to Lua compiler that produces performant code when using an asm.js-l…
> Is there a C++ to Lua compiler that produces performance code... ?
This statement makes zero sense. It's like someone saying Forth is silly because it doesn't have an asm.js-like layer.
Clearly you don't understand the use cases of Lua.
Re: NGINX Open Source: Reflecting Back and Looking Ahead
#27Nginx Plus seems like they took a lot of the obvious feature upgrades, some which look fairly easy (remove cached item) and put them in a pay wall. Nothing wrong with that, just feels weird. And the pricing is enough to pay for a Windows license, not that IIS is even close to nginx (it's reverse proxy capability is terrible). I'm sad to hear about JS; I thought the work with Lua was going well and would be a better c…
> I thought the work with Lua was going well The lua support is GREAT, and make a lot of complex stuff (standard outside authentication on multiple apps) simple as using a 20 lines lua script. Let's hope LUA doesn't fall to second class citizen.
just to nitpick: Lua is not an acronym. It means Moon in Portuguese.
Re: NGINX Open Source: Reflecting Back and Looking Ahead
#28Nginx Plus seems like they took a lot of the obvious feature upgrades, some which look fairly easy (remove cached item) and put them in a pay wall. Nothing wrong with that, just feels weird. And the pricing is enough to pay for a Windows license, not that IIS is even close to nginx (it's reverse proxy capability is terrible). I'm sad to hear about JS; I thought the work with Lua was going well and would be a better c…
> Nginx Plus seems like they took a lot of the obvious feature upgrades, some which look fairly easy (remove cached item) and put them in a pay wall. I had a chat during an interview with folks from the Nginx team recently and definitely got the impression they are putting a lot more thought into the separation of Plus than this. One of the key features is the ability to add/remove backends at runtime, as well as, II…
> If you read the prior article, linked in this one, the original author of Nginx is allowed to expound on this himself. An experienced Ops team can assemble a number of open-source components and custom code to accomplish some of the more advanced functionality in Nginx Plus, but I think it's saving more than a couple hours of customization. :)
Can you elaborate? I'm able to do almost everything with haproxy, including hot reloads, client-based SOA, frontend/backend traffic. I'm not sure what Nginx Plus gets me on top of that.
Disclaimer: From an ops team.
Re: NGINX Open Source: Reflecting Back and Looking Ahead
#29Which JavaScript VM are they going to use?
From the article: > I have a working prototype of a JavaScript VM that is highly optimized for NGINX’s unique requirements and we’ve begun the task of embedding it within NGINX Open Source.
I am a bit surprised it isn't V8, considering its high performance and relative success in Node and IO.js
Re: NGINX Open Source: Reflecting Back and Looking Ahead
#30Earlier quoted context omitted.
From the article: > I have a working prototype of a JavaScript VM that is highly optimized for NGINX’s unique requirements and we’ve begun the task of embedding it within NGINX Open Source.
I am a bit surprised it isn't V8, considering its high performance and relative success in Node and IO.js