I don't think any of the current JS frameworks are as comprehensive as Rails but it's clear where the momentum is.
About frontend: JavaScript all the times if there is a frontend separate from the backend. React with some rare Angular project.
I'd like to make a poll and see how many of the people here are working on a JavaScript backend vs any other language.
Anyone use it? Thoughts?
So selection bias is very possible.
In particular Blazor offers two interesting approaches (“hosting models”):
1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time.
2) a wasm based approach where the whole application is delivered to the browser and you make the API calls.
Both have you writing majority of the code in C# and Razor templating syntax. Yes, you make an argument that well it’s technically still JS running it. But this becomes an implementation detail that will be ironed out, because technically the browser is written in C++, but we look beyond all that. And so on and so forth.
Now, I’m not saying I expect the world to move to .NET. Far from it. I have been preaching for a language agnostic browser execution engine so that I can write not only my logic, but my layout and styling in whatever language I want to, whether it’s Ruby or F# or Lisp, and have the browser execute it via its own internal “assembly code”. Except I’ve been parroting this idea since mid-2000s and we have at last finally started down that road.
I think this is where we are headed, and I don’t think it’s far fetched.
>1) a websocket-based HTML sync layer, basically shipping over the smallest amounts of render state from the back-end. This is as close as you get to having, essentially, a server-side rendered page that is then updated in real time.
Also it's not like you have to load the runtime more than once. So it's not that it's a non-starter for anything performance sensitive--it's a non-starter for anything that can't download a 2MB file up front (I believe their goal is to get it down to half that size) if you want to use the WASM version of Blazor instead of the websocket-based HTML sync layer version.
2. 2MB includes bootstrap CSS and they are working on getting that number down.
3. 2MB is only the Wasm version of Blazor. You don’t have to use that version if it doesn’t fit your use case.
Most people I've talked to using Blazor are in fact using Blazor server not Blazor WASM.
To someone who is switching from the Node ecosystem to Django REST, this seems like an understatement.
I'd be happy to use server-side JS for certain microservices that needed its performance characteristics, or for prototyping in something like Firebase functions. But the mere thought of building a standard fully-featured web app in Node depresses me.
yeah tools like django are amazing packages. node is shockingly hardly any more tamed than it was 5 years ago, still rag tag Express for the most part. with who knows what for the data layer.
but it just doesn't matter. alas! the actual application has been heavily front end biased, & all the real investment g architecture needs to revolve around that front end. it'd be great to have better out of box omakase js experiences. projects like hapi & fastify tried. but there's just not enough effort spent on the back end for that many devs to really care. and plenty of folks are using api based systems or hosted backends, appsync or some hosted graphql, where they can care even less about the backends.
why be comprehensive when you hardly matter?
Even if you have a SPA, which isn't a given (yes, trends. I know. They come and go), the API, data migrations and background workers can easily be 50% of your code and effort.
Like I said in other comments I'd only build an API in Express if I needed its particular performance characteristics.
I've checked other tools in the JS ecosystem that serve as "low-code" API layers, but upon close inspection they always seem to have some limitations on the business logic you can write, and some of them lock you in to products. No thanks.
I'm finding Django REST gives me a sweet middle ground between dev speed backed by great abstraction "magic" and freedom to customize as the app grows.
huge js lover here but I don't think this is true. I think the basic obvious progression is that the client side has shouldered more & more responsibility, that architectures have shifted away from being server side, & few folk have figured out how to make the server relevant. it does a tiny bit of business logic & mostly just crud operations on data. trying to do like we did, keep rendering & a lot of the client state on the server- it wasn't helpful, was a bad way of doing things. these choices of languages became irrelevant as the client side rose in prevalence, capabilities, & yes too, somewhat, performance, but mainly I chalk it up to a long long struggle to find suitable architectures. I don't think this is fair accompli, that it's all decided, but server side needs to radically change it's game if it wants to become relevant again.
This is not true – PHP is still much faster when running on the server than NodeJS.
JS has got much faster in the last 20 years, but in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on).
From what I can find, in most benchmarks, Node.js is much faster than PHP - orders of magnitude in many cases [1]...
This is what I've always heard anyway, that the amount of R&D that has gone into engines like V8, the C++ under the hood and the I/O model make it so.
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Instead PHP is faster for the things websites normally do, like string manipulation.
"Instead PHP is faster for the things websites normally do, like string manipulation."
No, this is not right for a couple of reasons. NodeJS is potentially slower in certain CPU-bound tasks due to the single-threaded nature of JavaScript.
On the other hand, thanks to its event loop and concurrency model, NodeJS is much faster than many languages/runtimes in I/O (reading/writing to stores, fetching data from other servers, etc.) - which is what many web servers do most.
Your original comment also mentioned:
"in-browser execution has seen most of the speedup (as it's where most of the optimisation is focussed on)."
Which is also not true. The V8 engine is hyperoptimized and runs not only Chrome but Node too. It is precisely one of the reasons why server-side JS has gained in popularity over the last decade. The fact that it was initially devised for a browser environment does not mean that optimisation is focused there.
If you're an engineer or web developer I really suggest that you brush up on these things, because with comments like the ones you've been dropping you'd definitely raise eyebrows - and not for the good...
https://www.techempower.com/benchmarks/#section=data-r19&hw=...
It is certainly true that NodeJS has become much faster as your synthetic benchmarks shows, however we have to measure our programs in the context of intended use, as previous poster suggested.
NodeJS wins against PHP when NodeJS does not make an external database call, like in the two test suites JSON serialization and Plaintext, but as soon as you throw in MySQL database PHP wins.
What does this tells us? That V8, the implementation of the JavaScript, is faster than the Zend engine, the implementation of PHP, but the event based NodeJS platform is not faster than the PHP(Apache/Nginx) platform.
NodeJS performance has evolved massively thanks to V8 R&D, as you already mentioned, Zend Engine has also gained a lot performance but of course not comparable to V8 for obvious reasons, the prior is a Google based project, the latter is a volunteer community based project. However the PHP stack also consist of a web server, and they has also evolved massively the past 20 years, Nginx is relatively new on the scene with an event based asynchronous architecture and Apache has evolved with a new PHP module.
I think your personal attacks against muglug, regardless if he was right or wrong, is not appropriate for this forum, especially when you yourself is not entirely up to date.
Edit: typo
I’m doing ok, thanks, and a little humility would go a long way :)
I work at a company where we run PHP as both a shared-memory server and also in a more traditional per-request model, both serving millions of requests a day. Separately I’ve created (and maintain) a 200-thousand-line multi-threaded PHP application with over 4 million downloads. I’m reasonably aware of PHP’s performance characteristics.
I’m less up-to-date on Node, admittedly, but it also intuitively makes sense that the V8 engine will be optimised more for in-browser use than serverside use.