https://forum.dlang.org/post/gpbfaobcmwjdprkxzzre@forum.dlang.org

On Tuesday, 6 February 2024 at 15:27:31 UTC, Sergey wrote:

For backend only webdev, I see no issue with using vibe.d besides not getting more options of third-party library for cloud services in D.

The major complaint was that vibe.d has a slow html templating library (diet) but that was about it.

These days, front-end libraries/frameworks ( react, angular, vue, svelte) are often used anyways.

I personally would consider vibe.d for backend only when building "large" apps due to the von mentioned above.

On Tuesday, 21 May 2024 at 03:37:11 UTC, aberba wrote:

Speed? (both compilation and RpS)

Recently htmx is gaining some popularity as well, which is not supported by D currently afaik.

But what are the benefits for large apps comparing to other solutions?

On Tuesday, 21 May 2024 at 06:54:35 UTC, Sergey wrote:

In my own words -- htmx is a javascript library designed to avoid writing javascript. htmx supports many typical client-side tasks for you by using the hx-... attributes inside your html.

htmx is very good. It has simplified my work A LOT.
In one of my projects, my javascript was reduced from 1000 lines to less than 100... and most of the javascript that remained was more layout than data.

So it does not need to be "supported by D" -- all the server-side does is return html code (with htmx) and thats it! It is language independent!

Using Vibe.d and Diet could easily make your html pretty and organised.

https://htmx.org

On Tuesday, 21 May 2024 at 09:25:16 UTC, Martyn wrote:

Kind of.. still many frameworks make integrations for better type safety and simplicity.. https://htmx.org/server-examples/

On Tuesday, 21 May 2024 at 06:54:35 UTC, Sergey wrote:

Naa, htmx is niche too (except on hackernews). Along with many others in the same bucket.

With that said, front-end requires a lot of iteration of the elements and styling and it'll be frustratingly slow working with a compiled language for that. Languages like like Go, Python, D, ruby are mainly suitable for backend. It doesn't make sense to not use these JavaScript libraries for front-end. React, vue, angular and svelte will be the top 4. I don't see why you'd want an alternative you'd have to wait for compilation after every single change (that is even if htmx was ported to D).

React has hot-reload in most frameworks where you see results of changes instantly...ensure fast iteration especially when styling elements. It's something like this vide.d's diet templates simply cannot match.

And why compiled languages like D are IMO suitable for back-end especially with safety (GC) and strict type checking.

D is faster than Java, JavaScript, ruby, Python. It's uncommon to find a language that reads like JavaScript by runs as fast as C++. As long as D code isn't time consuming to write or unnecessarily complicated, it checks many boxes except the lack of third-party packages for cloud services...aws, AI, dbms, web scraping, etc.

But personally, D has most of the main ones, you may just have to manually write a few more. I don't use D professionally mainly because of ecosystem reasons... because the JavaScript ecosystem is so rich these days for productivity although performance sucks for backend. But it's still within acceptable range.

On Tuesday, 21 May 2024 at 09:37:42 UTC, aberba wrote:

From my (and my teams) experience, it was not a frustratingly slow process when working on the frontend with htmx.

Our Server side returns html. Thats it. Sure - do we need to compile the code. Yes.. but we also created unit tests returning said html with mock data. We can easily grab it and dump it into the web browser to do our iteration and styling.

We do not use anything special.. just make use of the web browsers built in tools, injecting sample html and mucking with the CSS. Generally speaking, once we get our desired results, we take our CSS changes from the browser and update our .css files -- refresh/repeat. Same for any changes to our html output. Once happy we test the htmx aspect of it.

Sure, we took a few days to get the hang of htmx and find our flow. Now, it is just so much easier and productive when fixing bugs or adding new features. We are skipping a lot of the javascript side of it or a framework that adds additional layers with components, actions, etc.

Niche might be the right word. It certainly is niche in our team. I work with 6 developers and we can focus on getting the job done rather than having to deal with (something like) React.

We also dont need to hire anyone (anymore) where react is useful.. or even need to get a fulltime react dev. I can hire devs where skills matter most yet can still jump on our web projects when needed.

Our internal web portal is not small. It looks nice. It transitions/animates nice. It still looks rather similar to our previous one (in React) - it just avoids much of the javascript.

I honestly think Niche fits React as well. If it works for a company or development team - more power to you.

On Tuesday, 21 May 2024 at 12:48:12 UTC, Martyn wrote:

Btw what is in your stack for the server side?
And how did you come to this solution?

On Tuesday, 21 May 2024 at 12:55:03 UTC, Sergey wrote:

We are primarily a C# team.
Our web projects are the typical ASP.NET Core MVC.
We use Razor for our Views (returning html)
We also use Databases - SQL Server, Oracle, etc.

I want to make it clear that while I do like C# it is not my favourite language. It just happens to be the language I have made a career with. It is a popular language and plenty of jobs in this area.

If the opportunity presented itself I would be open to using D+Vibe. Reality is I have a team of developers and suggesting another language is not the right move.

If this question refers to the C# side of things - it is simply "the chosen language" at the company and have been accustomed to it for many, many years.

If this query refers to the htmx side of things, it is because I am tired of frontend javascript libraries. I miss the old days of web development and htmx seemed like an interesting project to review and remove unwanted bloat. That is just my opinion.

On Tuesday, 21 May 2024 at 09:37:42 UTC, aberba wrote:

That's what makes it a good target for D. What are the odds that an enterprise unwilling to use htmx would be open to using D? Maybe it's greater than zero, but it's small enough that you'd run into issues with floating point precision.

On Tuesday, 21 May 2024 at 14:02:18 UTC, Lance Bachmeier wrote:

After working in the industry for long, I honestly doubt an app-like front-end will be easy to build by spitting html from the server alone. I've done it, it doesn't scale easily. The kind of front-end I work on are like gui development for native apps but on the web with so many interactions and dynamic actions that it'll be almost unmaintainable with raw browser DOM APIs or jQuery. You'll need some kind of component model.

There's a reason why many SaaS apps opt for dedicated front-end frameworks/libraries and decoupled back-end from front-end. The alternative works for smaller apps but it becomes difficult to scale, test and maintain eventually. I've worked with companies where I had to migrate their front-end to React to make it easier to build an app-like experience. The component model abstraction used my most Js frameworks really works.

Now I agree the JavaScript ecosystem has gone nuts with the noise and oversaturation which eventually leads to Js fatigue, but that's what you get with popularity. I hate it too. I hope to move to using D professionally for backend someday.