Slack using React Dev Build in Production
twitter.com
twitter.com
I can't really imagine what type of benefit they believe they're getting. Your error tracking system does re-assemble the stack from a out-of-band delivered sourcemap, even in prod, even with multiple versions deployed simultaneously... right? Like any decent error tracking system such as Rollbar or Sentry will do out of the box. Tell me you didn't build your own and can't even unwind a production error trace.
I don't understand how deploying React's dev build would help anyway... Do they regularly run into bugs where they need to step into React code?
Are there examples for HTML5 apps that manage to have great performance? Are there inherent limits?
We have a huge Android market here, but they're all phones with very low storage and slow 3G connections, so the default way to get an 'app' out is a HTML5 progressive web app. And the companies here work hard to make things run fast and smooth on slow devices.
When I have 20-50 KB/s stable 3g, browsing the web is a bit slow, but most sites work pretty good. Also messenger aren't a problem.
But working below 20 KB/s is a pain.
After coming to Australia, everyone here treats +4mb websites as normal which was a real mind twister for me. Thankfully pagespeed has always been my concern regardless of network speeds due to my 'conditioning' years ago.
By dumping binaries, creating emacsclient, but mostly by waiting 25+ years for fast computers w/SSDs to come along?
I love emacs, but slow startup was a problem for multiple decades, IMO.
There's been articles on HN specifically about how slow VS Code is, particularly the one about rendering cursor blinking, and of course anything running on Electron will never compete work the likes of vim, &c.
However, as Electron apps go, I've found it noticeably faster and less resource intensive than any others. Slack in particular is comparatively terrible, as was Atom in the past (people have said it's improved but I've not felt the need to try it again recently)
So what I would like to know is wtf everyone is doing in these apps to create this CRAZY amount of resource hogging they keep bitching about? Or are they rockin chomebooks? Seriously? I want to know where all of this nonsense is coming from?
You're running a music player, a text editor (or IDE), and a chat client. I would expect reasonably that would use less memory. One point you could make is that even native application alternatives, ones that don't use Electron, would be bloated and I would have to agree. Visual Studio .NET is pretty darn slow/cumbersome itself.
That's not to say that there aren't decisions to reconsider about code size, resource formats, etc. but I think it's easy to forget how much more behaviour has moved into our default baseline assumptions.
In my very limited experience, this makes programming anything several times more complicated. Writing a document editor? Difficult. Writing a networked, multi-user document editor? As difficult as the last thing but with asynchrony and lots of new failure modes.
Microsoft Word, with a multi-page complicated document, is using 200mb.
Just because we _have_ the resources to allow applications to bloat doesn't mean we should be alright with it. Its a similar argument to electric versus ICE cars; just because gas is cheap doesn't mean we shouldn't support EVs. EVs are fundamentally better for the future.
If we focus on performance optimizing the apps we use, it opens up a wide range of new computing hardware. You make fun of chromebooks, but imagine how much more interesting your work would be if you could use a machine with that performance. Battery life would be substantially higher. The cost of the machine would be substantially lower. The only reason most people need massive performance beasts is because we've pushed abstraction hell and bad engineering practices, so all of our tools suck.
Docker is another offender in recent times. Its great if you're on Linux, but few people are. So on OSX, we need to run a VM, so there goes another gig of memory.
Your bar should not be, "Well, I don't see a slowdown." Many people still develop software on computers with only 8GB total RAM. Throw in a browser and one or two more applications and you're getting close to exhausting that.
Eventually you are going to exhaust your memory resources; using software with poor performance constraints is (in my opinion) inherently antagonistic to a development machine. That's not to say I'm against desktop JavaScript/HTML5 apps categorically, I just think they need much better optimization.
No idea why, it's only joining one team with under 20 people and ~5 channels.
But I agree, Atom and Slack are really useful to if they consume another 250mb of ram because "It's not optimal", let them use it.
I also run two java processes with 1gb predefined (well probably I could fine tune them to use 512mb). and one angular/cli which accounts for 800mb. plus my database which got 500mb aswell.
spotify on mac used way more than 500mb memory, the last time I used it and also had an extreme amount of i/o pressure. atom actually did use at least 500 mb memory as well, with just the c# plugin.
Its incompetence on behalf of Slack and Github, not the tech itself.
Deleted comment
React introduces a layer of indirection into your rendering. Rather than saying "draw a profile pic" and then "a profile pic means these DOM manipulations", with React you add another layer: "hey, oracle, what does the whole page look like this now, and what DOM manipulations should we do to get there?"
It's like having an AI look at your code and decide how it should actually run. Very cool, very futuristic. Not convinced it's a practical decision.
Putting something like that in your app means for a much more complex debugging process. It always seemed like the React team was trying to solve a really really hard problem in order to avoid solving an easier problem a bunch of times. Which is classic programmer thinking, and generally a good strategy. But I wonder if it's good for us in the end.
The principle you could adopt, which would make React a bad choice, is something like "solve one hard problem if it means you can avoid solving a lot of easy problems, but only if you're solving those actual small problems in bulk. If you're only solving a subset of them, you're going to cause problems for yourself later."
Which DOM queries and manipulations make sense? Is React actually answering that question for you, or is it mashing the buttons until it works?
Giving their engineers the option to peer into react whenever they like is probably getting them more pure slack bugs fixed. That is not to say I think the current slack resource use is acceptable. There should be a middle ground where most users aren't wasting resources all of the time.
In addition to the speed difference, there's a significant payload size difference: something like 1.5+MB for the dev build, vs 70kb for the production build, last time I checked.
And about the size: if the JS file is cached properly, downloading 1.5mb once doesn't seem like a huge issue, especially for something like Slack where only desktops use the web client (most mobiles probably download the Slack app). I don't know if this was the case here though.
Btw, Discord also surpassed Slack in traffic on SimilarWeb.
I would gladly pay them.
Discord's specifics aside, it blows my mind that people use any off-site SAAS for internal communications, including Slack. The database set contains so much critical information, including infrastructure passwords, private SSL and SSH certs, etc. Employees will send anything and everything over the company's chat client. Even if you trust the company's employees and general security, the fact remains that your uploaded attachments typically have a public URL not requiring authentication to download.
Someone spreading FUD?
Everything with Discord feels like a super mature well develoved product.
I've used Discord for gaming related purposes on another computer, but it didn't feel... "better" to me. Sluggish at times, but in understandably large rooms with lots of traffic.
I'm mainly curious in your statement as to how Discord performs compared to Slack, and if better, how they achieve "better".
With Slack you need for every chat a new login/password and 100 clicks for sign-up, skip tutorial and email-verification, WTH why? Getting users into Discord is one single click. With Discord you have one login and you can have different names per server.
And Slacks admin pages are just a confusing pile of mess, my .vimrc is light-weight compared. Slack is so overrated and people just use it because everybody does.
Discord has never been sluggish for me.
However, both are timewasters.
Sidenote, I use it because the integrations take a burden off of me. Ie, my CI might not have integrations for Discord. My CI has plugins, and do those have integrations for Discord too? Etcetc. Being the most popular is not always just due to "we use it because everyone does".
Personally, I dislike how expensive Slack is. I'm not sure if I prefer Slack over Discord or not, but even if I preferred Discord, I'd still choose Slack for the integrations that I don't have to write myself.
Yes and if not there is a Slack-compatible API, check Discord's API doc.
Just try Discord, takes one minute and will know yourself if you like it. It's not a behemoth like Slack.
This is where they started and you can also use the product for everything else than gaming.
And if you mean the dark theme you can change this to a bright innocent I-am-serious-engineer Slack theme.
Data from Chrome Inspector's network tab:
Slack Discord
Req. 93 103
Transf.22.4MB 5.2MB
Finish 39.19s 6.48s
DomCL. 6.53s 4.01s
Load 21.70s 4.16s
- automatic backlog resumption
- server stored pageable backlog
- continuous presence (you don't disappear from the channel when you leave, you're just marked as away)
- authentication built into the spec rather than implemented using a "services" layer
- general upgrades to what is allowed in the chat, such as long pastes, inline images, and file uploads
If you haven't tried Matrix yet (the best client is probably Riot at https://riot.im/ ), I encourage you to give it a try. It's essentially next generation IRC.
Is it that hard to debug the production build?
My thoughts are that there must be a lot of low hanging fruit, judging by the way a chat app can rev up my maxed out Macbook Pro.
You know what? I'm happy with IRC. weechat uses maybe 28MBs and runs stellar.
Maybe you should just consider that the tools you are using simply are flawed and move to something proven instead?
So yeah, it is a little more complicated than just "Slack needed 32GB" - in fact, and thankfully, even my whole stack fits comfortably. It's what I upgraded from that it didn't work well on.
Slack Enterprise is expensive for a messaging service, and one of their main selling points is support and reliability. When a huge customer reports a breaking bug they need to resolve it ASAP, turnaround time is probably the number-one priority.
Companies will always take the easy path because capitalism. It's up to us (native toolkit devs) to make the easier path better.
Is there a platform out there that has no X server?
XQuartz on Mac OS X sucks (maybe it's just Inkscape though) and I'm not sure if there's decent Windows support.
Qt might work, though.
I've used it, it wasn't bad at all but it definitely clashed visually (not that electron apps don't.)
>I'm not sure if there's decent Windows support.
Cygwin with X11 is one of the first things I install on my work machine whenever I get a new job. It can't do fancy GTK stuff super well but most of the apps I use work great.