61–70 of 107 posts
https://docs.microsoft.com/en-us/dotnet/api/system.web.scrip...
RPC - this isn't anything new. When I started doing web development in the late 90s for about ~5 years I was the designer, front-end, and backend developer all in one. Then over time things changed to allow for specializations and we now have many different functions, and that's a good thing. RPC has a place, and it's not for web apps, at least most of the time. I've noticed over the years that JavaScript developers…
I'd imagine it's probably a business thing as well. The idea that they can easily transfer people from frontend to backend tasks or have full stack devs who don't need to know two languages. Where I work, having one language has made things simpler when doing tasks. Don't need to look things up as much because you keep forgetting which one uses push vs append, etc.
Oh, you're a poet, right? I need you to write some legal documents. You are already expert in English, so it should be easy.
RPC - this isn't anything new. When I started doing web development in the late 90s for about ~5 years I was the designer, front-end, and backend developer all in one. Then over time things changed to allow for specializations and we now have many different functions, and that's a good thing. RPC has a place, and it's not for web apps, at least most of the time. I've noticed over the years that JavaScript developers…
Earlier quoted context omitted.
I'd imagine it's probably a business thing as well. The idea that they can easily transfer people from frontend to backend tasks or have full stack devs who don't need to know two languages. Where I work, having one language has made things simpler when doing tasks. Don't need to look things up as much because you keep forgetting which one uses push vs append, etc.
> The idea that they can easily transfer people from frontend to backend tasks or have full stack devs who don't need to know two languages. Oh, you're a poet, right? I need you to write some legal documents. You are already expert in English, so it should be easy.
They write the Javascript for you but you won't even notice it.
I don't have experience with Phoenix, but with Blazor I just write my complete SPA in C#. There is no API for communication between the server and client. Blazor creates all the JavaScript websocket code for me so I never need to write a single line of Javascript.
And when you separate your business layer from Blazor you can always add an API in the future when you need one. Just create some controllers for your API and use the same business code Blazor is using.
Pouchdb/firebase/backend-as-a-services were supposed to be the answer to getting rid of CRUD apis. The problem is authorization and validation becomes really difficult if you don't have a backend that you can trust.
>Sorry, this site requires JavaScript to be enabled. For a flat blog post? Like, seriously?
the OP message falls flat when it can't even be bothered to server render. also, most offensive is the use of 3rd party js hosting. given the tiny size of the 3rd party libraries (relative to 1st party code), add them in to the code from your own site (which you're already bundling up. SMH) [from jsdelivr.net] polyfill.min.js (31.8kb/96.8kb) (wire/resource) url-polyfill.min.js (1.9kb/6.1kb) react.production.min.js (4…
CORBA called, they want their ideas back
Even in JS, the Meteor framework was basically created to implement this. Except they actually implement things like validation, because as much as one may want to unify both environments, the reality is that exposing all your methods to the outside world may have some pitfalls, to put it mildly.