71–80 of 98 posts
If your UI is complicated enough to worry about most things on this list, maybe simplify your UI?
Valid point, if your app is a todo list manager. There's a level of complexity in the domain logic where all these things mentioned by the author become pain points. That complexity can't be reduced by "simplify your UI" statements.
Ember.js seems to check off a lot of those boxes, if you are willing to use a complete solution and not do the 'pick and choose' method of react and friends. While it has lost popularity in the last few years, it has been moving forward technically. It has become leaner and meaner. Really learning the "Ember Way" to do things can reduce some of the friction the author mentions. Ember Data can allow you to talk to mul…
(I'm not familiar with Ember.js)
This post feels like a uninformed and undifferentiated rant against "things are too complex". Let's start with the first paragraph: What does the JavaScript fetch API have to do with data management? How can you compare the fetch() API with Swagger (an API documentation format) with Protobuf (a serialisation format)? That doesn't even make sense. Second paragraph: "The UI should automatically update everywhere the da…
(I'm not familiar with Ember.js)
This post feels like a uninformed and undifferentiated rant against "things are too complex". Let's start with the first paragraph: What does the JavaScript fetch API have to do with data management? How can you compare the fetch() API with Swagger (an API documentation format) with Protobuf (a serialisation format)? That doesn't even make sense. Second paragraph: "The UI should automatically update everywhere the da…
How does Ember.js compare to Angular? Both seems to aim to be a complete solution / batteries included. (I'm not familiar with Ember.js)
Earlier quoted context omitted.
The rest of the world moved on from Ember because Ember is a pain in the ass to use.
As someone who's not a front-end developer, but who works near them and sees the (React) code they produce and their general productivity (or lack thereof), what's so bad about it? To me as a backend developer just reading Ember's docs, it seems like Ember provides most of the conveniences I take for granted in a backend web framework such as Django, Rails or Laravel. On the other hand, the front-end code I see from…
Earlier quoted context omitted.
I think the post is a bit unfortunate in its wording and this seems to have sent you off on a wrong track. From how I read it, this the post is not specifically about JS and a discussion of the specific technologies mentioned but rather concerned with the following very general situation: 1. There's a user sitting in front of a browser. 2. There's a backend server providing data and points of interaction with that da…
I think parent is completely missing the point. In my opinion the way it should be is that in the backend you export a typed function like "getTasks(filter: Filter): Tasks And in the frontend component you should be able to use it immediately and it would be correctly typed without having to duplicate types or anything. And if function is not complete yet it will not render the component before. This should be instea…
Why? REST doesn't have anything to say about this. You can design your application however you prefer, and publish input and output specs however you prefer, without tailoring your application to the HTTP layer.
This post feels like a uninformed and undifferentiated rant against "things are too complex". Let's start with the first paragraph: What does the JavaScript fetch API have to do with data management? How can you compare the fetch() API with Swagger (an API documentation format) with Protobuf (a serialisation format)? That doesn't even make sense. Second paragraph: "The UI should automatically update everywhere the da…
What this person said! ^ almost all of the mentioned issues have solutions out their but the author is jumping around the stack with no sense of true purpose. How does graphql impact your SPA updating views, it doesn’t..
Earlier quoted context omitted.
I think the post is a bit unfortunate in its wording and this seems to have sent you off on a wrong track. From how I read it, this the post is not specifically about JS and a discussion of the specific technologies mentioned but rather concerned with the following very general situation: 1. There's a user sitting in front of a browser. 2. There's a backend server providing data and points of interaction with that da…
I think parent is completely missing the point. In my opinion the way it should be is that in the backend you export a typed function like "getTasks(filter: Filter): Tasks And in the frontend component you should be able to use it immediately and it would be correctly typed without having to duplicate types or anything. And if function is not complete yet it will not render the component before. This should be instea…
This post feels like a uninformed and undifferentiated rant against "things are too complex". Let's start with the first paragraph: What does the JavaScript fetch API have to do with data management? How can you compare the fetch() API with Swagger (an API documentation format) with Protobuf (a serialisation format)? That doesn't even make sense. Second paragraph: "The UI should automatically update everywhere the da…
I think the post is a bit unfortunate in its wording and this seems to have sent you off on a wrong track. From how I read it, this the post is not specifically about JS and a discussion of the specific technologies mentioned but rather concerned with the following very general situation: 1. There's a user sitting in front of a browser. 2. There's a backend server providing data and points of interaction with that da…
Earlier quoted context omitted.
I think parent is completely missing the point. In my opinion the way it should be is that in the backend you export a typed function like "getTasks(filter: Filter): Tasks And in the frontend component you should be able to use it immediately and it would be correctly typed without having to duplicate types or anything. And if function is not complete yet it will not render the component before. This should be instea…
> instead of REST Why? REST doesn't have anything to say about this. You can design your application however you prefer, and publish input and output specs however you prefer, without tailoring your application to the HTTP layer.
It could work with REST underneath or REST being auto generated based off your function names, but you shouldn't have to deal with that. And REST in general would probably not be optimal to transfer the data here.