Hacker News Reader

Comment by brandoncordell | Hacker News Reader

So happy jQuery is gone! I'm also glad they're moving towards including more utility classes (this started in v4) but I've spent the last year with TailwindCSS and man is it nice. I just bought TailwindUI as well for the component aspect. I think it's going to take some convincing to move back to Bootstrap.

I'll definitely give it a shot on a small project though.

View on HN

When I first heard that jQuery is gone, it made me hope that Bootstrap could work directly with Vue without needing to use BootstrapVue.

But then I realized that it's probably still doing direct DOM manipulation, which is what makes it incompatible with Vue I think?

It's definitely going to make it a lot easier than it is now. It's really not bad working with external libraries in Vue. I imagine the way that Bootstrap does it's Javascript will leave you doing a lot inside of Vue's lifecycle hooks (beforeMount, mount, etc).

You're probably better off with BootstrapVue (or one of the React equivalents) because they're doing dom manipulation...

The libraries based on bootstrap should just be rendering components with matching classnames etc.

Direct DOM manipulations are not necessarily incompatible with Vue or React.

I'm not sure in this specific case, but I'm saying this in general because there seems to be a common misconception. People jump through the craziest, smallest, highest, flaming-ist hoops to get everything to render through Vue/React. Using virtual scrollers that aren't fit for purpose. Trying to get d3/plotly running on the VDOM. Etc etc.

You can always just pop a DOM ref out and let something else take control of it; easy peasy.

While it’s possible to use direct DOM manipulation via refs, IMO this defeats the purpose of using a reactive lib like Vue or React. If you are using a lib like jQuery/D3 with Vue/React, you are basically just using Vue/React to render the initial state of the DOM.

If your entire site's React/Vue implementation is solely serving up DOM elements to other libraries perhaps.

Frequently it's the case though where like 99.99%(hyperbole) of the site is handled by React/Vue and you just need a few specific components to be controlled by an external lib. Heck, anything wrapping a canvas based lib is pretty much doing this.. Tons of component libs do this. It's very "web component" like to let something control a slice of the DOM anyway.

I agree that sometimes its okay to give another lib control of the DOM (D3 probably falls in this category). However in the context of the parent comment where haberman is wondering if Bootstrap could work directly with Vue (which it could) I still hold that this is missing the point. In this case Vue would be nothing but a glorified templating engine. I would rather only use the boostrap styles while writing my own logic with Vue's reactivity model.

I can attest to this. I had the hardest time getting a vue wrapped google maps library to work, until I decided enough is enough and used the native google maps sdk. Perfectly doable and can save you a ton of time. If possible use a vue/react compatible library, but don't do it at all cost.

Can the interactive / JS parts of Bootstrap be reimplemented in a way 'native' to Vue or React? I'm probably naive but I can't imagine the JS parts are that complicated (things like collapses, menus, changing classes, etc).

Yes they can. Libraries like reactstrap and sveltestrap do just this.

You don't need to use BootstrapVue at all. For things like Modals just add the appropiate divs and change classes in the same order.

> TailwindCSS

How big is the CSS per page? Do you have to do any per-page optimisations? I like the concept but when I look into it, the full library appears large and having to e.g. run a CSS optimiser to bring in only the CSS classes used on every page is added complexity.

Generally I'm aiming to inline all the CSS into the page with less than 50KB of CSS when it's uncompressed. Bootstrap was always too large for this.

The full Tailwind without PurgeCSS is definitely huge (about 2MB uncompressed), but the more recent versions have PurgeCSS integrated directly, without needed to set it up separately.

The suggested use case is building one stylesheet that covers all your pages, with the idea that a site with a reasonably consistent design is likely to use only a very narrow sliver of the available classes. In practice I've found my styles when using Tailwind to hover around the 30KB mark uncompressed (single digit KBs actually going over the wire).

It's definitely added complexity, but it's not too bad imo.

30KB is still absolutely massive in terms of raw CSS

I don't see that as an issue. It will get cached and it's the same difference as having a medium sized, well compressed image. Almost inconsequential when you consider you'll never have to write any more lines of CSS.

Don't get so hung up on the size of the CSS when it's relatively tiny compared to images.

> Don't get so hung up on the size of the CSS when it's relatively tiny compared to images.

It's an issue when you have to make the user wait for the top of the page to render (so they might leave if it takes too long to see anything), especially on mobile on a slow connection.

That's why APM for example makes you inline the CSS at the top of the HTML file and won't allow more than 75KB of uncompressed CSS.

CSS might be smaller than most images but it's critical to the initial page experience whereas image loading can be delayed.

Good job you can combine approaches by inlining the functional classes you've used and serving the remainder normally then.

Like I say though, that's prior to gzip/Brotli. It's usually < 10KB actually being downloaded.

As another poster said with PurgeCSS it isn't bad at all. I'm lucky enough that all my users are internal and we're a Chrome only business so a lot of that cruft can be left out and the speed of the page isn't a large concern.

Prototyping with VueJS and Tailwind on the frontend with Rails on the backend is pretty much my ideal workflow. It's so quick to get a feature done I still surprise myself.

Can you please explain to a non-web-dev - why such a fuss about dropping jQuery? AFAIK it is just a small utility lib.

Its an extra (30kb) dependency for many projects that can solve the same problems using vanilla javascript with the same amount of friction

And many projects/people don't care about not supporting anything but the latest chrome, so yes, for them it's a legacy.

Most if not all the modern frameworks/projects use Babel to compile modern Javascript to the es5 standard from 2009. I guess 11 years of browser backwards compatibility are enough, or should we downgrade and support IE 6 ?

its not about js compatibility it is more about platform / browser specific glitches

Unfortunately vanilla JS is much less readable. JQuery function names make your intent very clear and chaining them is elegant. Also, very minor, but the "magic" (syntactic sugar) provided by `$()` compared to `document.querySelectorAll()` et al. makes using JQuery seem much more frictionless, especially since you know if you're using it, all the functions will work on whatever you selected and can also take HTML strings, etc.

One thing vanilla JS does have going for it though is performance. I profiled a script of mine and rewrote all the bottlenecks using native JS and it's undoubtedly faster.

religion mostly :)

JavaScript didn't work well across all browsers a decade or more ago, and jQuery made it easier to write JavaScript without resorting to browser-specific hacks. It also added some elegant features.

JavaScript has improved so much you don't need jQuery anymore.

Got recommended this twice in the past week. How does it change your workflow? Also is it as quick to get something started as bootstrap?

Reply on news.ycombinator.com