I am one of those JS guys who like to put JS/Node.js everywhere, but I do not get the problem Redbird is trying to solve: the Express.js doc is quite clear that for serious things, you should use a dedicated http server. [1]
If you just want reverse-proxying, you can choose between the simplicity of Caddy or the power of Nginx (or Apache). Why would I want to run a JS app (that I know will be less performant) to do that?
> If you just want reverse-proxying, you can choose between the simplicity of Caddy or the power of Nginx (or Apache). Why would I want to run a JS app (that I know will be less performant) to do that?
The same reason you'd use Caddy over Nginx or Apache, why use the former over the the latter when the latter already exist and are faster? Because someone who knows Go but not C can customize its codebase, just like someone who knows JS but not C or Go can modify Redbird's.
If Node.js is good enough to build and run servers then it's good enough to build reverse proxies.
No, not correct. Why do you think it's okay to immediately jump to an absurd conclusion?
There's value in being able to modify the software you're using. That doesn't mean you throw out absolutely everything every single time you want to appreciate that value.
There are cases when performance is not your main focus but simplicity of use is. Like during development. I'd of course never use this in production, but it's perfect for my development needs.
I agree with the sentiment, but using nginx as a proxy is reasonably easy (at least after you make one that works and can reuse that configuration.)
The advantage of developing on as similar a platform to the projected production platform is that when you do deploy to a real environment, there are fewer nasty surprises.
How easy is it to use nginx for dynamic proxying? Wondering, because the need I have is to be able to dynamically route requests to ephemeral flask apps that could be on a different host/port at any given moment. Not my design BTW, but it's what I need to do.
The thought was to have node manage the flask processes and another tracker service which would dynamically proxy to the apps. Can nginx provide this? Forgive my ignorance, just new to the concept of dynamic proxying.
nginx is just a web server so it doesn't have dynamic programming capabilities. However, if you wanted to do something like that from nginx you could script it in Lua using OpenResty https://github.com/openresty/
It is not reasonably easy, I can't set it up completely with "git clone" and it does not stay inside the project (that's an issue when your developers use a huge variety of operating systems with varying installed and configured software). That means a lot of time lost during problem solving with the hundreds of developers I work with, most of them have never even heard about nginx, they're developers, not sysadmins.
There absolutely should not be any nasty surprises with switching a reverse proxy, and you can cover that with end to end tests. Such issue would be a bug in the reverse proxy.
Of course there are things like Docker, but that implies performance issues on Mac.
> If you just want reverse-proxying, you can choose between the simplicity of Caddy or the power of Nginx (or Apache). Why would I want to run a JS app (that I know will be less performant) to do that?
I don't have the numbers to back this up, but I would be inclined to believe that a Node.js implemented reverse-proxy would outperform Apache.
- node (whose main reason for existing is event driven IO) is in the same order of magnitude as nginx (whose main reason for existing is also event driven IO). I think sometimes people think node is ruby/python/php levels of performance. It isn't.
- And as another comment mentions, developer productivity may be better than minor performance difference - you mentioned Caddy, same rationale applies here.
- nginx is also a bit crippled as useful features (like dynamic reconfig) are only in the proprietary nginx plus.
- This has good defaults - having to set up the seperate webserver for ACME is a pain, this is way easier.
But actually, you could have setup a pure Python server instead of nginx for the last 10 years with twisted.
Not that you should not consider uring nginx anyway: it deals with caching, load balancing, has great tutorials, it's battle tested, and has tons of pluging.
Sure, I mentioned Tornado a few minutes before you posted this. Twisted obviously counts too, I dislike the non-PEP8 coding style it uses but that's off topic. I love Python's non blocking features, they're just not in the mainline VM right now. Here's hoping for a libuv or whatever else non blocking Python 4 VM / stdlib.
Do you know of a performance benchmark that shows the current status? I can't find many that describe node not at those levels of performance, Especially against Ruby.
I haven't seen anyone compare Ruby to node perf, unless there's a non blocking variant of Ruby (looks like nio4r), in which case it would have similar perf.
Likewise node vs Python Tornado would be a good comparison.
Thing is, nio4r and Tornado aren't the standard library. Whereas node's stdlib is: node's file and socket read operations etc are non blocking, Python and Ruby equivs are not.
Also (addressing weird moderation - sudden downvotes when I mentioned other languages): please don't turn this into a lang tribal thing: I personally think Python is a better language than JavaScript, it just blocks by default. This isn't a matter of preference, it's a fact.
That resource looks like node is faster than those other languages? I think you might be getting the down votes because your comment is being interpreted that it is slower.
I find this as a failing, at least partially, of desktop monitors. Once the DPS is high enough you kind of stop caring about individual pixels. However most laptops and desktops out in the wild have screens which are 1080p at best. Nota bene: I'm talking globally, developed countries are doing better int his regard.
Wayland is actually pretty stable. Nvidia has problem with OpenGL in Xwayland (i.e. 3d accel for x11 apps), otherwise, it should work.
There are warts though, when using Wayland. When using scaling (doesn't have to be fractional, either), X11 apps are being upscaled, not downscaled, resulting in blurriness. Unfortunately, neither Firefox nor Chrome does support Wayland natively, and who wants to use their most used app on their computer in blurry mode?
Must admit I don't understand what Wayland is, or X server for that matter. Would someone mind explaining it, for someone a bit dull of mind as myself?
In short: X.org is a decade old display server that became the standard to display graphical window on the majority of Linux distribution. GNOME, KDE, XFCE and others are/were client to this display server.
Wayland is a new protocol where the window manager (ie GNOME, KDE,...) is responsible of directly managing the display. Each window manager must reimplement this protocol (or use a library already doing this work) which enable them to have more control over the windows.
Applications must also directly support Wayland like they did for X.org before (which was the default commonly used, so no problem) or the user just have XWayland installed on their computer to show X.org windows inside a Wayland WM but then the application may not display correctly (blur, artifcats,...)
It is perhaps worth noting that while X.org is about a decade old, it is an implementation of the X Window System protocol which dates back to the mid 80s.
Suffice to say, quite a lot has changed in computer graphics/interfaces since that time, and most modern *nix operating systems end up circumventing quite a lot of X to offer modern features. Thus X brings quite a lot of legacy debt to the table which can't be easily removed.
Gopher and HTTP had a similar situation. Gopher had a lot going for it, but the future licensing situation was unclear. HTTP was free, clear, and widespread by the time Gopher became GPL.
It doesn't play nice with OMTC, or 3d accel in general (see EGL bugs in bugzilla), and has problems with scaling and input. It is a work in progress, that's why it is disabled.
> It dosen't happen that way on windows. I had scaling set to 1.25 and got no issues anywhere.
You do get scaled (and hence somewhat blurry) icons if you do 1.25x on Windows as well. 1.5x usually works better, because icons scaled by that much tend to hit the next size tier that is often available prescaled to look good (16x16 -> 24x24, 32x24 -> 48x48).
If you do fractional scaling on a svg image, pixels will not align to the pixel grid and the image will look blury. You won't notice that on big svg images, but tiny ui icons will definitely look blurry.
There was even a (never implemented) proposal to allow svg files to handle this problem.
That's why svg icons are often designed using a 24x24 pixel grid, so you can scale them at 48X48 (x2), 72x72 (x3), 96x96 (x4) and they remain pixel perfect and crisp at those sizes.
If you have a 1366x768 screen why would you need DPI scaling? You shouldn't be affected by this issue at all if your resolution is below a certain threshold.
I use KDE with x1.3 scaling and it mostly works, but e.g. VirtualBox is unusable with scaling, pdf fonts in Okular look torn, some pixel maps scale poorly giving artefacts.
Still, I don't have better options: 13" FullHD doesn't play well with 2x scaling (and even 1.5x would usable, but too big for my taste).
Canonical can only be blamed for this if you disagree with their decision to move to Wayland and Gnome. Fractional scaling has been planned in Gnome for some time now (it was originally supposed to be in 3.26).
That's probably a fair assumption, OTOH paras and commandos are "projection" force so one could expect them to be able to arrive very quickly and set up with little to no resources. Wouldn't be the worst disaster relief force early on.
Prop-types is for runtime, TS does static type checking. Prop-types are terribly verbose and only work with React (what about utils files, external libraries, etc?).
The start-up scene is currently definitely at an interesting point: really young and active (people already shared links to Startup studios, you should have a look at them). The meetup scene is great too.
The salary is still a pity though (compared to the States, Switzerland or Baltic countries). For a middle developer position, you may be around 40K euros, which is "nice in France", but not a lot, especially after paying your taxes.
> How good does my French need to be?
To work, English is fine, to live, it's another problem. French people are usually really kind to people trying to learn French as it's a hard language. If you don't care about french, people won't care about you.
> Are there any languages/platforms/etc. that are popular there more than in Silicon Valley/Fairfax County
There's a bit of everything, but the Web and Robotics are especially important.
> For a middle developer position, you may be around 40K euros
I won't get into details here but 40k€ before taxes ("brut") for a developer between junior and senior is not considered that good in Paris anymore. It would have been decent 8 years ago but wages went up with the increase in demand. Of course it depends on skills, position, stack, etc...
That being said, you will almost always make more money working as a freelancer, and you will definitely make more working remotely for a California-based startup (which may be difficult because of French employment laws but is still definitely possible).
I don't know how much has changed in the last 5 years, but "more" in the US was at least 3 (over 4 for me) times more. Computer programming (in the mainstream regard) was a "meh" position: something you do while trying to become a manager.
I loved it there and would advise anyone to do it (I'm thinking of doing it again!) - but if money is your goal... I traded an awful lot of "opportunity dollars" for "opportunity experiences".
I am working in Tallinn. This is the first time I've ever heard anyone say anything good about the salaries here. I'm happy with mine, but it would be 3x higher in US and Switzerland (I have also worked there). What do you base this opinion on?
As a front-end developer, accessibility has always been a way for me to describe to non-technical people what I actually do for a living.
Saying: "I build web applications" means nothing to them, and saying "I create website" makes you look like a wizard doing some black magic.
But saying "my job is to make websites accessible to everyone: we are used to use a screen and a mouse, but what if you are blind or deaf? Those people should not be allowed to go on any website? My role is to make those people able to browse the web, as you and me" give them an example of what kind of problems you actually solve as a web developer.
> Saying: "I build web applications" means nothing to them, and saying "I create website" makes you look like a wizard doing some black magic.
Who are these people? When people ask what I do I just tell them "I'm a developer; I make websites" and they understand what I do enough to move the conversation forward. Is there other context I'm missing?
There's a difference between informing someone of your job title (serviceable smalltalk) and actually telling them what you do (likely reserved for a conversation with someone who's demonstrated some interest)
That's a pretty good way of communicating. I need to start changing "I write web servers" to "I make sure our customers, who are frequently in the middle of nowhere, can interact with the services we offer."
But those two statements seem to me to be very different. The first would make you a web backend developer and the other more of a network engineer or sysadmin. I know this probably isn't too different for many people, but those people won't probably be able to imagine a specific job if given either description.
I don't want to be just negative, so I'd like to suggest an alternative: "I make parts of computer programs, like <names of well-known products that are similar to ones you make>". This will be easily understandable to everyone who knows what computer programs are and also won't be misleading. You could also add "for the internet" somewhere if that part is important.
While the roles certainly overlap, frontend dev and accessiblity for me have become separate roles. The level of knowledge and expertise just too much in each.
If you just want reverse-proxying, you can choose between the simplicity of Caddy or the power of Nginx (or Apache). Why would I want to run a JS app (that I know will be less performant) to do that?