401–408 of 408 posts
Earlier quoted context omitted.
Jesus NO at no.2 Rewrites are ALL about the schema. Look, over time, your initial requirements will change. The initial schema will 100% not be what is ideal. On a long enough time scale EVERYTHING becomes many to many. I've found any rewrite of software without restructuring the schema has always been a waste of time.
Yep, I've never seen a system that was a) so bad that it requires rewriting and b) had a great schema that rewrite could be done on top of. Usually a quick glance at the schema will shine a bright light on top of all sorts of badness - denormalizations, excessive metadata-driven-ness etc. Rewriting code on top of crud like that would be epensive, and result in a lot of ugly code, which would need to be rewritten agai…
They make little sense as soon as a project is completed, even if you rewrite, the software hasn't had time to point you in a direction, a 'nice' rewrite of the same wrong solution is just as useless as a bad implementation of the wrong solution.
They may make sense after a product has matured, since the actual scope of the software will be more defined. The 'correct' schema is starting to reveal itself, but usually it's rare that business wise it's worth rewriting at this stage, adding features is the better choice.
They definitely make sense once a product is fully matured, starting to gather legacy issues - since fighting around all the cruft and incorrect schema restrictions is wasting more time than redesigning it from ground up using the existing implementation as the guide.
Earlier quoted context omitted.
The performance and resource usage of slack both on the desktop and in a browser indicates that “front end code” is not their strength.
Creating a web app with a multi-billion dollar valuation indicates it is their strength. Who cares about a little superfluous memory usage compared to that.
Slack is successful because of marketing, not technical superiority.
I worked at a small company that used Google Talk for office chat, and us developers complained because it was difficult to have a group conversation with. We started using Discord (we were familiar with it and liked the dark theme) and it caught on and we were quite productive with it. Our business types saw it and decided to "formalize" it, so they picked Slack and rolled it out company wide. Most people actually preferred Discord, but the business types preferred Slack (probably mostly because of marketing), and now we're all using Slack.
Now, Slack also didn't royally screw up as it scaled up (outages were rare and transparently reported), which is a credit to the developers and PR people. That being said, just because something is successful doesn't mean it's good; it could be, but that's tangential to the topic at hand.
How about a native client? I think it's safe to assume that Slack has the resources for this.
The fact that nobody's gone out on their own and built a native client means at least one of four things is true: 1. Slack is too restrictive, and its API is too poorly supported for anyone to create a port. I find this unlikely, given that the API is extensively documented and that an Emacs port already exists, but maybe there are problems I'm not aware of. 2. Good native ports are actually a lot harder to build and…
If I'm going to put my resources into building a client for something, it's not going to be based on some closed source backed that could change at any time, it's going to be based on something open and forkable (worst case scenario, I can just maintain my own backend).
Slack bills itself as a complete solution, not a piece to a larger puzzle, so third party clients and plugins will always take the backseat. Who is going to try to build a serious competitor when they can't really rely on the backend staying consistent?
Building a decent frontend isn't particularly difficult. It's not trivial, but it has been done. For example, Pidgin, while a little ugly (I prefer "functional"), works well and has been around for years. I used weechat and irssi for IRC chat before we switched away from IRC, and it worked really well (didn't see pictures, but I think that's more a feature than anything, and links were more than sufficient).
The problem is that business types prefer hosted, "batteries included" solutions, and those types tend to not be very friendly with third party add-ons. If I end up being able to use Matrix/Riot, maybe I'll try my hand at a native, cross platform client. But until then, I'm not going to throw my effort toward something that can change at any moment.
Earlier quoted context omitted.
That was me! Component level fetch !== no Redux, that's not what I described; using Redux does not _mean_ you have to use one of the many libraries built to wrestle asynchronous fetching into Redux. I've got nothing against any of them, I've used almost every major one in my jobs over the last few years. But I (and the person who replied to me) both seem to feel the same way, that in many cases just fetching in React…
I have preferred this method myself when dealing with simple calls (calls that need no further external information). jumping through 7 files just to find the API request that gets shipped is slightly insane. but how do you put the result back in the store? how about displaying a default failure screen?
The API request is in the file that represents the point at which the API request is made by the user (previously in a loader component or, now, using a hook, in future using suspense), so I would say it involves jumping through 0 files, as opposed to several if I move it to redux (the dispatch occurs at the UI trigger point, then I have to drill through several other layers of abstraction). In practice there's normally some facade in front of the API to prefill values and also to make it easier to mock for testing, but if anything that just makes it simpler as the facade acts as a reference.
> how about displaying a default failure screen?
failure && {failure.message}
> but how do you put the result back in the store?
dispatch({ type: "foo", data: "bar"})
I was so hoping that they had dropped Electron.. but nope. At least they’re focusing on performance, but the achilles heel will always be there. That said, as much as I dislike Electron, Microsoft has done a fine job with VSCode, so there are ways to do Electron “better”, even if the “best” Electron apps are still mediocre compared to native apps
> Microsoft has done a fine job with VSCode Microsoft has done a fine job with VS Code considering it is built on Electron , but it's a freaking text editor ffs! It has basically zero need for a UI. If this were 1990 and there were no cross-platform filesystem, i/o, network, async, etc. APIs available for native applications, it might make sense. But a text editor is basically the very simplest cross-platform UI you…
But no doubt, Sublime Text exists in a different (native) world of speed altogether (and I do love Sublime Text)
Earlier quoted context omitted.
My only request for redux-starter-kit is more documentation on usage with TypeScript (and perhaps deeper integration with ts-not sure how well the current package integrates with a ts codebase).
RSK should be fairly usable with TS. As I understand it, it can't be as magically strict as `typesafe-actions` is or infer quite as much automatically, because of how we're generating the action types from the reducer names as strings. But, it should definitely generate correctly typed action creator functions for you. And yes, agree on needing more documentation: https://github.com/reduxjs/redux-starter-kit/issues/5…