61–70 of 98 posts
If you're doing something more complex than this in your app then quit whining about browsers not being convenient for you to abuse. The users don't want your crap any more than browser implementers do.
Vue > React
Earlier quoted context omitted.
I'm saddened to see that almost a decade after Ember's release, the front-end world still insists rolling their own (terrible) reimplementation of it. I would've expected that a decade later we would've settled on an Ember-like framework for the front-end and moved beyond constructing URLs and parsing JSON responses manually but apparently not.
The rest of the world moved on from Ember because Ember is a pain in the ass to use.
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 the people I work with seems to have no standard for structure (every project has its own), reinvents the wheel all the time (using Axios and building the URLs manually with string concatenation for example), etc. Most of the stuff they do (and redo) from scratch seems like something that would be handled by Ember to begin with.
So what's so bad? I feel like (as an outsider - feel free to prove me wrong) Ember is fine for most purposes, and edge-cases where React or alternative approaches do provide a benefit can be used ad-hoc without having to use it for your entire application.
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…
Black boxes with tons of magic are great if you need to do exactly that one thing that creators had in mind. When you need it to work a little bit different you're usually either just out of luck, or the added flexibility makes whole api very complex (and usually buggy, as it goes hand in hand). It's just super hard to make things very high-level and simple, while still flexible enough.
Having a number of simpler functionalities that you're free to compose any way you like is for me preferred approach anytime. Most of the things that you mention can be solved with fairly simple wrapper libs doing just one thing (tracking state of connection, tracking errors, batching requests, etc.). Perhaps not in a perfectly reusable way, but good enough to allow easy recycling from project to project, and it's way easier to use and debug and adjust than if we had one huge built-in service object to handle it all.
> UI frameworks (at this point, React has won) Isn't this like someone in 2011 saying "UI frameworks (at this point, jQuery has won)"? I think things like Svelte and other up and coming UI frameworks are still being developed because we all recognize that React is not the ultimate UI Framework. Perhaps we will never get there, but surely we can do better than where we are at.
I still cringe when I see questions on StackOverflow where they ask "how can I XYZ with jQuery" where XYZ is something that has absolutely nothing to do with the DOM.
I didn't see "show download progress" as one of the needs. I remember seeing complaints about the fetch api not exposing an easy way to do that. Issues like this one seem to remain: https://github.com/AnthumChris/fetch-progress-indicators/iss...
I didn't see "show download progress" as one of the needs. I remember seeing complaints about the fetch api not exposing an easy way to do that. Issues like this one seem to remain: https://github.com/AnthumChris/fetch-progress-indicators/iss...
This is possible with the Fetch API actually. You can get the chunked up contents of the request as they arrive. This link has a good example: https://javascript.info/fetch-progress
If your UI is complicated enough to worry about most things on this list, maybe simplify your UI?
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.
This applies to everything in the browser honestly. Why can’t I bind a variable to the DOM natively? I want the variable X to match the value of and vice versa without having to set up a bunch of listeners and hope they don’t go in a loop.
seriously though, why not just write a simple wrapper around event listeners + maybe some proxy magic and get the semantics you prefer? or find a library that does that, i'm sure there's a bunch out there
Earlier quoted context omitted.
I started my current project using SWR and then switched to react-query after dealing with some annoyances with SWR. Overall react-query is impressive for data fetching, but I’ve run into issues with mutations and cache invalidation.
Hey! SWR author here. Mind sharing the annoyances and how I can make it better for you?