4 ms·

I've been using the likes of PrimeVue (https://primevue.org/ https://primevue.org/), PrimeReact (https://primereact.org/ https://primereact.org/) and PrimeNG (h

I've been using the likes of PrimeVue (https://primevue.org/ https://primevue.org/), PrimeReact (https://primereact.org/ https://primereact.org/) and PrimeNG (https://primeng.org/ https://primeng.org/) because they attempt to give you a library of components that work well out of the box and have a similar API across multiple technologies: Vue, React and Angular, respectively. I feel like at some point I'll probably make a project with just jQuery and possibly jQuery UI for the sake of it: while what's there doesn't seem too flashy, it would probably work just fine for most web based CRUD needs. I might end up rediscovering up close why people moved to Vue/React/Angular in droves instead of jQuery, but honestly something that you just drop in and that works has a lot of appeal. No complex toolchains, no configuring a bunch of plugins and registering them with the app, no endless abstractions for state management and things about render loops to keep in mind, just a silly JS import and writing some schlocky code that still sorta works. I like to consider the UI of Kanboard as a good example. It's minimalist, but works great for what it is: https://kanboard.org/ https://kanboard.org/

diob 2y ago
I started working in a project using prime and the exposed api is just frustrating compared to MUI, at least for me. Feels like they take the idealistic view of things versus pragmatism.
CharlieDigital 2y ago
> ...might end up rediscovering up close why people moved to Vue/React/Angular in droves instead of jQuery Vue, React, and Angular are fundamentally MVC in disguise: a "controller" modifies some state (model) and on the next render cycle, the "view" is updated by the library/framework to draw the change. (Simplifying here to ignore details of the implementation like vDOM, components, etc.) Not so with jQuery. You draw the change directly. You can write a framework on top of jQuery to achieve something similar where a model/state gets updated -> detect the change -> jQuery to draw the change. (That might be interesting or perhaps something like this already exists.) In other words, in Vue, React, and Angular, you are discouraged from doing direct DOM manipulation; you always modify some state from which the framework applies the DOM changes and in jQuery, it's the opposite: you directly manipulate the DOM in reaction to some action. So the reason why people moved is that an MVC-aligned paradigm is ultimately more productive and a better abstraction than directly manipulating trees of rectangles.
- kijin 2y ago
  Very true. But it doesn't matter if you're building a typical website instead of an SPA, and the only "state" you care about are little things like whether a checkbox is checked. Even in that case, many of the fancy effects people used jQuery for can now be implemented in pure CSS. These days, when I'm working on a simple blog or landing page, I find that I don't even use much JS at all. It's HTML and CSS, not full-blown SPA frameworks, that have gradually replaced jQuery for me.
  - CharlieDigital 2y ago
    Yes, agree. I do think that using either web components or Lit offers a nice layer of encapsulation and reuse as well as some convenience. There are a lot of options nowadays.
- spinningslate 2y ago
  indeed, good description. Noting that vue etc. are MVC in the browser, with (typically) calls to json http endpoints on the back end to read/write data. JQuery was born in a time of server-side rendering (SSR) where, in essence, MVC happened in the back end and it shipped html to the browser. In that model, the browser is essentially a terminal that renders output formed in the back end. JQuery was one of the early libraries to promote behaviour in the browser instead of "browser as terminal". It feels like there's bit of a swing back to the SSR model, e.g. with the growing popularity of htmx [0] though there are still many strong proponents of the MVC-in-browser approach. [0] https://htmx.org/ https://htmx.org/
  - CharlieDigital 2y ago
    > JQuery was born in a time of server-side rendering (SSR) where, in essence, MVC happened in the back end and it shipped html to the browser. Yeah, I think this is nail on the head. It was also a time of smaller apps and smaller teams so it was easier to manage the state even with direct mutation on the DOM tree. With bigger and more complex apps, you needed multiple teams and now it's not possible to really effectively track the state of the DOM if multiple teams could be manipulating it from different components. You can see that shadow DOM and web components is one way of thinking about this problem. Separating the render from the state (a la Vue, React, Angular et al) is another.
