Hacker News Reader

Comment by peterkelly | Hacker News Reader

You don't even need a damn framework.

I learnt the basic web technologies 20 years ago, and have kept mostly up to date with the subset of improvements to browser APIs that are actually important. This knowledge has served me well, and I don't have to re-learn the latest thing every year because something new is trendy.

The less unnecessary complexity between me and the browser, the better. I can spend my time being productive instead of wasting it learning about how to migrate from version 15 to version 16 of some overhyped framework.

View on HN

I've seen a lot of bad React websites that are slow because the developer was a half-assed React developer or just learning and didn't notice on his 4Ghz i9 machine that something is making rerender every component on scroll event or something

This. When someone needs to solve some particular problem, they reach for the most convenient npm package called "react-something-something" that works great until, a month later, there is more data or complexity in the application that the performance issues introduced by the component become apparent.

Funny, another commenter below made that exact comment - "I love how fast I am able to deliver features by just bringing in a few libraries"

This does not mean that you’re bringing in dead weight or security black holes. The statement remains true if you bring just a couple libraries like Material UI, an SDK or two for key API interactions, and maybe a state management lib if the situation calls for it.

The other day I pruned unused dependencies from a medium sized app we’re about to launch and package.json was not much more than the above.

Bringing in Material-UI actually feels like a good example - the last time I used that framework, it felt fairly large. I guess it was ~3mb as of their last publish (0.20?). Now, it's large enough that they've split it into ~4/5 packages, although it appears you would want to take the @material-ui/core to get started? This is 6mb alone, and the other pieces that are just material bring in another couple of megabytes, and then there are additional dependencies. So, a fairly sizable starting point, and then you've got your own code, and then you've got whatever additional components you want to pull in (more widgets, a drag-n-drop, etc), and suddenly you're looking at what the GPs were saying. The package file is probably still pretty clean, but pop open node_modules or the network tab when the page is loading. Even a small number of dependencies pretty quickly bloats up size

Material UI core is around ~100kb bundled.

If you’re doing some kind of code-splitting or SSR you can probably serve a fraction of that.

Unless you’re developing for a very particular use case like embedded, I fail to see how the raw size of the package is any concern given how much MaterialUI brings to the table in terms of interaction design capabilities and dev speed.

Regarding your comment on the network tab, that’s really got me scratching my head… I’ve done a lot of profiling of React apps and when they’re bundled you don’t see a network call explosion because you’re just downloading a couple of JS bundles at worst… I can guarantee that a React app with the dependencies you describe would have anywhere between good and excellent network performance in 3G and above.

Or, that npm package

a) is deprecated

b) has security issue, with no patch

c) web framework has major changes, making it challenging to upgrade, so you need help from framework maintainers for upgrading

Any code that you have not written yourself has pontential to break. It's same for every programming language.

And, that npm package brings 200 MB of dependencies, even though it actually requires only 10 files total.

Same story here. I have around 50ish web applications that I run for customers. There is hardly any time spent on maintenance and is recurring revenue for me, and I can spend most of my work time on creating new business opportunities. Some of the web applications are from 2005 and display real-time information about available items in their inventory, real time customer support chat, real time sensor data from oil rigs offshore.

> You don't even need a damn framework.

thats a very classic problem. some people like frameworks some dont. some poeple like ORMs some dont.

at this point im done fighting these battles - whatever job market requires im just gonna use.

1. Browser APIs have subtle differences, or don't always exist in every browser you need to support (e.g, https://caniuse.com/)

2. You'll need at least a transpiler (if writing anything above ES5) and polyfills to solve #1, and if you're diving that far into the JavaScript tooling chain (bundler + babel), might as well choose to use a framework.

I have a hard time learning react, because the 'language' used is so divorced from the concepts or actions of what it is the code does... If that makes sense. So I memorize some language chunks in react that does something and this is supposed to be 'programming?' How can I ever know what this stuff does? And why I'm supposed to use it. I just get frustrated with all these frameworks.

Unless you’re using machine code, it’s all frameworks on frameworks.

Well, language != framework.

But you do have a point - the browser itself can sort of be considered a framework (some might say runtime), in the sense that it's a layer of abstraction. Certainly an imperfect one, but an extremely mature and stable framework with excellent backwards compatibility.

Reply on news.ycombinator.com