Comment by neovive | Hacker News Reader

Comment by neovive | Hacker News Reader

I've been using Buefy for about a year for two projects and it provides a nice set of drop-in components for projects within the niche of Bulma/VueJS users. The project is very well designed and documented and easy to customize. Note: The original author, @rafaelpimpa, recently transferred maintenance over to jtommy.

If you happen to fall within the aforementioned niche, Buefy is definitely worth a try. The Form components alone are worth their weight in kilobytes and greatly simplify your templates. The components, props, and events use logical naming conventions and the examples in the docs work out of the box and are easy to customize.

I love how readable this is as opposed to a series of nested divs and classes:

    <b-field label="Email"
        type="is-danger"
        message="This email is invalid">
        <b-input type="email"
            value="john@"
            maxlength="30">
        </b-input>
    </b-field>

If you only need one or two components you can import where needed:

    import { Table } from 'buefy/dist/components/table'
    import { Input } from 'buefy/dist/components/input'

I have been building websites for most of my adult life. And I use Vue for some projects. But I have no clue what this is about. What is a 'b-field'?

It's a vue component that is part of the framework. In this case it renders an input field that is customizable by passing props into the component.

In the original link, the Buefy project describes itself as "Lightweight UI components for Vue.js based on Bulma". It seems like b-field is an example of such a component [0]. Looking at the documentation, this seems to be the case. If you're familiar with components in Vuejs, this is just a component in Vuejs.

[0] https://buefy.org/documentation/field

And why is it "is-danger" and has a message. Is this string based programming? What are we doing?

This could probably be a future improvement for buefy, but it's just implementing the conventions Bulma uses. is-danger is a color modifier https://bulma.io/documentation/modifiers/syntax/

Seems very clear to me. What is the alternative?

That's the million dollar question.

What's the alternative to declaring our UI using pseudo-html elements and string-matching on css class proxies from the currently-in-favour CSS framework which sits on top of the javascript framework of the moment which, after going through several transpilation steps to become plain old javascript, then sits on the client manipulating a shadow-DOM, to finally render plain old html?

No idea. Hopefully some nice solutions will arise from other languages which compile to wasm - I would expect all the major players to be looking at coming up with something to that effect now that the world seems ready for Silverlight 2.0 and everyone loves writing frameworks.[1]

Until then, any solution will unfortunately probably involve adding yet another level to the house of cards, maybe one which compiles down to buefy or the Vue bootstrap components..

[1] yeah, I see the irony in that it's just another stack which will probably be just as insane in many ways, but at least it will compile in less than 5mins.

This is what modern front-end UI programming looks like now. It's... weird.

Buefy uses the class naming conventions established in Bulma. Since it's Vue, you can bind the values to data and change the classes dynamically to quickly toggle the error state and messages.

It is a component meant to represent a field. `b-` is just the namespace for Buefy components.

If you've been using Vue for some time this should be obvious...

What is a 'field'?

I get the feeling that Buefy's approach is to use custom elements instead of native elements? So something like an <input> element becomes some <b-field> thing?

I am sceptical if that is a good thing. I would not want to swap out all regular html for some fantasy elements of a library.

A grouping of form controls and labels that together represent a piece of form data is a field. True, HTML doesn't have any exact `field` tag, but the notion of a field has always been there, see `<fieldset>`. Working with custom "fantasy" elements is quite typical of modern frontend development, and very productive to work in.

Nevertheless, in the more restricted question of using custom elements to replace CSS classes, you may have a point; many libraries that try to do this typically end up with a far more restricted use case since a custom components library is less open to extension than CSS classes, and custom components authors often fail to anticipate ways in which CSS frameworks are used. (e.g. using a CSS class with a standard HTML tag, and then, using a CSS class with a custom component)

    Working with custom "fantasy" elements is quite
    typical of modern frontend development

And eating too much fat is quite typical of the modern diet. I prefer to eat healthy nontheless.

This isn't quite analogous. Developers use custom components because they encapsulate a common structure in Web apps not provided out of the box in vanilla HTML.

To use a more accurate analogy, they are akin to building an ALU with the use of a an adder (a fantasy component abstracting away the NAND gates) rather than completely in NAND gates.

Reply on news.ycombinator.com