A project using Elixir + Phoenix would be way cleaner if one would like to leave out the API in web dev.
Do we need a web API?
41–50 of 107 posts
Re: Do we need a web API?
#42>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.7kb/12.3kb)
react-dom.production.min.js (36kb/116kb)
[from liaison.dev]
bundle.a7c7d78d57.immutable.js (108kb/375kb)
actual website code: https://github.com/liaisonjs/liaison/tree/master/website
Re: Do we need a web API?
#43Earlier quoted context omitted.
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.
What ever happened to Meteor? It was flavour of the month a few years ago, with many a frontend dev ranting about how great it was. Now seems to be forgotten about.
Facebook came out with GraphQl and they went on to build Apollo for it and left Meteor behind.
Re: Do we need a web API?
#44Re: Do we need a web API?
#45Earlier quoted context omitted.
welcome to the web 2.0 cooming soon: web assemply web 3.0 which (I fear) might feel a lot like flash web pages from the early 00s. I hope I'm wrong.
Web 2.0 was like 15 years ago now. Web 2.0 was "supposed" to be about separation of style & content and gracefully degrading JavaScript. I don't know want to call what we have now.
Probably the "Web App" or "Web SPA" era, since everything seems to need to be a single page app that exists mostly in the client.
There are some benefits, of course. Stable and standardized UI is finally available as a baseline for devs (much like early Windows/iOS software) and all roads are clearly leading toward a unified design model for phone apps/web/desktop. Bloat and needless complexity are the biggest issues at the moment, but all the frameworks seem to be (finally) focusing on becoming more snappy.
Re: Do we need a web API?
#46I daresay that if you need to:
a) scale, and
b) adapt over time
you're going to find yourself decoupling and slapping APIs on both ends to adapt to the transport mechanism.
So for a boutique app, you might get away with a client-server model.
Re: Do we need a web API?
#47Things like this have been tried many times before. (I made one myself back in the day). It always seems like a great idea up front, but never ends up quite working out.
One of the big things is that the benefit declines over time. The amount of code reuse you get is sub-linear with respect to the size of the project. As the project matures, GUI code and back end code diverges. That leaves you stuck in a framework that ends up not necessarily optimal for server side, and not necessarily optimal for client side, and the amount of code you end up writing to coordinate between them ends up outweighing the actual business logic.
The things that are successful tend to focus on problems that increase with greater than linear complexity as your app matures. Spend time focusing on these instead. Don't lock yourself into a framework that prohibits it.
Re: Do we need a web API?
#48RPC - 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 tend to try and put their JavaScript everywhere and I often wonder if it's because they don't want to learn other technologies. Don't get me wrong, I like a little bit of JS too - I even added JavaScript support to an old 2D Game engine using SpiderMonkey (before V8 was a thing) back in the day so that I could make desktop games with JavaScript. I just don't want to do _everything_ with JavaScript. Especially with so many interesting languages and technologies to play with these days.
Are JavaScript developers today the PHP guys of the past?
Re: Do we need a web API?
#49Things like this have been tried many times before. (I made one myself back in the day). It always seems like a great idea up front, but never ends up quite working out. One of the big things is that the benefit declines over time. The amount of code reuse you get is sub-linear with respect to the size of the project. As the project matures, GUI code and back end code diverges. That leaves you stuck in a framework th…
> As the project matures, GUI code and back end code diverges.
This. This is why ASP.NET, ServerFaces, JSP+Taglibs, etc. became a nightmare.
Re: Do we need a web API?
#50Earlier quoted context omitted.
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.
What ever happened to Meteor? It was flavour of the month a few years ago, with many a frontend dev ranting about how great it was. Now seems to be forgotten about.
Smart phones. Meteor came when people used browsers. Once the app model became prevalent, and users expected native integration, slow butt JavaScript in an HTML5 app on your 2012 phone CPU was a non starter.