www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Web Programming in D

reply aberba <karabutaworld gmail.com> writes:
https://forum.dlang.org/post/gpbfaobcmwjdprkxzzre forum.dlang.org

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

 On Thursday, 22 June 2023 at 06:15:47 UTC, Web Dev wrote:

 I think Hunt is no longer in development but Vibe.D continues 
 to be developed.


 It seems that Hunt is dead yes.


 Has anyone done a web project with Vibe.D before? What are the 
 positive and negative aspects?


 Some people are using D for web projects.
 For example this one looks nice: https://myst.rs/

 Mostly you have 2 frameworks with many features:
 * Vibe.d
 * Arsd CGI

 Vibe has many integrations with different packages (oauth, 
 oneapi, graphql).
 CGI is the fastest (at least in benchmarks).

 If you need simpler solution (just a server):
 * handy
 * serverino
 * lighttp (not maintained, but still worked)


 Does it make sense to use the D language on the web for now?


 Like there is no any sense to use D in general, not 
 specifically in web.
 But if you like D, you can use it for web as well.

 For production I think it is save to choose Go.

 I think current level of D frameworks won't provide any "killer 
 features" compare to other popular solutions and have more cons 
 (lack of users, documentation, adoption for deployment, etc) 
 than pros (D is fun and great for your hobby project).

 But you can try it for something simple and see if it works for 
 you :)


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.
May 20
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Tuesday, 21 May 2024 at 03:37:11 UTC, aberba 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.


Speed? (both compilation and RpS)


 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.


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


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


But what are the benefits for large apps comparing to other 
solutions?
May 20
next sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Tuesday, 21 May 2024 at 06:54:35 UTC, Sergey wrote:

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


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
May 21
parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 21 May 2024 at 09:25:16 UTC, Martyn wrote:

 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!


Kind of.. still many frameworks make integrations for better type 
safety and simplicity.. https://htmx.org/server-examples/
May 21
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Tuesday, 21 May 2024 at 06:54:35 UTC, Sergey wrote:

 On Tuesday, 21 May 2024 at 03:37:11 UTC, aberba 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.


 Speed? (both compilation and RpS)


 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.


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


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.


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


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


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.
May 21
next sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Tuesday, 21 May 2024 at 09:37:42 UTC, aberba 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).


 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.
May 21
parent reply Sergey <kornburn yandex.ru> writes:
On Tuesday, 21 May 2024 at 12:48:12 UTC, Martyn wrote:

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


Btw what is in your stack for the server side?
And how did you come to this solution?
May 21
parent Martyn <martyn.developer googlemail.com> writes:
On Tuesday, 21 May 2024 at 12:55:03 UTC, Sergey wrote:

 Btw what is in your stack for the server side?



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.


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.



 And how did you come to this solution?



"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.
May 21
prev sibling next sibling parent reply Lance Bachmeier <no spam.net> writes:
On Tuesday, 21 May 2024 at 09:37:42 UTC, aberba wrote:


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


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.
May 21
parent aberba <karabutaworld gmail.com> writes:
On Tuesday, 21 May 2024 at 14:02:18 UTC, Lance Bachmeier wrote:

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


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


 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.


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.
May 21
prev sibling parent reply Aravinda VK <mail aravindavk.in> writes:
On Tuesday, 21 May 2024 at 09:37:42 UTC, aberba wrote:

 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).


I am using Vibe.d for one of the application that I am currently 
working on. During development, I use the Live feature of Diet 
library so that I need not compile again for the HTML changes in 
diet file.

```
dub build --d-version=DietUseLive
```

After changing the diet template, browser refresh will show the 
latest changes (No need to run `dub build`).

