Size of node_modules folder when installing the top 100 packages
size-of-npm.netlify.com
size-of-npm.netlify.com
Another huge benefit is that it simplifies you application code immensely. Your store and models are simply vanilla JS since Mithril doesn't have reactivity, observables, etc. Mithril will simply redraw all the vdom whenever a user event happens or when its router/http client do something. You can also call m.redraw() if you need the UI to update if you for example receive something from a web socket.
Obviously with this approach the performance cannot be as good as something like Svelte or Inferno, but it's significantly faster than React.
https://krausest.github.io/js-framework-benchmark/current.ht...
Personally I use it with JSX since I can't stand the hyperscript notation.
It's certainly not for everyone and all use cases but I think it's totally valid for a good portion of front end work if you can handle a double edged knife.
> that’s going to be painful when I want to filter a live search result page with more than a just few results.
I'm using it right now with a gallery of about 2000 items with filtering and search. No problem on an i5 desktop.
There needs to be concerns beyond pure speed and package size to dictate tools. Sometimes real world practical constraints must be considered
As for hiring I agree somewhat but anyone with a couple of years of front end experience should be able to pick it up in a matter of hours.
It sounds like you're saying that the way out of tech debt is to install more 3rd-party packages and/or hire more people, I hope you meant something else.
I use and recommend React at work because of the hiring thing, but for my own personal projects I stick with Mithril. With JSX it's not hard to switch back and forth between the two, at least with TypeScript there to tell me when I accidentally use HTML in my React JSX, e.g. the class attribute when React wants the className property. (With Mithril you use attributes that map exactly to HTML attributes)
i.e. one of the fastest consumer machines around. I wonder how much the web would be better if more people targetted a $300 laptop instead of a $3000 one. Or probably a $30 Android instead of a $1000 iPhone.
Hmmm would be interesting to do the benchmarks on different machines and see if you are right.
My only annoyance is that I've grown accustomed to making micro components with React, Inferno, and Mithril on the same file. Stuff like buttons and such. With Svelte (and Vue when using SFC) you need to create each component in its own file which becomes tedious for more complicated views.
[0]: https://create-react-app.dev/docs/making-a-progressive-web-a...
Then again, it seems people that develop these monstrosities are never the ones to maintain them.
There is a lot of blame to go around in this industry--it isn't just individual engineers acting out of ignorance or resume building.
I rather have a standard baseline to be up to speed and don't get bothered with this on each app.
Is this a Freudian slip? The amount of bugs in "modern web apps" seems rather huge indeed.
> I rather have a standard baseline to be up to speed
To me, the baseline for any kind of website or web app is, you know, HTML. When authoring static HTML or rendering it dynamically on the server, I'm up to speed instantly.
As of the cache size, I simply do not care. E.g. installing gnome, kde or openoffice requires to download hundreds of megabytes of binaries and everyone is okay with that. If you’re not familiar with these packages, they draw large ui controls, copy files and render bad tables. Not much different from a regular node project.
I don't think they ever got "left-padded" as they say.
Not that your overall point is wrong (most definitely, it is not in my opinion). I think the reality is that this is what actually drives the concern of the size of the node_modules folder, because deep down, all frontend developers know that so many of these packages have never been vetted, probably won't be vetted, and there is alot of duplicate functionality in many of these dependencies, or the libs themselves just aren't designed to be efficiently consumed. Other communities (like Python) have been having community level conversations around the size of their respective package folders & the validity of reproducing their builds, security etc for awhile now, and the governing bodies for those respective communities (and/or language) are working hard to reduce redundancy among packages & encourage cooperation (the PSF, for instance, has funded directly or helped facilitate funding for many keystone packages, like flask, IIRC. It is also my understanding that Microsoft has been doing (and is expanding its efforts to) do this via the https://dotnetfoundation.org/ among other efforts)
Sadly, I have not seen the same effort within the NPM/frontend focused ecosystem. Though, maybe the open JS foundation will take off: https://openjsf.org/projects/
Come on. Gnome and KDE are not equivalent of a node project, they're an equivalent of a browser (or at least browser chrome). And OpenOffice does quite a lot more than pretty much any Node project out there.
I mean, making chrome is not a big issue if you’ve got yourself webkit/blink/presto/etc. it is a regular program, pretty stupid one, if you think its ui out of box.
(That said, I think the people working on that have since been laid off or quit, so not sure what the current status is.)
EDIT: Silly me, I was looking at the audit number. It did seem ridiculously big.
literally? (if not, what's the actual figure?)
Whenever I start working with a framework I create my own starter kit which I reuse, I don't start from scratch on every project.
Will try to relearn again. Hopefully, the new versions are not that bad.
They are marginally better but still the user experience is horrendous. I think a large part of it is opting for massive nested configuration objects instead of something more similar to Gulp. You have to keep mentally parsing the object to figure out exactly what webpack is going to do exactly.
Or, even worse, are these docs, tests, and other stuff that have no place in the checkout of a recursively-resolved dependency?
Bingo. I've seen an embarassing number of what should be dev-dependencies pulled in transitively for some packages, as well.
Nothing like seeing some four layer deep dependency pulling gulp-cli because somebody didn't know what they were doing...
If all libraries are tiny then a set of “the best” libraries can evolve over time through the preferences of individual people.
Obviously this doesn’t work so well for finding libraries or having them work great together.
What could be useful is some concept of a "metalibrary" or "platform", a la the "rust platform" and "haskell platform" efforts - a sensible aggregate of libraries with compatible versions that work together and cover most of the common things you need - not as an inflexible monolith that you have to do big-bang upgrades of, but as a starting point that you can then customize as needed. Almost like a Linux distribution. But keeping the ability to upgrade one small piece without touching the others is really important.
.net I'm less familiar with, but I've certainly heard of projects being stuck on older versions of it, and again for a lot of tasks it tends to be a case of there just not being a library available at all.
That, combined with the ability to target .netstandard and a much more clear line of sight for what is compatiable with those standards, have made this, to me, a non issue.
It was historically though, very hard to deal with for large apps.
Microsoft hasn't move much out of the core C#/.NET libaries, rather they made it easier to interop the SDKs/runtimes. The actual libaries themselves haven't changed much in respect to this issue.
I'm sure the wheel will come around again.
edit no, the one with the evolution of robots and such
Tree shaking still isn't that great or widely available, so separate packages mean you can do this manually.
This sounds like an opinion based on the state of web development a decade ago.
In 2020 on the other hand the Google Closure Compiler has been a mature project for years, and even projects not explicitly focused on dead code elimination (bundlers like Webpack and Rollup) do a decently thorough job of cutting out unnecessary code with the right plugins.
But for real. Terraform is like 300mb for the binary, easily the largest single binary on my system. (And it’s golang)
Why?
That's a difference of more than 6 orders of magnitude :')
So you think a kernel is large and has to be counted in the total, even if a browser also requires a kernel.
Yet you think web apps don't need libraries, so you are not even counting the browser and its dozens of libraries?
His knowledge is limited to an extremely tiny domain of programming, and he regularly berates people for not following his philosophy. Meanwhile, it took him eight years to make The Witness. What did he build with his eight years time? A first person puzzle game with essentially no interactive physics, no character animations, and no NPC's to interact with. (I actually enjoy The Witness, fwiw.) The vast majority of developers do not have the budget to spend eight years on a single title, and wouldn't want to even if they did.
The most notable thing about Jonathan Blow is how condescending he is.
He's passionate and smart and interesting - and writing him off like that, I think, is not justified.
The thing about Jonathan Blow is that for a lot of people, he's the first graphics-focused outspoken programmer that they run into and so they think he's some form of singular genius. He isn't.
Is the average weight high? Or are there a couple behemoths?
For the server, I’m using hapijs. It fits my style a whole lot better than Express.
For the client side, it’s entirely just raw css and js. Absolutely no frameworks.
Eventually I’m going to have to use a few third party tools when I get around to adding square or braintree integration but that’s a way off.
It’s an absolute joy to just sit down and get stuff done. Today I was able to move from getting the basic node server running in under an hour to building out a couple pages and writing some content. Added some css styling like back in the old days and without needing less or sass. Still only about as good as you’d expect from one day of work but it was so easy to do.
I didn’t spend hours setting up tooling, researching which extra npm modules were needed, etc. There’s no React garbage, no Everest of overhead just to get to a point where I could work.
It's one of those modern magic frameworks that when you need to step outside the simple hello world example app you spend most of your days chasing buggy behaviours mentioned on unresolved month old github issues.
When this happens, usually your only choice and suggestion is update to the beta version of some core library, which breaks tons of other packages that haven't yet been updated to the new rewritten API, rinse and repeat.
Never again.
To be honest, NextJS wasn't worse than the rest of the JS ecosystem, the problem is systemic.
My initial thought was a widespread security patch or something.
> On my Macbook Pro the folder containing Xcode is larger than 13 GB. And to get the .NET application running at work I had to install over 20 GB of applications and dependencies. So, relativity speaking, JavaScript is still ok.
Personally, I completely agree with that. A single gigabyte of hard drive space on a developer's machine or a modern server is not terribly wasteful.
EDIT: I know he says "the application at work" and it's just an offhand comment, but you shouldn't read too much into it. Unless it means "I had to install Windows 10 on a VM" because it uses classic framework libraries that don't work with Mono or something.
NET::ERR_CERT_AUTHORITY_INVALID is the listed error
Of course, that’s made difficult by the fact it’s against our own collective interest. At this rate even the worst developers will be able to be employed managing some gargantuan and wholly unnecessary software stock.
Not to knock on you to much, but this culture of bloat reminds about the classic “Evolution of a Programmer” joke:
https://www.smart-jokes.org/programmer-evolution.html
Let’s all try and be like the Guru Hacker, not the Seasoned Professional!
I don't think the path forward is to bash all websites that use a common npm library.
I’m with you though, I don’t think the bashing is necessary, in either direction. It just breeds contempt.
Vanilla JS! 0 Dependencies!
Let the 1995 revolution begin!
While, yes, they can choose to just not use such tools or libraries, it also presents a fun barrier for learning.
It's also perfectly fine to not give a damn about either of the above.
Your point still stands of course!
I remember downloading a 150mb JDK overnight on dial-up for Java 2.
Everyone uses local nation sites, some of which even use languages spoken by no more than 5 million people world wide.
We aren’t the target market for the “first world” website, and that’s fine as the first world isn’t the target for any of our digital goods either.
It just feels a bit patronizing when this discussion is brought up, as no one is dying to use a random American made website. Facebook and Google are exceptions, not the rule.
Over the new year, I was in an area where all power and phone communications were first limited, then cut completely. I was able to send/receive 30 megabytes of data in about 8 hours.
I understand there's always competing constraints and priorities, but shouldn't we be striving to do the best possible job?
Hopefully things like Starlink will improve the situation a lot.