The issue of attracting contributors is a funny one right now. We happen to be living in a time of plentiful new and interesting languages. Rust, D, Vale, and Elixir, for example, have all caught my attention by bringing things to the table that older, better-established languages don’t do as well. In order to benefit from them, and potentially help shape them into tools that benefit us even more, we have to use them. This is how we build a better future for ourselves, and for our field. IMHO, this is more important than maximizing the number potential contributors on every project. As a fairly new project, Lemmy is in a good position to make this trade-off.
(Also, having fewer contributors generally makes a project easier to manage, so the downside is not necessarily all down.)
I’m mainly glad they chose something with decent memory safety. This is important to me in systems that face the network or process external data.
Rust probably wouldn’t have been my first choice, because my early impression is that it seems ugly and awkward, so I don’t think I would enjoy using it. That doesn’t make it an objectively bad tool for the job.
On the front end, I just wish it was less reliant on JavaScript, such that basic functionality worked when scripts are disabled in the browser. Outside of that, TypeScript seems like a fine choice.
I’d go with Elixir + Phoenix for the backend. Though that would also mean not many people would manage to contribute, as it’s not a very widely known or used language. It is very resource efficient, tho, so it should scale upwards very easily
I’d use what I’ve been experimenting with exclusively on personal projects: htmx, AlpineJs and Razor Pages on PostgreSQL AKA the HARP stack. Obviously, a hilarious acronym was needed.
Which might sound esoteric and hipster, but I’d contend it’s pretty close to how we were building websites for decades before the cult of the SPA took over. For those not in the know, HARP is built with no fe frameworks, everything is rendered server side and html is swapped in the DOM on the fly. Htmx is a very tiny js library that makes backend requests to the server, and renders the returned htmx within the current page. AlpineJs is a client-side js library that acts like a modernized and simplified jQuery. Razor Pages is part of the ASP.NET web framework that runs on .Net, and produces html from Razor templates coded with C#. My professional work is on SQL Server, but I like PostgreSQL as the runner up because I’m not paying mssql out of my own pocket.
I’m wouldn’t be concerned with hiring since I’d mostly just need C# developers with some designers. .Net developers are a dime a dozen, and many are seasoned vets with 15+ years experience building with .Net. It’s easy to build a career with just C#/.net/asp.net so few of these devs are running around flipping frameworks every few hype cycles.
The behaviour you described is very similar to what Blazor is. No frontend framework, and the DOM updates are rendered on the fly. I’m using it a lot and it’s very good.
I like Blazor and use it exclusively at my work (usually to build the same type of stuff I’d use a HARP approach in a personal prj).
Blazor is awesome, but really is attractive to backend .Net developers more than anyone else. However, Blazor has a bunch of downsides: Blazor Server is too chatty to build scalable public facing webapps. Blazor WASM has a massive initial payload, which makes it slow and heavy.
Also, it just really falls into being overkill for so much stuff on the web. Half the shit I’m paid to build with Blazor would be faster and cheaper with just some htmx. Most SPAs are attempting to build a sand castle with an excavator.
[…] Blazor WASM has a massive initial payload, which makes it slow and heavy.
Blazor WASM doesn’t need to have a massive initial payload, that’s only if you’re making your projects too big, and aren’t really structuring them correctly. To be fair, Microsoft hasn’t really done anything to make this easier, or address this
(Shameless self promotion) - I however, have fixed that: https://github.com/RonSijm/RonSijm.Blazyload
Your “landing page” should basically ideally be pretty much the only thing that’s initially loaded, so that the initial load is fast. Once that is done, you can quietly lazy load the rest of the dlls you need
That’s my case, i’m a backend developer, more specialized in databases than websites, so i choose blazor because it was easy for me to become proficient fast and build nice and fast apps.
Also i usually build Enterprise apps, not public facing ones, so my target is still good for blazor. I know there are methods to scale better with blazor server (like using signalr on a separate service, outside the webapp).
Also we use DevExpress components, so basically all UI controls are done for me, so my dev time is even lower.
I’ll look at htmx, i’m curious at the tecnical differences and why it may be lighter than blazor.
I’d have gone with PHP. Modern PHP is really good, all the tools are mature, the few drawbacks it has are well understood and easily worked around, and it’s an easy language to learn with a huge community of people who already know it.
For a project this large and widely used - I wouldn’t use a framework and that’s another area where PHP really shines. The standard library is very comprehensive, and all of the major frameworks are split into smaller modules which can be used standalone and interact with modules from other frameworks.
So you can bootstrap the project and get to a working proof of concept quickly by using well tested and well written third party code, then later when you need lower memory footprints/etc it’s trivial to fork those modules and and reduce them to just the core features you are actually using in your project.
I think Rust is a little hard to find contributors, and is also just hard in general. Too low level.
I would opt for a language like Kotlin, Go or TypeScript. Easier than Rust, more popular than, or similar to Rust popularity.
JS, Python and ruby might also be very easy and popular, but they’re a little too loosey for me for a large project.
If I were to do it today, I would choose Scala purely out of interest. Such a cool language. But it’s probably less practical and popular than the choices I named above
The choice of stack would matter a lot less if the documentation were better. Last I checked, having to figure out the details of message semantics from scratch made writing better frontends or alternative server implementations in other languages ten times more difficult than it needs to be.
Definitely would have kept Rust, at least. Rust is one of the fastest growing languages out there (maybe fastest or second fastest), and it’s incredible for the majority of application domains, not just performance related.
The backend is quite alright. The Rust backend makes it indimidating to approach, but I know it has many advantages.
The frontend could use LOTS of changes. I don’t like Inferno, it’s messy and confusing to work with. Instead, I would have opted for a Svelte+Tailwind stack for the UI.
I think Rust is a perfect choice here. Considering the investments of the Linux kernel, AWS, Microsoft and so on, I think Rust is a future-proof bet.
That said it think the programming language is not everything. It seems to me that lemmy was written under the assumptions that there will be a lot more hosted instances that will fedrate but a lot of load seems to centralize on a handful of instances now (i.e. lemmy.world).
To support these it could make sense to rethink the system design to something that offers better support for high-load and high-availability scenarios.
Ngl I was going for worst possible stack. Not that either one is bad on its own, but like you said, I don’t think anyone in their right mind would choose this combo.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
I quite like Rust so I’m biased. But I understand it’s not always the best choice.
The issue of attracting contributors is a funny one right now. We happen to be living in a time of plentiful new and interesting languages. Rust, D, Vale, and Elixir, for example, have all caught my attention by bringing things to the table that older, better-established languages don’t do as well. In order to benefit from them, and potentially help shape them into tools that benefit us even more, we have to use them. This is how we build a better future for ourselves, and for our field. IMHO, this is more important than maximizing the number potential contributors on every project. As a fairly new project, Lemmy is in a good position to make this trade-off.
(Also, having fewer contributors generally makes a project easier to manage, so the downside is not necessarily all down.)
I’m mainly glad they chose something with decent memory safety. This is important to me in systems that face the network or process external data.
Rust probably wouldn’t have been my first choice, because my early impression is that it seems ugly and awkward, so I don’t think I would enjoy using it. That doesn’t make it an objectively bad tool for the job.
On the front end, I just wish it was less reliant on JavaScript, such that basic functionality worked when scripts are disabled in the browser. Outside of that, TypeScript seems like a fine choice.
I’d probably go with Symfony for the backend and Angular for the frontend.
I’d go with Elixir + Phoenix for the backend. Though that would also mean not many people would manage to contribute, as it’s not a very widely known or used language. It is very resource efficient, tho, so it should scale upwards very easily
I’d use what I’ve been experimenting with exclusively on personal projects: htmx, AlpineJs and Razor Pages on PostgreSQL AKA the HARP stack. Obviously, a hilarious acronym was needed.
Which might sound esoteric and hipster, but I’d contend it’s pretty close to how we were building websites for decades before the cult of the SPA took over. For those not in the know, HARP is built with no fe frameworks, everything is rendered server side and html is swapped in the DOM on the fly. Htmx is a very tiny js library that makes backend requests to the server, and renders the returned htmx within the current page. AlpineJs is a client-side js library that acts like a modernized and simplified jQuery. Razor Pages is part of the ASP.NET web framework that runs on .Net, and produces html from Razor templates coded with C#. My professional work is on SQL Server, but I like PostgreSQL as the runner up because I’m not paying mssql out of my own pocket.
I’m wouldn’t be concerned with hiring since I’d mostly just need C# developers with some designers. .Net developers are a dime a dozen, and many are seasoned vets with 15+ years experience building with .Net. It’s easy to build a career with just C#/.net/asp.net so few of these devs are running around flipping frameworks every few hype cycles.
But I might have just shown my age and bias.
The behaviour you described is very similar to what Blazor is. No frontend framework, and the DOM updates are rendered on the fly. I’m using it a lot and it’s very good.
I like Blazor and use it exclusively at my work (usually to build the same type of stuff I’d use a HARP approach in a personal prj).
Blazor is awesome, but really is attractive to backend .Net developers more than anyone else. However, Blazor has a bunch of downsides: Blazor Server is too chatty to build scalable public facing webapps. Blazor WASM has a massive initial payload, which makes it slow and heavy.
Also, it just really falls into being overkill for so much stuff on the web. Half the shit I’m paid to build with Blazor would be faster and cheaper with just some htmx. Most SPAs are attempting to build a sand castle with an excavator.
Blazor WASM doesn’t need to have a massive initial payload, that’s only if you’re making your projects too big, and aren’t really structuring them correctly. To be fair, Microsoft hasn’t really done anything to make this easier, or address this
(Shameless self promotion) - I however, have fixed that: https://github.com/RonSijm/RonSijm.Blazyload Your “landing page” should basically ideally be pretty much the only thing that’s initially loaded, so that the initial load is fast. Once that is done, you can quietly lazy load the rest of the dlls you need
That’s my case, i’m a backend developer, more specialized in databases than websites, so i choose blazor because it was easy for me to become proficient fast and build nice and fast apps.
Also i usually build Enterprise apps, not public facing ones, so my target is still good for blazor. I know there are methods to scale better with blazor server (like using signalr on a separate service, outside the webapp).
Also we use DevExpress components, so basically all UI controls are done for me, so my dev time is even lower.
I’ll look at htmx, i’m curious at the tecnical differences and why it may be lighter than blazor.
I’d have gone with PHP. Modern PHP is really good, all the tools are mature, the few drawbacks it has are well understood and easily worked around, and it’s an easy language to learn with a huge community of people who already know it.
For a project this large and widely used - I wouldn’t use a framework and that’s another area where PHP really shines. The standard library is very comprehensive, and all of the major frameworks are split into smaller modules which can be used standalone and interact with modules from other frameworks.
So you can bootstrap the project and get to a working proof of concept quickly by using well tested and well written third party code, then later when you need lower memory footprints/etc it’s trivial to fork those modules and and reduce them to just the core features you are actually using in your project.
That’s certainly an unpopular opinion. I like your bravery!
PHP is dead. Why not use TS.
So, kbin then?
I think Rust is a little hard to find contributors, and is also just hard in general. Too low level.
I would opt for a language like Kotlin, Go or TypeScript. Easier than Rust, more popular than, or similar to Rust popularity.
JS, Python and ruby might also be very easy and popular, but they’re a little too loosey for me for a large project.
If I were to do it today, I would choose Scala purely out of interest. Such a cool language. But it’s probably less practical and popular than the choices I named above
I’d argue the opposite - Rust is the perfect fit for the entire stack. We don’t even need JS with libraries like Yew
What does yew do?
You can write fronted in it without using JS, thanks to WASM.
I agree. Rust has advantages, but none of them outweighs the negatives (complexity, difficult to find devs) for this particular use case.
I also agree that JVM would be a good platform. It’s both performant enough and simple/conventional enough.
The thing with sum types, async support, trait system, is low level?
deleted by creator
The choice of stack would matter a lot less if the documentation were better. Last I checked, having to figure out the details of message semantics from scratch made writing better frontends or alternative server implementations in other languages ten times more difficult than it needs to be.
Definitely would have kept Rust, at least. Rust is one of the fastest growing languages out there (maybe fastest or second fastest), and it’s incredible for the majority of application domains, not just performance related.
The backend is quite alright. The Rust backend makes it indimidating to approach, but I know it has many advantages.
The frontend could use LOTS of changes. I don’t like Inferno, it’s messy and confusing to work with. Instead, I would have opted for a Svelte+Tailwind stack for the UI.
Svelte is such a pleasure to work with.
I think Rust is a perfect choice here. Considering the investments of the Linux kernel, AWS, Microsoft and so on, I think Rust is a future-proof bet.
That said it think the programming language is not everything. It seems to me that lemmy was written under the assumptions that there will be a lot more hosted instances that will fedrate but a lot of load seems to centralize on a handful of instances now (i.e. lemmy.world).
To support these it could make sense to rethink the system design to something that offers better support for high-load and high-availability scenarios.
It has the perfect stack
Flask backend
Blazor frontend
Why did you chose Blazor and then Flask instead of .NET for backend? I’m just curious.
Ngl I was going for worst possible stack. Not that either one is bad on its own, but like you said, I don’t think anyone in their right mind would choose this combo.
I read flash and was horrified a second.
Can actionscript be used for a database?
If you’ve got the right attitude.
Backend in Javascript (node) and frontend in PHP (web assembly), the only sane way.
Backend in Excel
The database should be made in Flash.
Nah, database as one huge JSON stored in local storage. Wait, did I accidentally invent MongoDB in a browser?
Just use Cobol. Lots of Cobol developers are idle these days.
OpenSilverlight would like a word.