**Note**: Please note, Live mode will not work as expected if lot 
of embeded D code used inside the diet template. Using Live mode 
is not recommended for production use (Refer: 
https://github.com/rejectedsoftware/diet-ng/?tab=readme-ov-file#experimental-html-live-mode)
May 22
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 22 May 2024 at 16:22:42 UTC, Aravinda VK wrote:

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

 [...]


 I am using Vibe.d for one of the application that I am 
 currently working on. During development, I use the Live 
 feature of Diet library so that I need not compile again for 
 the HTML changes in diet file.

 ```
 dub build --d-version=DietUseLive
 ```

 After changing the diet template, browser refresh will show the 
 latest changes (No need to run `dub build`).

 **Note**: Please note, Live mode will not work as expected if 
 lot of embeded D code used inside the diet template. Using Live 
 mode is not recommended for production use (Refer: 
 https://github.com/rejectedsoftware/diet-ng/?tab=readme-ov-file#experimental-html-live-mode)


Awesome. Interesting to know it works. Due to that statement, I 
never tried the live mode.

If I may ask, what other dub packages are you using?
May 22
parent Aravinda VK <mail aravindavk.in> writes:
On Wednesday, 22 May 2024 at 18:37:34 UTC, aberba wrote:

 On Wednesday, 22 May 2024 at 16:22:42 UTC, Aravinda VK wrote:

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

 [...]


 I am using Vibe.d for one of the application that I am 
 currently working on. During development, I use the Live 
 feature of Diet library so that I need not compile again for 
 the HTML changes in diet file.

 ```
 dub build --d-version=DietUseLive
 ```

 After changing the diet template, browser refresh will show 
 the latest changes (No need to run `dub build`).

 **Note**: Please note, Live mode will not work as expected if 
 lot of embeded D code used inside the diet template. Using 
 Live mode is not recommended for production use (Refer: 
 https://github.com/rejectedsoftware/diet-ng/?tab=readme-ov-file#experimental-html-live-mode)


 Awesome. Interesting to know it works. Due to that statement, I 
 never tried the live mode.


I think it is must have during development especially during 
front-end development. Use the Diet cache feature during back-end 
development to improve the compile speed.


 If I may ask, what other dub packages are you using?


Not many. `yxml`, `prometheus`, `d2sqlite3` and `dpq2` and a few 
others.
May 22
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 22 May 2024 at 16:22:42 UTC, Aravinda VK wrote:


 **Note**: Please note, Live mode will not work as expected if 
 lot of embeded D code used inside the diet template. Using Live 
 mode is not recommended for production use (Refer: 
 https://github.com/rejectedsoftware/diet-ng/?tab=readme-ov-file#experimental-html-live-mode)


Great to see other people find it useful!

To clarify a bit -- live mode does not include a D compiler, so 
it should work as long as any of your changes are to the *html* 
portion of the diet file. If any code has changed (including 
restructuring the code, like moving an interpolation outside a 
loop), then it's not just that it just won't render the changes, 
it actually will throw an exception, and refuse to render the 
template. The exception says as much. This is one of the main 
reasons it's not recommended for production -- you don't want to 
mess with the file and find it crashes your server.

Note that it still requires you to compile your templates into D 
code, because, well, there is no compiler to do it later!

I use live mode constantly, and vibe development is 10x better 
because of it.

If you are interested in compilation speed, you can use my dietpc 
pre-compiler and cache mode to avoid some of the giant 
memory/compilation time of diet templates.

https://github.com/schveiguy/dietpc

-Steve
May 22
parent Aravinda VK <mail aravindavk.in> writes:
On Thursday, 23 May 2024 at 00:44:26 UTC, Steven Schveighoffer 
wrote:

 On Wednesday, 22 May 2024 at 16:22:42 UTC, Aravinda VK wrote:


 [...]


 Great to see other people find it useful!

 To clarify a bit -- live mode does not include a D compiler, so 
 it should work as long as any of your changes are to the *html* 
 portion of the diet file. If any code has changed (including 
 restructuring the code, like moving an interpolation outside a 
 loop), then it's not just that it just won't render the 
 changes, it actually will throw an exception, and refuse to 
 render the template. The exception says as much. This is one of 
 the main reasons it's not recommended for production -- you 
 don't want to mess with the file and find it crashes your 
 server.

 Note that it still requires you to compile your templates into 
 D code, because, well, there is no compiler to do it later!


I like the way it compiles the Diet templates into binary and 
serve the content from RAM. It is awesome for production use. I 
started using the Live mode only for development where I can skip 
recompiling the code for each CSS/JS/HTML change.


 I use live mode constantly, and vibe development is 10x better 
 because of it.

 If you are interested in compilation speed, you can use my 
 dietpc pre-compiler and cache mode to avoid some of the giant 
 memory/compilation time of diet templates.

 https://github.com/schveiguy/dietpc


Looks interesting. Thanks.


 -Steve
May 22
prev sibling parent reply Andrea Fontana <nospam example.com> writes:
On Tuesday, 21 May 2024 at 03:37:11 UTC, aberba 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.


We successfully use serverino+parserino for html serving.

Andrea
May 21
parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 22 May 2024 at 04:42:38 UTC, Andrea Fontana wrote:

 On Tuesday, 21 May 2024 at 03:37:11 UTC, aberba 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.


 We successfully use serverino+parserino for html serving.

 Andrea


Big fun of those two. I recently tried it and looks cool.

Would you consider a templating system at some point? I would 
love to be able to include header, footer, etc. in multiple pages.
May 22
parent Andrea Fontana <nospam example.org> writes:
On Wednesday, 22 May 2024 at 18:41:12 UTC, aberba wrote:

 On Wednesday, 22 May 2024 at 04:42:38 UTC, Andrea Fontana wrote:

 On Tuesday, 21 May 2024 at 03:37:11 UTC, aberba 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.


 We successfully use serverino+parserino for html serving.

 Andrea


 Big fun of those two. I recently tried it and looks cool.

 Would you consider a templating system at some point? I would 
 love to be able to include header, footer, etc. in multiple 
 pages.


We use parserino as template system. You can write your own 
header.html footer.html etc and composing them using the dom 
easily.

Or easier: build a page with footer header and everything else 
and then replace the contents and/or remove the parts you don't 
need.

Eg: 
https://github.com/trikko/parserino/blob/bcef3c11a106f03d578eaacf764547b287edb24d/examples/05_serve_html/source/app.d#L37

Andrea
May 23