Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linen.dev: A 500 kb Slack alternative

linen.dev

Post reply on HN
Print view View original

111–120 of 219 posts

Re: Linen.dev: A 500 kb Slack alternative

#111

Post by Eduard »

capableweb wrote: post #80
Eduard wrote: post #57

Ah yes, highlight.js. One innocent import hljs from 'highlight.js'; pulls in over a Megabyte of hundreds of programming language syntax definitions. Do you really need Mathematica, "ISBL", and "GML" — or would a curated list of popular programming languages such as Python, Java, JavaScript, and HTML ("xml.js" ) be enough? This results in a massive reduction down to ~70 kilobytes. Even better: load this reduced size o…

Hightlight.js basically have two main modes of usage: The one you complain about is specifically about importing everything, because that's what the user wants in that case, importing it like that signals that that's what the user wants. Otherwise you can do the following: import hljs from 'highlight.js/lib/core'; import javascript from 'highlight.js/lib/languages/javascript'; hljs.registerLanguage('javascript', java…

But that's what my code does, albeit my code loads only on demand (plus can be easily improved to load any further language dynamically), whereas your code statically bundles everything into the main bundle (if not using proprietary Webpack chunk comments, which I see as antipatterns).

Re: Linen.dev: A 500 kb Slack alternative

#112

Post by thaumasiotes »

MuffinFlavored wrote: post #100
__ryan__ wrote: post #95

Earlier quoted context omitted.

A commuter typically takes a free public bus ride to work. The bus broke down this morning. The commuter had to go out of their way to take a different bus to get to work. Wouldn’t it have been better if they stayed and fixed the first bus?

I get the proverb but you have to admit that it's kind of a big deal that a tree-shaker bundler optimizer has a pretty big glaring known broken issue with it where it doesn't bundle. The bus gets fixed eventually. This doesn't (unless somebody fixes it).

I don't think the bus will get fixed unless somebody fixes it either.

Re: Linen.dev: A 500 kb Slack alternative

#113

Post by capableweb »

andrewxdiamond wrote: post #94
thex10 wrote: post #37

Not enough discussion here of the parts under "Our Optimization Strategies", which was the most interesting to me. Assorted reactions: > We found that react-icons had an issue that lead to everything being imported. This meant that we were including every single react-icon in our package whether we need it or not. Kudos to the Linen team for proactively finding this - I have a feeling tons of projects blindly trust t…

FYI there is a middle ground with the AWS SDK. If you don’t need the entire thing (you certainly do not), you can import product specific SDKs as standalone. Still quite a bit fatter than building your own HTTP client, but it’s an easy win if you already use the SDK. ex, an s3 only Java sdk: https://stackoverflow.com/questions/35591248/aws-sdk-for-s3-...

But also, if you're just making two API calls (the use case for Linen) which are using JSON, you can get both request making and json parsing pretty much out-of-the-box without doing anything, web browsers JS API ships with this by default, window.fetch and response.json(), no "building your own HTTP client" required :)

You need to have two calls at least, generate a signed URL and then actually uploading it. How many lines on the client would you guess that requires? My guess is less than 30, and you cover 100% of your use case without putting in any 3rd party code what so ever. Sounds like a solid win with few drawbacks.

Re: Linen.dev: A 500 kb Slack alternative

#114

Post by dns_snek »

thex10 wrote: post #37

Not enough discussion here of the parts under "Our Optimization Strategies", which was the most interesting to me. Assorted reactions: > We found that react-icons had an issue that lead to everything being imported. This meant that we were including every single react-icon in our package whether we need it or not. Kudos to the Linen team for proactively finding this - I have a feeling tons of projects blindly trust t…

> I have a feeling tons of projects blindly trust that tree-shaking their dependencies will "just work" even though for many libraries it won't!

Is there an easier way to verify this than, say, observing the final bundle size and looking inside the JS bundle? I'm not a frontend developer so this is outside my usual area of knowledge.

Re: Linen.dev: A 500 kb Slack alternative

#115

Post by niedzielski »

dns_snek wrote: post #114
thex10 wrote: post #37

Not enough discussion here of the parts under "Our Optimization Strategies", which was the most interesting to me. Assorted reactions: > We found that react-icons had an issue that lead to everything being imported. This meant that we were including every single react-icon in our package whether we need it or not. Kudos to the Linen team for proactively finding this - I have a feeling tons of projects blindly trust t…

> I have a feeling tons of projects blindly trust that tree-shaking their dependencies will "just work" even though for many libraries it won't! Is there an easier way to verify this than, say, observing the final bundle size and looking inside the JS bundle? I'm not a frontend developer so this is outside my usual area of knowledge.

I use source-map-explorer to see what's inside. Lighthouse Treemap provides a similar view.

[source-map-explorer]: https://github.com/danvk/source-map-explorer

[Lighthouse Treemap]: https://umaar.com/dev-tips/270-devtools-lighthouse-treemap/

Re: Linen.dev: A 500 kb Slack alternative

#116

Post by teddarific »

thex10 wrote: post #37

Not enough discussion here of the parts under "Our Optimization Strategies", which was the most interesting to me. Assorted reactions: > We found that react-icons had an issue that lead to everything being imported. This meant that we were including every single react-icon in our package whether we need it or not. Kudos to the Linen team for proactively finding this - I have a feeling tons of projects blindly trust t…

The same thing happened in a past job for me — we discovered we were included every single icon in FontAwesome. I wrote a codemod script to refactor how we were importing icons so it was treeshakeable. Cut load times from 10s to 2s — was glorious.

Re: Linen.dev: A 500 kb Slack alternative

#117

Post by endgame »

capableweb wrote: post #113
andrewxdiamond wrote: post #94

Earlier quoted context omitted.

FYI there is a middle ground with the AWS SDK. If you don’t need the entire thing (you certainly do not), you can import product specific SDKs as standalone. Still quite a bit fatter than building your own HTTP client, but it’s an easy win if you already use the SDK. ex, an s3 only Java sdk: https://stackoverflow.com/questions/35591248/aws-sdk-for-s3-...

But also, if you're just making two API calls (the use case for Linen) which are using JSON, you can get both request making and json parsing pretty much out-of-the-box without doing anything, web browsers JS API ships with this by default, window.fetch and response.json(), no "building your own HTTP client" required :) You need to have two calls at least, generate a signed URL and then actually uploading it. How man…

That's a good trick for JSON-based AWS APIs, but the S3 API is all XML AFAIK. I had to fix some signing bugs in the unofficial Haskell AWS SDK, and found it rather fiddly and a fair bit more than 30 LoC. Compared to standard AWS SigV4, S3 is also a special case in a few ways (request chunking, support for presigned PUTs with unsigned payloads, etc).

Re: Linen.dev: A 500 kb Slack alternative

#118

Post by capableweb »

endgame wrote: post #117
capableweb wrote: post #113

Earlier quoted context omitted.

But also, if you're just making two API calls (the use case for Linen) which are using JSON, you can get both request making and json parsing pretty much out-of-the-box without doing anything, web browsers JS API ships with this by default, window.fetch and response.json(), no "building your own HTTP client" required :) You need to have two calls at least, generate a signed URL and then actually uploading it. How man…

That's a good trick for JSON-based AWS APIs, but the S3 API is all XML AFAIK. I had to fix some signing bugs in the unofficial Haskell AWS SDK, and found it rather fiddly and a fair bit more than 30 LoC. Compared to standard AWS SigV4, S3 is also a special case in a few ways (request chunking, support for presigned PUTs with unsigned payloads, etc).

Ah, good point, but of course the browser also ships with APIs for dealing with XML, not doing so would be weird as HTML and the XML structure a pretty fundamental part of the web. See XMLHttpRequest, XMLSerializer and DOMParser.

Re: Linen.dev: A 500 kb Slack alternative

#119

Post by capableweb »

Eduard wrote: post #111
capableweb wrote: post #80

Earlier quoted context omitted.

Hightlight.js basically have two main modes of usage: The one you complain about is specifically about importing everything, because that's what the user wants in that case, importing it like that signals that that's what the user wants. Otherwise you can do the following: import hljs from 'highlight.js/lib/core'; import javascript from 'highlight.js/lib/languages/javascript'; hljs.registerLanguage('javascript', java…

But that's what my code does, albeit my code loads only on demand (plus can be easily improved to load any further language dynamically), whereas your code statically bundles everything into the main bundle (if not using proprietary Webpack chunk comments, which I see as antipatterns).

Sure, but it's far away from "pulls in over a Megabyte of hundreds of programming language syntax definitions" as you said:

    76K     node_modules/highlight.js/lib/core.js
    20K     node_modules/highlight.js/lib/languages/javascript.js
But I agree with you, that you probably want to only load it when really needed, especially if your total budget is 500kb which this would take a big part of it already.

Edit: I see now their budget was actually more than 1MB actually, as they for some reason only "really care" about gzip'd sizes... Then I wouldn't say it's so bad to just say fuck it and do it the easy way. Saves any latency introduced by lazy-loading it too.

Re: Linen.dev: A 500 kb Slack alternative

#120

Post by c-hendricks »

Eduard wrote: post #111
capableweb wrote: post #80

Earlier quoted context omitted.

Hightlight.js basically have two main modes of usage: The one you complain about is specifically about importing everything, because that's what the user wants in that case, importing it like that signals that that's what the user wants. Otherwise you can do the following: import hljs from 'highlight.js/lib/core'; import javascript from 'highlight.js/lib/languages/javascript'; hljs.registerLanguage('javascript', java…

But that's what my code does, albeit my code loads only on demand (plus can be easily improved to load any further language dynamically), whereas your code statically bundles everything into the main bundle (if not using proprietary Webpack chunk comments, which I see as antipatterns).

Dynamic imports aren't unique to webpack, they're a standard feature.

The two different variants written are six of one half a dozen of the other. There's nothing stopping you from writing the imports + register in one file and dynamically importing it in a dom loaded event in another.

Post reply on HN