But the bundle size 😕

Gmail already replaces all remote content with a Google-cached version.

Really? Just like that they gave up because they were too embarrassed to admit they didn't know how young flutter is?

Does this actually happen to people? I've had it happen maybe once or twice, and the longest it took for me to notice what was wrong was a few minutes.

They don't even bring this up with you before going straight to your manager? Sounds like they're the ones not communicating effectively about you not communicating effectively

It's probably just lots of different paths to the same package. For example, joi>lodash, lodash, ajv>lodash counts as 3 vulnerabilities even though it's only one package.

If this seems to be all that's out there, how do you find a good job?

Whatever works best for your code base, it's just something that I would avoid in general but if it's the cleanest option for you then go for it

@Fast-Nop Good. I never said that more JS = better website. I'm just saying that when you need to have more JS, lazy loading is useful.

According to https://stackoverflow.com/questions... it seems that most browsers store the data in compressed format. I would be surprised if they didn't. iOS Safari allows 50MB of cache per website before starting to clear stuff out. 50MB should be plenty.

Why do you think that piecing together small scripts into one (like with webpack) means they are all loaded in a waterfall, one after the other? They aren't. They can all be bundled together, or they can be loaded separately but concurrently.

Why not have the benefits of both? Load statically, but with scripts that make subsequent loads faster. This is what Next.js does, for example.

(continued)

- Client-side routing is not hard. You're just a history.pushState() away from updating the URL instantly. This is not "replicating native browser behavior"--this is native browser behavior.

- The discussion was about lazy loading or not lazy loading, and your answer is "I would rather just eliminate the bloat." Of course I would like to that too, but what if you want to add some widgets to your site without slowing down the rendering of the main content? Like a share widget? Or the part of your navigation bar that doesn't appear until the user clicks on it? Or a notification reader component? If those features are necessary, wouldn't you rather have them lazy loaded?

@Fast-Nop a lot of what you're saying is true for small applications or simple static sites. But when it comes to larger ones, the benefits of this extra JS start to become clear:

- GraphQL caching can be more effective than HTTP caching since it is more granular. For example, you could fetch relations on an object in one query and then run a completely different query fetching the same relations and the relations could be cached from the first query while other stuff is loaded from the server.

- If you have one app shell and load the content inside separately, you can cache the app shell to make subsequent page loads really fast. And AFAIK DOM modification is rarely slow, but feel free to find me an example.

- Dog slow? Never experienced that. After startup, which only takes a couple seconds, everything is pretty much instant.

(continued)

- If you do it improperly, yeah. But good SPAs will store the right data in the URL and use it to load the right content when loading the page. Just look at vue-router, react-router, reach-router, etc.

- Would you rather lazy load and get the most important stuff in 2 seconds but have the other stuff take an additional 2 seconds so a couple widgets may not be loaded, or take the full 4 seconds to load the page? This one sounds like a no-brainer to me.

- Ajaxing in static content does not render the browser cache useless. Properly built RESTful APIs will allow the browser to use its built-in cache, and GraphQL API results can be cached by the client using something like Apollo (which is not so lightweight) or URQL (which is, but has inferior caching).

- Client-side rendering != larger page load time. Bloated scripting is not caused by how you render your pages. There are many lightweight and well-built PWAs out there (like dev.to) as well as crappy static sites (dailymail.co.uk). Not everything is "pieced together" in a waterfall fashion.

- Bloat != CSR. Yes we should try to avoid bloating pages with unnecessary JS, but that doesn't mean that all JS is bad or all frontend frameworks are bad and we need to go back to the days of CGI.

- What? I can name one electron editor that is quite fast and far more fully featured that Notepad++. Yes it's VSCode.

You probably should have kept it like a normal function (id, auth). Maybe you can think about {id, auth} once you have lots of parameters or more than one optional parameter. But {id}, {auth}? Very unconventional.

Well you could use a framework like next.js to handle getting the same content rendered client side and server side, but I know not everyone does that. Also in the US you can get sued under the ADA if you have >=15 employees, just FYI.

Interesting that you think writing web apps as single page client rendered applications has no good use case and is only a result of "gross incompetence."

@Fast-Nop I agree that websites are accessible by default, but NoScript does break websites. It's no secret that JavaScript is required for most websites to work. But if you want to go back to the stone age of doing everything through forms (rather awful UX, due to constant page reloading and no client side rendering) you go right ahead.

@TheCommoner282 I can agree with not bothering to support users of an extension that is designed to break websites, but accessibility is pretty important. The number of people with various disabilities is not that low.

I like next.js: while it is capable of being much more than a SSG, it can do that quite well as long as no page uses getInitialProps and automatic static optimization is enabled.

Not sure what you're criticising here, looks completely fine

Maybe they want to keep URLs short so they look nicer when shared. Like Reddit's r/* and u/*

I've never seen single-letter API endpoints.

Pixel dungeon. Great roguelike, open source too

I agree--the lack of a standard way to do CSS in React results in lots of weird solutions. However, it's hard for me to go back to Vue because I love the simplicity and TypeScript-friendliness that JSX and React (respectively) provide. Vue has it's own kind of bloat--tons of features that allow you to compose components together in ways that violate "props down state up" and a huge API of mostly overcomplicated stuff that starts with "$".

@Al@ALIAKBERAAKASH working on a freelance project right now and I'm afraid that if I start on a side project too much of my time will go into it 😂

An API that manages authentication, spitting out session tokens, allowing you to store metadata in them, invalidating them, etc. so you don't have to hand roll it each time. Comes with a node sdk/module which caches tokens so you don't have to call the API every time.