To whom it may concern...

[sintaxi]

I recently spent time evaluating the current landscape of Front-End developer tools and SSGs/Frameworks and I have come to the following conclusions...

Utility-first CSS is a major workflow paradigm shift

I've been playing with TailwindCSS (& purchased the TailwindUI tool kit). It turned out to be nothing what I expected.

• Tailwind is a low level tool that can be used to implement any web interface. Tailwind is effectively an alternative to SASS/Less rather than an alternative to Bootstrap.

• The Tailwind documentation is exceptional. The CSS/DSL is very good & the tooling is decent (for the most part). Tailwind has a strong team so I suspect the issues I have with the tools will eventually get worked out. Regardless, Tailwind is production viable right now and is likely to only get better moving forward.

For those who don't like the Tailwind approach, I'm not here to convince you otherwise. You should use the tools that best compliment your skillset choose the technology that has the downsides you are most willing to accept based on your values as a technologist.

ESBUILD and SWC are amazing - and they fit the Harp architecture perfectly

Those who are familiar with Harp know its a JIT in the true sense - in that the no compilation happens until a request is made to the Harp server (html/css/js). This is why Harp starts up so quickly and feels so fast. Harp can process Jade/EJS/Markdown/SASS/etc very quickly.

Unfortunately Harp never got a proper implementation of JavaScript bundling because the overhead was too high to build it with a JIT architecture - UNTIL NOW!. ESBUILD and SWC are now just as snappy to process as any of the other supported pre-processers in Harp - which in my view means resurrecting Harp is seriously worth considering. Perhaps I'm not alone.

The current state of Harp

I've been using Harp lately to play around with Tailwind and even though Harp is quite outdated it absolutely slays at building things with Tailwind. Templating truly is a strength of Harp and it shines in this case. For example, with zero-modification I can CMD-C a component from tailwindui.com and paste it directly into a file named _navbar.ejs then in my harp project then call partial("_navbar") from any other template. Later I can effortlessly add some variables to the EJS template <%= myvar %> or when It time to hand-bomb a component I simply use .jade to take advantage of the terse syntax. Then I use .md to add some content and style it by adding a content.sass file. Even without any updates to Harp its already a huge win - but I see so much potential in what this could become - and the question is would it be worth the work?

Harp's deficiencies.

To put it mildly, Harp is fairly outdated at this point which makes its flaws apparent compared to modern alternatives. However although the deficiencies are significant I think most would be nearly trivial to address. Harps architecture is solid and IMHO would not need to change at all. As I see it, these are the following deficiencies in Harp...

1. Proper JS Bundling - Harp need to handle JavaScript better and I think ESBUILD is the ticket to having a flawless implementation. Should certainly add .cjs, .jsx support and if it comes without much additional effort it should also add .ts, and .tsx support.

2. Shared Templates Client/Server - Harp could benefit with a template that can be called by both server Side by the SSG and Client Side using react .jsx seems like a natural fit for this use case and I think with this feature Harp would be a great tool for projects that are a SSG/SPA cross-over.

3. Embrace package.json - It appears as though package.json is now the home base of every project. Harp should be designed and documented to be used in this way - especially if it has first-class bundling baked in as dependency management will be a requirement.

4. New CLI - Harps CLI needs a refresh. This should be straight forward and easy to do. harp . to start the server and harp . somebuilddir to compile the assets. Easy enough.

5. Logging - Logging in harp is pretty much completely absent which is sad. Harp should provide useful logs for both when serving and compiling your site. Again, this should be an easy win.

6. Cut the Fat task complete! 🎉 - Everyone loves lightweight tools so Harp should leave what its not good at too other tools. (I have actually already started on this work - and last night cut down terraform from 53MB down to 7.7MB by removing pre-processors that are not very popular or and removing libraries that have negligible benefit.

Thats it for now. If you have thoughts on the past, present, or future of Harp I would love to hear what you have to say. Tell me, Is Harp worth resurrecting?

[ameesme]

Over the past years I have switched bundlers many times, but for simple web projects and prototypes Harp is still my go-to. It's integration of pre-processors and webserver is just so nice to work with. I've never stopped using it (and was actually updating it today, which is why I'm replying here).

I agree with most of the points you're making and could definitely see Harp become my primary "platform" to build more sophisticated web-applications on when JS-bundling is implemented, but it's simplicity is also the main reason why it stuck in my workflow for over 5 years.

Thanks so much for your work on it!

[smnsc]

I use harp constantly, every day, and it's made my life SO easy. Over time I have come to depend on it so much that I resisted learning Hugo or some other static site generator and rely on Harp, especially as so few support EJS.

From my POV, it's absolutely worth it.

[sintaxi]

@ameesme @smnsc Thank you both for your input and encouragement. It helps a lot. Glad to know I'm not the only one still using harp :)

Here is my breakdown of the pre-processors and their status moving forward. Let me know if this doesn't look right to you...

Processor	Cost	Status
.ejs	864k	keep
.jade	1.8MB	keep
.md	320k	keep
.sass, scss	4MB	keep
.less	5.8MB	remove
.styl	2.9MB	remove
.coffee	1.8MB	remove
.jsx, .cjs	8MB	add

[jdcauley]

Wait. Is harp coming back?

If yes, a way to add lifecycle hooks so I could add things like image optimizations or other mark up manipulation at build or run time.

[sintaxi]

@jdcauley Its looking like a yes, harp is coming back.

I like the idea. Do you have an API design in mind? I think it would be nice if it was unobtrusive so people don't have to concern themselves with it if they don't want to. perhaps a harp.config.js file?

[jdcauley]

@sintaxi I haven't given it a ton of thought yet, 11ty has plugin capabilities that might be a good place to review for API design.

I'm excited about a Harp rebirth after finding most of the tools that have come up in the last few years require a bananas amount of initial configuration for something simple.

But the ability to use external sources to build from apis is a big plus, I think there is a way to marry the quick to start from harp with the flexibility and compilation in the newer tools.

[smnsc]

IMHO as long as it's compatible with more recent versions of Node, I'm happy.

One of harp's best aspects is the way it allows you to forget about it.

That's a rare feature in the current FE tooling environment.

[sintaxi]

@smnsc absolutely agreed.

[sintaxi]

Item 6 is now complete. The cut down version of terraform is a 87.17% reduction in size with very little change in functionality. This is a huge win in my view.

version	size
terraform@1.11.1	53M
terraform@1.12.0	6.8M
terraform with esbuild (in progress)	15M (est)

I think I'll cut a release of Harp using terraform@1.12.0 so that there is a super lightweight version. Then I'll start adding those new features.

[jvandemo]

This is awesome, thank you, @sintaxi! 🏆

[sintaxi]

@jvandemo thank you my man! Got any requests/suggestions?

[sintaxi]

Harp has a new CLI!

Item 4 complete.