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

Pika/web: Web Apps Without the Bundler

pikapkg.com

Post reply on HN
Print view View original

71–80 of 85 posts

Re: Pika/web: Web Apps Without the Bundler

#71

Post by ioulian »

segphault wrote: post #45
anonytrary wrote: post #34

Earlier quoted context omitted.

Sorry if this is a dumb question -- but that means you don't write ES6?

At this point, ES6 support is sufficiently widespread that I don't really have a problem using it natively. Major features like the const, classes, template literals, and async functions are all at least at 90% market penetration. I can get away with not supporting Internet Explorer, though I understand that it's not a trade-off that everybody is comfortable making.

I think (thought) also like you, just use the latest es6 code to do everything. The workflow is very fast, I can write my app 20%-50% faster than es5. I develop mostly on Chrome. My application/website works.

Then we test the website on different browsers (we all work with OSX), FireFox works (of course), Opera works (is Chromium), Safari, naah, it's the new IE. We do some minor fixes for Safari.

When we send it to the client, nothing works, of course the client uses IE so we need to rewrite a lot of stuff to make it work for "most" people. (I live in Belgium, there are "a lot of" IE users still. And even if IE is not widely used, our clients always use IE :( )

But wait, why rewrite our application, this can be fully automated! We run our code through babel/webpack. It automagically works everywhere!

Now I understand there is some performance penalty by using transpilers, but using them leaves our code mostly bugfree on all browsers and the client is happy.

The big problem with those fancy new features is browsersupport. If every browser followed specs correctly, we wouldn't need these tools. They make the job of the developer easy, the bosses wallet full and the client happy.

Re: Pika/web: Web Apps Without the Bundler

#72

Post by ownagefool »

curry-castaway wrote: post #64
intertextuality wrote: post #63

Earlier quoted context omitted.

It’s bad because this leads to a standard React project having over 2,000 dependencies. The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. What happens when a common package breaks? What happens if it gets hijacked and becomes a security vector th…

> The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. So the problem is the sheer number of dependencies? What is a reasonable upper limit? Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't see…

If you care about security, you should evaluate your dependencies.

This preferably means reading the code you're pulling in but it's unrealistic that we're going to read 2000 constantly changing dependencies for every deploy, so you need to establish trust some how.

Reputation of maintainers, dep CVE scanning, SAST and protective monitoring can all add additional assurance, but they won't protect you from a random hijacked npm module, and the more you include and from more people, the more likely you'll be affected by a zero day.

Having an entire community depend on tiny libraries that do nearly nothing exaperates this problem, and if you use something that almost nobody else does, you're unlikely to be saved by npm audit.

I don't use node daily driver, but I assume npm audit growing to include reputations and frameworks owning more of the dependency tree will help, but the users of the system also need to be considerate of the risks they take and the trust they place.

Re: Pika/web: Web Apps Without the Bundler

#73

Post by ownagefool »

jaabe wrote: post #68
curry-castaway wrote: post #62

Earlier quoted context omitted.

> One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. Just trying to understand, is this a bad thing? Someone else made an open source CLI spinner library which also uses other people's existing open source libraries. This saves a lot of time and gives developers many good options. Should Pika write and maintain…

It’s fine from a development perspective where the job is to make something work. It’s horrifying from an operations perspective where the job is to make sure everything works. Developers can afford to ignore looking into dependencies, operations need to make sure every dependency is functional and safe. If you write a piece of C# using the standard .Net library you can be fairly sure it’s safe and sound. If you writ…

I disagree that it's the job of a random ops person to ensure that a developers dependencies are sane.

Putting the onus on the developer to do a good job with regards to secure development practices is an essential part of a wider system.

Re: Pika/web: Web Apps Without the Bundler

#74

Post by z3t4 »

ownagefool wrote: post #72
curry-castaway wrote: post #64

Earlier quoted context omitted.

> The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. So the problem is the sheer number of dependencies? What is a reasonable upper limit? Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't see…

If you care about security, you should evaluate your dependencies. This preferably means reading the code you're pulling in but it's unrealistic that we're going to read 2000 constantly changing dependencies for every deploy, so you need to establish trust some how. Reputation of maintainers, dep CVE scanning, SAST and protective monitoring can all add additional assurance, but they won't protect you from a random hi…

I used to have all npm modules in source control (SCM), until npm introduced tree shaking. I'm using ZFS which have both de-duplication and compression, so I gain very little by tree shaking. I wish there was a way to disable tree shaking in npm, it's really the source of all evil. Anyway, I reviewed all code diffs after each npm update, very little changed, eg. it wasn't that much work. But it's now impossible as npm moves files around. I also deleted a lot of unnecessary files. About 90% of the content of each NPM packages are not needed.

Another reason why I stopped hosting dependencies in SCM is native modules. I wish Node.JS itself could become a platform layer so that I wouln't have to use these native modules.

Another thing is compile to JS, where a tiny change in the source might cause a huge diff in the generated JS.

Re: Pika/web: Web Apps Without the Bundler

#75

Post by jaabe »

ownagefool wrote: post #73
jaabe wrote: post #68

Earlier quoted context omitted.

It’s fine from a development perspective where the job is to make something work. It’s horrifying from an operations perspective where the job is to make sure everything works. Developers can afford to ignore looking into dependencies, operations need to make sure every dependency is functional and safe. If you write a piece of C# using the standard .Net library you can be fairly sure it’s safe and sound. If you writ…

I disagree that it's the job of a random ops person to ensure that a developers dependencies are sane. Putting the onus on the developer to do a good job with regards to secure development practices is an essential part of a wider system.

Oh I agree with that completely, but it’s very easy for developers to get away with shitty practices in a lot of shops.

Re: Pika/web: Web Apps Without the Bundler

#76

Post by omnimus »

rhizome wrote: post #61
s_y_n_t_a_x wrote: post #44

Earlier quoted context omitted.

That never really works out in practice when there's so many versions and then you're at the disposal of a public CDN, which can be the bottleneck, especially when it's critical code. Sure you can fallback to local copies, but that just means your app hung there for X amount of time, and the added complexity of adding fallback logic. Plus if you look at the size of these libraries, especially utility libraries (date-…

That never really works out in practice So glad this was such dominant practice and advice for the last 10 years. I wonder for how many of those influential practictioners have known it's more of a lazy include than clever cache reuse. Cargo culting writ larger than most.

It really depends. I think CDNs are still great if you are making smaller content website with few libs for things like lightboxes, sliders etc. It works out better than bundling. There is much less complexity without build process. Many websites don't need too much JS and devs tend to overengineer them nowdays.

If you are talking about products with lot of dependencies then of course but don't forget that bundler situation used to be completely different. There is not that much of difference (besides number of requests) between concating libs in sequence and loading libs in sequence.

Re: Pika/web: Web Apps Without the Bundler

#77

Post by pier25 »

jnbiche wrote: post #55
pier25 wrote: post #32

Earlier quoted context omitted.

I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.

> if we had a decent standard library and language to begin with. I use compile to JS languages when I can, but not sure what now you'd want for a frontend JavaScript standard library beyond what's available in ES6.

Optional static types, enums, data binding, reactive primitive, etc.

Yeah TS has many of those, but TS is not JS and it introduces new problems.

Re: Pika/web: Web Apps Without the Bundler

#78

Post by Can_Not »

treve wrote: post #6
est31 wrote: post #5

I'm not sure why this would be desirable. Sure, bundlers are slow, but that's what projects like pax [1] are for. Bundlers create one single file instead of the browser having to download your entire possibly huge dependency tree. Sure, with HTTP/2.0 and the upcoming QUIC or HTTP/3.0 overhead of this is minimized, but it's still not zero . There is also a cognitive overhead of having to configure the server to push a…

One major benefit is that for any given page in your application, you probably don't need the entire bundle. This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases. Just grabbing what you need can have significant benefits. I agree with the latency problem though, it would be nice to have a HTTP/2 or HTTP/3 server that has a basic understanding…

nuxtjs and webpack4 are actually automatically bundling dependencies so that libraries are automatically included only on pages that use them.

Re: Pika/web: Web Apps Without the Bundler

#79

Post by andreareina »

preommr wrote: post #50
pier25 wrote: post #32

Earlier quoted context omitted.

I've said before and I'll say it again, we wouldn't be in this mess if we had a decent standard library and language to begin with.

The way it seems to work with JS is that the community develops a bunch of stuff and the best rises to the top. This then influences the official language spec. ES6 basically made a lot of the popular tools redundant because it was heavily inspired by them. This is so incredibly important because the main development of the language is so poorly handled.

And despite adding arrow functions, async/await, modules etc. we still don't have sprintf and a Math.round that can specify the number of places to round to.

I think that modern javascript is pretty good and I'm grateful for the syntax extensions that have effected that, but the standard library is crying out for some love.

Re: Pika/web: Web Apps Without the Bundler

#80

Post by curry-castaway »

yardstick wrote: post #65
curry-castaway wrote: post #64

Earlier quoted context omitted.

> The real question is: do you -really- need an external lib with 20 dependencies just to show a freakin’ loading spinner? Remaking the wheel is bad but so is never making truly simple things yourself, or just not using them. So the problem is the sheer number of dependencies? What is a reasonable upper limit? Yes, javascript should continue to standardize commonly used features, but avoiding dependencies doesn't see…

From a security perspective, minimising dependencies is preferred. I have to review at least monthly all our dependencies for published vulnerabilities and new versions. We don’t allow automatic upgrading of packages/dependencies due to the risk of malicious code making it in (see https://www.npmjs.com/advisories for examples). Yeah there are companies that will help manage your vulnerability process but it’s still a…

> We don’t allow automatic upgrading of packages/dependencies due to the risk of malicious code

That's a good idea, how do you do that?

> you always need local archived copies of any dependencies you use.

Are you committing your dependencies? Or using a package manager with caching?

Post reply on HN