Project X – Like Tailwind for JavaScript | Hacker News Reader

Project X – Like Tailwind for JavaScript

github.com

83 pointsrmason21 comments

I'm working on a similar project called Remake [0].

It lets you add a CRUD editing interface with automatic data syncing/saving to any element. All that's required are a few HTML data-* attributes [1].

It takes a different approach than most frameworks: it doesn't separate the data from the presentation layer. This makes it so it can make a lot of assumptions about the structure of the application and the saved data based on the hierarchy of the HTML elements.

Also, since it's based on a traditional, server-rendered stack, you don't need to include the front-end JS library 90% of the time. If the current user can't edit the page, Remake simply isn't loaded, which cuts down on the page weight dramatically.

It basically lets you have all of the benefits of a traditional, server-rendered web app, while also giving you inline data editing capabilities for free.

I just finished recording some tutorials for it 1 week ago [2]. I'd love to have some people try it out :)

[0] https://remaketheweb.com/

[1] https://remaketheweb.com/data-attributes-api/

[2] https://tutorials.remaketheweb.com/

That’s an interesting idea, essentially to get the usefulness of Vue single file components but without involving a build process.

I would expect development and debugging could be somewhat easier since you’ve just got annotated HTML (no build pipeline), but I would also expect that runtime performance would be worse (or at least it would be harder to write an implementation as performant).

I could see this being a very nice option for simple sites, where you just have a bit of interesting UI on the page (menus, forms) and want to write it declaratively, but going to a full-on SPA framework is overkill.

VueJs fit that description really well at version 1. I love Vue, but I feel it has moved much in the direction of a full all or nothing framework these days, especially with the mental hoops they’ve gone through in v3 (setup + hooks) to take the paradigm and make it typescript friendly.

I like that Vue 3 is sticking to their API though even with the new stuff. React hooks felt like we were doing something wrong while Vue just feels like a natural progressive enhancement.

It’s also cool that you can use the normal Vue lifecycle stuff with the composition api. Episode 129 of full stack radio podcast has a lot of good info in it!

I use Vue (2) in this way, and Angular when I need a full fledged SPA (heavy) environment.

This is like intercooler.js[1], but more general, I see. While you can only take my react+immer+typescript stack from my dead cold hands, I like attempts on simplifying the status quo and different perspectives (instead of css & html in js, we get js & css in html).

[1]: https://intercoolerjs.org/

intercooler reminds of Stimulus JS looking over its docs. Not exact parallels, but its a great idea, especially if you just need that jQuery style interactivity

https://stimulusjs.org/

You might be interested in mavo (https://mavo.io/): it also lets you produce interactive pages by adding some keywords to HTML, but the primitives offer higher level functionality (e.g. a few attributes get you a full WYSIWYG editor)

I like this trend that I am seeing, even if Project X isn't for me, the fact that both Vue.js and Svelte have kicked off a newer perspective of strong compile time (or bundle time, if you prefer) optimizations, due in large part to their realized benefits (and why I think they're both rising in developer mindshare popularity, even though I think Vue's install base is many factors time bigger then svelte's, svelte is the baseline now for performance metrics to be measured against from what I can tell)

This has inspired me to work on in my spare time a Web Components compiler for optimized at compile time custom elements (and other features) kind of like Stencil JS, but I want to use Babel as to not alienate those who don't use typescript. I'm also considering what the compilation target should be (currently I'm toying with Lit HTML, but I've looked at Incremental DOM too, or forking my own thing based on it, because Google's lack of communication around it makes me nervous.)

This is what I feel like the bundler promise is ultimately the most logical extension of, highly optimized compiled components that frameworks/libraries can hook into (the compiler, I mean) to highly optimize their builds without the developer having to worry and fret about whether their build is setup properly to be the most performant

This is my opinion of course, and its entirely possible this started long before Vue or svelte even existed, but I'm excited to see more of this now.

I feel like its what Handlebars was suppose to be, but I don't know if it ever lived up to that hype, especially performance wise (in the browser. I know its popular server side, where the performance concerns are a bit different).

EDIT: Just a heads up, it appears they're using a bit of eval (view `new Function([...args])`[0] under the hood. I'm personally not a fan of this . Too many security related edge cases not to be considered risky. I'm open to the fact I could be wrong though.

[0] https://github.com/calebporzio/project-x/blob/master/src/uti...

You really don't need a compiler to be fast. A fast architecture is really the first order concern. lit-html generally beats Svelte and Vue at performance, but has no compiler.

Seems like a reinvention of Knockoutjs.

That's okay!

Looks cool. I'm currently fooling around with Eleventy (similar to Jekyll but for JS) and was thinking about including Stimulus and Turbolinks, similar to this stack here: https://github.com/scottwater/eleventy-origin

How would Project X fit into that? Could it replace Stimulus and Turbolinks?

Project x would replace stimulus. But you would still use turbolinks. It supports it out of the box.

So it's Stimulus alternative for those who prefer the Vue syntax, smart.

How do I v-for in this?

So when is using this a good idea? And when would you not use this? It looks interesting. But maybe not.

I'd say don't use it until there are more than two contributors. The last thing you want to do is rely on something like this without support. Tightly binding dynamic logic in your HTML like this would be something I'd see as a "critical path dependency" for an application.

I've seen a TON of projects with huge teams of contributors go belly-up just because they fell out of style, after a ton of people had implemented it because "cool!" This is almost a trope in the JS/ECMA world.

If you're looking to make something informal then all of what I just said goes out the window, but usually even my hobby stuff has a potential support cycle/lifespan.

Is it only me, or does this remind you on a very early AngularJS.

I was also thinking that most of these things were already doable in AngularJS.

It's also very similar to how I used to use backbone.

Compared to how I work now it feels outdated, having said that, though with static site generators being a growth market, maybe markup decorators like this could be a way to get more custom UI behaviour into said sites without the kinds of massive complexity in the editing process that usually result in 'enterprise' like content management

I wish more protects like this used processing instructions. They're intended for exactly these kinds of use cases.

Reply on news.ycombinator.com