audessuscest 2y ago
seems awesome. FYI got a react error screen when trying calendar with time, not sure exactly how sorry
ulrischa 2y ago
I totally agree. I miss something simple and complete for UI things as Jquery UI
deleted 2y ago
[deleted]
emursebrian 2y ago
jQuery UI was a step up from the time, but it was still painful to do basic things compared to now. I much preferred developing front-end for apps deployed on the web in Flex and later Silverlight. I moved to Knockout and then Vue. I have used Angular and React, I just prefer Vue. I was doing consulting work up until a few years ago and it still showed up on a lot of projects, and the integrations were usually full of buggy spaghetti code. You can build low-quality apps in any framework, but the more full-featured frameworks at least to try to set the developers up for success.
anonymous344 2y ago
was the primevue the one that you need to purchase some blocks or something in many cases ?

diob 2y ago

I started working in a project using prime and the exposed api is just frustrating compared to MUI, at least for me. Feels like they take the idealistic view of things versus pragmatism.

CharlieDigital 2y ago

> ...might end up rediscovering up close why people moved to Vue/React/Angular in droves instead of jQuery Vue, React, and Angular are fundamentally MVC in disguise: a "controller" modifies some state (model) and on the next render cycle, the "view" is updated by the library/framework to draw the change. (Simplifying here to ignore details of the implementation like vDOM, components, etc.) Not so with jQuery. You draw the change directly. You can write a framework on top of jQuery to achieve something similar where a model/state gets updated -> detect the change -> jQuery to draw the change. (That might be interesting or perhaps something like this already exists.) In other words, in Vue, React, and Angular, you are discouraged from doing direct DOM manipulation; you always modify some state from which the framework applies the DOM changes and in jQuery, it's the opposite: you directly manipulate the DOM in reaction to some action. So the reason why people moved is that an MVC-aligned paradigm is ultimately more productive and a better abstraction than directly manipulating trees of rectangles.

kijin 2y ago
Very true. But it doesn't matter if you're building a typical website instead of an SPA, and the only "state" you care about are little things like whether a checkbox is checked. Even in that case, many of the fancy effects people used jQuery for can now be implemented in pure CSS. These days, when I'm working on a simple blog or landing page, I find that I don't even use much JS at all. It's HTML and CSS, not full-blown SPA frameworks, that have gradually replaced jQuery for me.
- CharlieDigital 2y ago
  Yes, agree. I do think that using either web components or Lit offers a nice layer of encapsulation and reuse as well as some convenience. There are a lot of options nowadays.
spinningslate 2y ago
indeed, good description. Noting that vue etc. are MVC in the browser, with (typically) calls to json http endpoints on the back end to read/write data. JQuery was born in a time of server-side rendering (SSR) where, in essence, MVC happened in the back end and it shipped html to the browser. In that model, the browser is essentially a terminal that renders output formed in the back end. JQuery was one of the early libraries to promote behaviour in the browser instead of "browser as terminal". It feels like there's bit of a swing back to the SSR model, e.g. with the growing popularity of htmx [0] though there are still many strong proponents of the MVC-in-browser approach. [0] https://htmx.org/ https://htmx.org/
- CharlieDigital 2y ago
  > JQuery was born in a time of server-side rendering (SSR) where, in essence, MVC happened in the back end and it shipped html to the browser. Yeah, I think this is nail on the head. It was also a time of smaller apps and smaller teams so it was easier to manage the state even with direct mutation on the DOM tree. With bigger and more complex apps, you needed multiple teams and now it's not possible to really effectively track the state of the DOM if multiple teams could be manipulating it from different components. You can see that shadow DOM and web components is one way of thinking about this problem. Separating the render from the state (a la Vue, React, Angular et al) is another.

audessuscest 2y ago

seems awesome. FYI got a react error screen when trying calendar with time, not sure exactly how sorry

ulrischa 2y ago

I totally agree. I miss something simple and complete for UI things as Jquery UI

deleted 2y ago

[deleted]

emursebrian 2y ago

jQuery UI was a step up from the time, but it was still painful to do basic things compared to now. I much preferred developing front-end for apps deployed on the web in Flex and later Silverlight. I moved to Knockout and then Vue. I have used Angular and React, I just prefer Vue. I was doing consulting work up until a few years ago and it still showed up on a lot of projects, and the integrations were usually full of buggy spaghetti code. You can build low-quality apps in any framework, but the more full-featured frameworks at least to try to set the developers up for success.

anonymous344 2y ago

was the primevue the one that you need to purchase some blocks or something in many cases ?