Learned a few things about state management and effects, thanks! If you’re open to feedback, I had a couple thoughts: - The intro before coding was a bit too abstract for me. Would’ve liked slower-paced visuals or to jump straight into code - Take a breather between segments! You have a great problem-> solution structure, but I needed beats in between
Appreciate the feedback, thanks! Yeah, I agree the explanation of TEA could've perhaps been a little more concrete. As for the rest, that's just kinda my style 😅 it's polarising at times, but I do get lots of people say they enjoy not having to watch at 2x speed. Thanks again, and keep up the good work on Astro 😉
I love all the memes / images you include, really subtle jokes sometimes ! The "scaffold" one was unexpectedly funny. Great video, ready for the next one, thank you !
Unfortunately ELM is not actively maintained, its lasted version is from 5years ago so I’m glad there’s finally a good alternative to ELM. Looking really good, definitely going to try it out.
Gleam is getting popular because it's genuinely a joy to write. It's a really good intro to FP for people who aren't familiar with it, it's really simple, it's got a great type system, the community is lovely, and the multiple compilation targets are very useful. Most of the other langs that compile to JS don't also compile to a BEAM VM language. When I do later videos in this series, you'll see how beneficial that is - you'll get full stack type safety while being able to make use of the BEAM's amazing scalability and fault tolerance.
Nice. The problem, though, is that with all these languages offering an alternative development experience (F#, Elm, PureScript, etc.), the ecosystem and libraries are so far behind modern-day frontend development that there's literally no good argument for using them other than for fun side projects in your spare time. I will try gleam for my next toy frontend app though 🍻
In some ways yes, and in others no. I agree that the ecosystem is larger in other langs, but I don't necessarily agree that there's no good argument to use them. Elm has been used in production sites just fine, and if you don't need a mega-interactive site (which is 99% of projects, to be honest), something like Lustre is probably one of the more robust ways to get there.
@@IsaacHarrisHolt Well, I'll give you that there are good arguments for using something like Gleam, but I would say they are not strong enough if your end goal is to ship products as fast as possible. However, if something like shadcn/ui and Flutter comes to Gleam, I'll definitely change that statement!
@@keffbarn totally fair! We're exploring the possibility of a Laravel-like backend framework for Gleam at the moment too: github.com/Pevensie/pevensie/discussions/1
Such a Beauty. Now i clearly see benefits from Gleam evolution. Transpiling to JS is mega selling point. If i didn't seen Elm before then feeling is like on first Rails presentation 20 years ago... magic and turtles all the way down ;)
I'm an Elm orphan, I love ELM but I'm really disappointed by the fact it's more or less abandoned. I'm glad Gleam and Lustre are here to make SPA development joyful again. The difference with Elm is, as I understand, Gleam is not a pure functional language, any function can be non deterministic and have a side effect, so it's up to the developer's discipline to write pure function and managed effects while using Lustre. I think encouraging purity without imposing it is a good trade off though, especially for a language that targets mainly the BEAM and is meant for backend dev.
Gleam is wonderful, honestly. And you're right, Gleam functions can have side effects. As you said though, it's discouraged outside of a managed effect when using Lustre. Especially IO, as that'll have a performance impact and will probably block your UI updates.
Thanks for this video! Gleam and Lustre are very interesting. I’ve been learning phoenix, and one thing that I can’t find is information on interop approaches between Gleam and other beam languages. I think that’s an overlooked killer feature for gleam that nobody seems to be talking about. Image the power of tools like ecto and phoenix written in gleam!
Great video, I would be really interested in how you would organize bigger projects. I know JS/TS and tailwind well, so I am of course used to creating custom components, which is really helping in a bigger application. How would you organize something like a dashboard for example with a complex layout, a sidebar, top nav and each site having a lot of data/interactive things going on.
So you technically CAN have custom components in Lustre, and it's useful for things where you really do need inner state (like a combo box). However, typically you would have a model with sub models, effectively. So (paraphrasing) you might have: ``` type DashboardModel type User type Route { Home Dashboard(DashboardModel) } type Model { Model(route: Route, user: Option(User)) } ```
@@IsaacHarrisHolt thanks for the reply! Do you think something like a component framework would be fairly easy to create? I would normally create one for at least the current project, better for the whole company to use and maintain. If I understood correctly, the best way would probably be to just create a package for that.
if you look out for "Games made with ELM " you will find alot of examples this means you can do the same thing with Lustre in Gleam but with better flexibility
I love how this is like Elm, but open source and backed capable. My problem with this level of abstraction over HTML is how hard animations become. After experiencing how easy animations are with svelte, and how important they are for user experience I am very worried about trying anything else
Fair point. It's something that's come to my mind too, honestly. You CAN break things out into components, so I imagine for things that need animations you'd do that, but you could also just write the animations in CSS (which is mostly what Svelte does anyway)
@@IsaacHarrisHolt css animations are great when they fill the bill, however when they are not you want to have dom manipulation control. Svelte provides fly, slide and other animations that are not doable with plain css
That's true. You could probably achieve what you want with effects that show/hide elements and do a transition in the background, sending a message once done
Would be interesting to see some good and more complex interactivity implemented in Lustre. I know it wasnt your intent to show case that but with frameworks like this I often think that it seems slightly painful to build a great user experience.
Also, why focus on a js target with gleam? To me the erlang machine seems much more interesting. The JS frontend ecosystem is so developed at thus point
Yeah that’s a great point, I wonder how would it look like to build a reusable search-box component with autocomplete, multi-selection and accessibility. How many messages and update functions would be needed, it also seems like all component’s state is managed at the application level which can be overwhelming. On the other hand this seems very interesting specially for simple UIs that may not need a whole JS Framework. I definitely would love to see more of Lustre and Gleam.
For stuff like this, Lustre DOES support a component model, so you can delegate to that when you need to. You just wouldn't store your entire application's state in such a model
As for why the JS target, it's just a different application of Gleam. Lustre is actually a full stack framework - I'll be doing into doing more with Lustre on the BEAM in future videos!
@IsaacHarrisHolt that's cool, but I'm remain unconvinced that backend is the right place to create this interactive experiences. Feels like they will always play catchup, personally I think some more headless setup is better for that. Not a knock on your video though, more a general thought
I’m curious and need to play with this. I’ve been loving learning gleam and looking something to use it in. Any approach to use it on web makes easier to find a place I guess, even if just for simplicity, but I’m still wary of how good js transpile… I need to try it myself and check on the ergonomics of this kind o pf solutions
Please do! Let me know what you think :) in my experience, the JS output is probably slightly less performant than vanilla JS, but the type guarantees you get outweigh that tenfold.
This is pretty cool. I have a question though. How does the browser interpret the interaction? Does it get compiled to javascript ? Is it possible to just return HTML from lustre endpoints and use something like HTMX ?
It does compile to JS, yes. You CAN use HTMX with Lustre SSR, but it's kinda pointless. Lustre is full stack, so you can use it on the backend too. I just haven't got that far in the series!
@@IsaacHarrisHolt Interesting. You can build both your FE and BE in gleam and leverage BEAM on the backend and type-safety on the frontend, right? If so, what would be the pros and cons of this approach ?
The biggest pro is that you get full stack type safety, and you get to leverage the BEAM to create a really scalable backend. Cons wise, you're locking yourself into Gleam. I don't see that as a massive problem though, to be honest
@@IsaacHarrisHoltLocking yourself into Gleam is also Pro that's why JavaScript devolopers want to write servers in node because using the same language for frontend and backend makes things easier also the team understand each others code and make it easy for full stack devs to learn one language and be great at BE and FE
Does it transpile into JS? Then what stops runtime code in JS (which have weak typing) to create runtime errors? What about external data, eg from API? At least, WebAssembly is typesafe
External data can be a source of errors regardless of the language. Thankfully, Gleam decoders prevent it from crashing your code and provide a nice way to handle it. And yes, it does transpile to JS, but the type guarantees you get from Gleam's type system work really nicely, and Gleam code won't throw exceptions (unless you FFI to JS code that throws)
Doesn't Typescript have a tsconfig file that will let you be extra strict on type safety? In ur example @0:22, I'm under the impression the tsconfig you had setup w/ loose restrictions.
@@IsaacHarrisHolt Gleam with lustre looks promising. If UI 3rd party UI Libraries grow to industry standard, I'll consider using it for larger projects.
@@user-eg4qz9yc7elook at elm language its very stable ask the people who have used it in production one company said it was using it for years and finnaly got a runtime exception after having no runtime errors for years Lustre is taking the way Elm is doing Ui so its stable also ...untill you use JavaScript inside your gleam project you might have runtime exception in your JavaScript code just like you would normally but if you implement small functions that won't give runtime exceptions you will be fine
I get the following error when trying to run the app as you do (7:40) error: Unknown module error: Unknown module ┌─ D:\gleam programs\app\src\app.gleam:31:26 │ 31 │ fn view(model: Model) -> element.Element(Msg) { │ ^^^^^^^^^^^^^^^^^^^^ Did you mean `lustre/element`? No module has been found with the name `element`.
It's unlikely to be exactly as performant, but browsers are so fast these days that you're not going to notice the difference. It also depends on your code. It's really easy to write really slow JS
You'd generally split your model and message types, and then have an update and view function per page that gets called from the main ones depending on the view!
I am totally new to the elixir erlang thing, phoenix really something like not using json my mind broke. Can I do the same thing with gleam or am I misunderstood. Thanks
@@IsaacHarrisHolt how can I learn these? Like I learnt the struct and basics of elixir and now thinking about phoenix but I never wrote Ruby on rails so pattern is something else. I was thinking of switching to gleam and your videos really motivate me
Gleam is a functional programming language, so the syntax will be different to non functional languages somewhat. That said, Gleam still aims to be readable for non functional programmers
Not in this example - here we're just serving HTML, CSS and JS (compiled from Gleam) to the frontend. Lustre supports server components which work on the way you're describing
@@IsaacHarrisHolt Yeah i understand but, in jsx you still see the html easy syntax (mixed with big chunks of js logic wich i don't like it too). A front designer can not event touch this level of abstraction of html. Thats my point.
In that case you probably need a new frontend designer 😅 this is barely an abstraction, and should take someone 20-30 minutes to learn at worst, and not that much longer to feel comfortable.
It's not just CRUD stuff - that's just what I've shown off here. You can do a whole lot with Lustre! Would you say React is something for "basic CRUD stuff"?
@@IsaacHarrisHolt there's also a really interesting talk from Mark Erikson at React Summit 2024 that gives the history of redux & shows the diagram I was talking about which originally came from a thing called Flux Architecture from Facebook.
Interesting! I do think that, while the idea behind Redux was good, there are better alternatives in the React space that fit React's rendering model better. It works well in Lustre and Elm because they were built from the group up for this approach, but iirc Redux would cause a lot of unnecessary rerenders
SSR for all the times you don’t need a SPA with offline functionality, WASM for when you do. Enough with awful JS and the endless front end frameworks, libraries, and languages that transpile to JS.
JS is not just about having offline functionality, it's about delivering experiences that delight your users, and more importantly, ones that don't frustrate them. I don't wanna have to wait for a server roundtrip to open a modal
@@IsaacHarrisHolt If you legitimately have users on very poor connections and a request to the server for interactions are frequent and slow enough to be noticeably worse than downloading a bunch of JS which is probably going to mostly make requests for JSON for most interactions, go for it. Also, SSR frameworks don’t stop you from still using JS for trivial things if you want, it lets you stop using it for the other 90%+. But for non-edge cases, let’s be real here, nobody’s “waiting” on that 20-30ms delay to show some UI element. Especially after you’ve made them wait to download your front end framework and the endless libraries that make up the rest of the stack.
I agree about slow connections, but that's why progressive enhancement exists. Also, 20-30ms is unrealistic for anything that also needs a database call, which a lot of things do these days. But I do get your point, however this video was meant to show off Lustre. The next video in the series is good to use Lustre in SSR mode :)
I think Gleam is cool, but I also don't see this succeeding in the industry. Thing is modern applications are built on a ton of libraries, some really complex ones, and just like dart didn't succeed, until you can directly tap into those libraries and interop then it won't be adopted for real world products (or at least not complex apps). Also, in the end browsers run html, css and javascript. So when you need to debug or tap in very specific web behaviours, you need to do it in its original language.
@@IsaacHarrisHolt Most dev teams have enough backlog as it is. Writing FFI is also error prone if you have to do it in a rush, so greatly diminishing the advantages Gleam would bring. Strict typescript is enough, with a good linter. And my argument remains, for instance I work a lot with web standards such as web components, which are essential for our primary business concern. Luster would just be a pain point. There are other use cases where it would only create friction. Like I said, cool project, but I have my doubts it'll be adopted at scale
So, on the web component front, Lustre has its own component system which essentially just registers a Lustre view function as a web component, so it's totally interoperable with standard JS stuff. And on your FFI point, I agree that it's an extra step, but I've so far found very few instances where I've needed it. Usually it's only to use very specialised libraries - the Gleam philosophy leans more towards implementing things yourself than pulling in loads of third party libs. While yes, this does mean there's an initial hit to development speed, it's a massive boon in the mid- to long-term as your code is more maintainable and extensible. The proliferation of libraries in the JS ecosystem because people can't be bothered to write simple functions like left pad or, honestly, most of lodash, causes innumerable problems and build-time slowdowns. I don't totally disagree with everything you've said, but I do think Lustre has a place. Being type safe makes it a great choice for larger applications, and Gleam's full stack type safety is also a huge boon if you're developing something more complex.
@@IsaacHarrisHolt I think gleam has a place, but where I think we disagree, is that I think it has a place in small applications. Not on enterprise grade. Writing your own left pad is not an issue. But writing a production ready, large scale and well tested library for a complex use case from scratch just won’t cut it. Let’s say you have part of your application that needs a multi-user real time text editor. You could use something like liveblocks in js land. Now with gleam, writing ffi for a code base that is 1.5mb is a project of its own. And if I need SLA and support I will have it with the official library. Now, you can probably reimplement all the protocols (because those are open source) and make it yourself in Gleam, but if I just need that for a small part of my app, and I make mine in typescript, I can probably ship that feature in less than a week. But with gleam from scratch, then you just added 1-2 months for that one feature. And it won’t be better tested that a dedicated library in JS. The language in theory allows to write safer code, but it does not negate the fact that well tested software needs a lot of engineering time. For a personal blog, or a Pokédex, then yes, Gleam is fun a fresh. But for enterprise applications, used in production, I don’t see gleam/luster making a dent any time soon. Bigger projects like flutter, backed by large corporations also didn’t make a dent. Hence my skepticism
I don't necessarily disagree here, but you've picked out one very niche use case. Sure, if your entire app is gonna revolve around a single library you're probably better off in JS. But if that's the case, what you're building is probably not worth building anyway - you want to be building your own technologies so you have a moat nobody else can copy. If you're only using it for a small part of the app, it's not a big deal to write a bit of FFI, and writing the whole app in a more error prone language for the sake of a single feature is not a wise choice.
It does, and plenty of large apps were put into production using Elm. You have to break things down, but ultimately you still have a single model at the top of everything.
@@IsaacHarrisHolt support of it will be headacke actually. I had expreience with Elm, and to move slower and slower. And hard connections doesn't help. Split system by features too. For instance you can have platform, where is a lot of forms, graphs, chat with clients. You wanna avoid load code for graphs before open the route and etc. You need controll data load and free manually. When I use react - I can write such code, if my branch's created, I load data, when it's removed, it'll be free
I didn't cover it in this video, but Lustre has a component model you can delegate to if you really need to. It's good for really interactive things like graphs and chats, but ultimately you'd keep your page state at the top level
@@IsaacHarrisHolt maybe it needs to see for understand how is it good/bad for change opinion. I tried to use Elm and in some time I fell like I am in swamp)) Also there is really hard to do something not in the loop(outside of architecture). Gleam does not have this drawback
Isn't this extremely slow though? Productivity wise I mean. What you did in the first 8 minutes could be done in a minute using any modern JS framework.
That's because in the first 8 minutes I was exploring the core concepts and building up to an application with effects. In reality you'd go straight into building your model and so forth. This video is meant for learning, not necessarily a "here's the step by step guide to create an app from scratch if you already know what you're doing". You'd skip the first few steps, as you would with JS.
@@IsaacHarrisHoltthis looks also a bit unscalable in my opinion, having a single massive enumeration for all your messages in your entire app sounds.. bad?
not a fan of elm architecture. i remember when all of the rust wasm frameworks used to be based on this. they shifted to signals and hooks which is much better.
@@IsaacHarrisHolt Two syllable words are best for mind share, or at least something that is punchy, easy to pronounce and remember. I know Gleam community is mainly british but if you are successful you might want to have your stuff easily pronounced and understood by others. Lustre = good. Gleam = Good. Pevensie = Huh? Pensive, pvc, peevency? Also, rude?
Yeah, I would argue that "I'm only bothering to comment because I think something you've done is horrible in such a way that nothing else is" is not the nicest of ways of phrasing something. On your two syllable point... Laravel.
@@IsaacHarrisHolt I know, it just makes me sad; and I wanted to see how styles would normally be applied to components (The video is fantastic, the tailwind is the only bit that isn’t excellent)
FP concepts are fine, but trying to solve real-world problems solely through pure programming is wrong. Computers are machines with mutable state. Accept it.
Gleam has ffi, you can make external JavaScript files that can mutate state of your own gleam files and types Lustre has a JavaScript runtime for their framework that allows mutability via effects
I'm a glass half full kinda guy, and I assumed that people on the internet wouldn't go out of their way to try and knock someone down, especially over something small like this, because that would be unnecessary and mean. I prefer to hope that people aren't mean :)
@@IsaacHarrisHolt I see it as helping each other to make the world better - the memes don’t contribute to the process, nothing personal. I like the intellectual part of the content but it’s hard to watch most of the time because of them )
I paused the video for a sec, so you can take a breath.. you're welcome!
great video ,thank you!
Haha thank you! Believe it or not I actuallyspeaklikethisallthetime
Learned a few things about state management and effects, thanks!
If you’re open to feedback, I had a couple thoughts:
- The intro before coding was a bit too abstract for me. Would’ve liked slower-paced visuals or to jump straight into code
- Take a breather between segments! You have a great problem-> solution structure, but I needed beats in between
Appreciate the feedback, thanks! Yeah, I agree the explanation of TEA could've perhaps been a little more concrete. As for the rest, that's just kinda my style 😅 it's polarising at times, but I do get lots of people say they enjoy not having to watch at 2x speed.
Thanks again, and keep up the good work on Astro 😉
can't wait for the next gleam adventures you are covering, I'm subbing!
Thank you! Lots of exciting stuff coming
0:09 this is my new favourite description of javascript
Yesss it's been my go to for a while
I love all the memes / images you include, really subtle jokes sometimes ! The "scaffold" one was unexpectedly funny.
Great video, ready for the next one, thank you !
Thank you! I do try 😅
Unfortunately ELM is not actively maintained, its lasted version is from 5years ago so I’m glad there’s finally a good alternative to ELM.
Looking really good, definitely going to try it out.
I would disagree that it's close to TypeScript at all. Gleam's type system is much more robust, and TEA is not something most TypeScript apps use.
Gleam is getting popular because it's genuinely a joy to write. It's a really good intro to FP for people who aren't familiar with it, it's really simple, it's got a great type system, the community is lovely, and the multiple compilation targets are very useful.
Most of the other langs that compile to JS don't also compile to a BEAM VM language. When I do later videos in this series, you'll see how beneficial that is - you'll get full stack type safety while being able to make use of the BEAM's amazing scalability and fault tolerance.
Gleam for me is what i always wanted from Elm Good FFI Good Backend Support and the fimmilar syntax to other languages
20 million web developers and barely 20 good websites...
Hahahhahaha so true!
It's because HTML, CSS, and Javascript are cursed abstractions.
... lol going backwards in webdev
SUPER Excited to see that lustre added server side rendering support recently.
It's great!
Whoa, this looks so amazing. I am in love with elm, and seeing gleam doing the same is just amazing. Maybe I can do my next project in it 🥰😍
Do itttt! Gleam is a bit more flexible, and Lustre is fantastic!
Nice. The problem, though, is that with all these languages offering an alternative development experience (F#, Elm, PureScript, etc.), the ecosystem and libraries are so far behind modern-day frontend development that there's literally no good argument for using them other than for fun side projects in your spare time. I will try gleam for my next toy frontend app though 🍻
In some ways yes, and in others no. I agree that the ecosystem is larger in other langs, but I don't necessarily agree that there's no good argument to use them. Elm has been used in production sites just fine, and if you don't need a mega-interactive site (which is 99% of projects, to be honest), something like Lustre is probably one of the more robust ways to get there.
@@IsaacHarrisHolt Well, I'll give you that there are good arguments for using something like Gleam, but I would say they are not strong enough if your end goal is to ship products as fast as possible. However, if something like shadcn/ui and Flutter comes to Gleam, I'll definitely change that statement!
@@keffbarn totally fair! We're exploring the possibility of a Laravel-like backend framework for Gleam at the moment too: github.com/Pevensie/pevensie/discussions/1
Can think of blazor from c# too
@@chneau I'm not entirely sure I see the connection here. Isn't Blazor just a templating language?
Such a Beauty. Now i clearly see benefits from Gleam evolution. Transpiling to JS is mega selling point.
If i didn't seen Elm before then feeling is like on first Rails presentation 20 years ago... magic and turtles all the way down ;)
I think there's very little magic. In fact, what I like about Lustre is just how clear all the flows are, since they're all laid out in your model
@@IsaacHarrisHolt Magic in Sagan sense "any advanced technology....:
I'm an Elm orphan, I love ELM but I'm really disappointed by the fact it's more or less abandoned. I'm glad Gleam and Lustre are here to make SPA development joyful again.
The difference with Elm is, as I understand, Gleam is not a pure functional language, any function can be non deterministic and have a side effect, so it's up to the developer's discipline to write pure function and managed effects while using Lustre. I think encouraging purity without imposing it is a good trade off though, especially for a language that targets mainly the BEAM and is meant for backend dev.
Gleam is wonderful, honestly. And you're right, Gleam functions can have side effects. As you said though, it's discouraged outside of a managed effect when using Lustre. Especially IO, as that'll have a performance impact and will probably block your UI updates.
i really hope development for gleam and things like lustre continue and dont end up in ELM land
I think Gleam will go further, being a general purpose language. It's also got amazing applications on the server thanks to its BEAM target
Thanks for this video! Gleam and Lustre are very interesting. I’ve been learning phoenix, and one thing that I can’t find is information on interop approaches between Gleam and other beam languages. I think that’s an overlooked killer feature for gleam that nobody seems to be talking about. Image the power of tools like ecto and phoenix written in gleam!
I've actually got a video on this coming out... _checks watch_ tomorrow!
@@IsaacHarrisHolt can’t wait!!
Great content as usual... I look forward to the next one.
Thanks!
Great video, I would be really interested in how you would organize bigger projects.
I know JS/TS and tailwind well, so I am of course used to creating custom components, which is really helping in a bigger application.
How would you organize something like a dashboard for example with a complex layout, a sidebar, top nav and each site having a lot of data/interactive things going on.
So you technically CAN have custom components in Lustre, and it's useful for things where you really do need inner state (like a combo box).
However, typically you would have a model with sub models, effectively. So (paraphrasing) you might have:
```
type DashboardModel
type User
type Route {
Home
Dashboard(DashboardModel)
}
type Model {
Model(route: Route, user: Option(User))
}
```
@@IsaacHarrisHolt thanks for the reply! Do you think something like a component framework would be fairly easy to create? I would normally create one for at least the current project, better for the whole company to use and maintain.
If I understood correctly, the best way would probably be to just create a package for that.
Yeah, that's absolutely an option
As someone who is a little bit into gamedev I can relate really well with TEA .
Awesome! Are you gonna try it?
if you look out for "Games made with ELM " you will find alot of examples this means you can do the same thing with Lustre in Gleam but with better flexibility
I love how this is like Elm, but open source and backed capable. My problem with this level of abstraction over HTML is how hard animations become. After experiencing how easy animations are with svelte, and how important they are for user experience I am very worried about trying anything else
Fair point. It's something that's come to my mind too, honestly. You CAN break things out into components, so I imagine for things that need animations you'd do that, but you could also just write the animations in CSS (which is mostly what Svelte does anyway)
@@IsaacHarrisHolt css animations are great when they fill the bill, however when they are not you want to have dom manipulation control. Svelte provides fly, slide and other animations that are not doable with plain css
That's true. You could probably achieve what you want with effects that show/hide elements and do a transition in the background, sending a message once done
Would be interesting to see some good and more complex interactivity implemented in Lustre. I know it wasnt your intent to show case that but with frameworks like this I often think that it seems slightly painful to build a great user experience.
Also, why focus on a js target with gleam? To me the erlang machine seems much more interesting. The JS frontend ecosystem is so developed at thus point
Yeah that’s a great point, I wonder how would it look like to build a reusable search-box component with autocomplete, multi-selection and accessibility.
How many messages and update functions would be needed, it also seems like all component’s state is managed at the application level which can be overwhelming.
On the other hand this seems very interesting specially for simple UIs that may not need a whole JS Framework.
I definitely would love to see more of Lustre and Gleam.
For stuff like this, Lustre DOES support a component model, so you can delegate to that when you need to. You just wouldn't store your entire application's state in such a model
As for why the JS target, it's just a different application of Gleam. Lustre is actually a full stack framework - I'll be doing into doing more with Lustre on the BEAM in future videos!
@IsaacHarrisHolt that's cool, but I'm remain unconvinced that backend is the right place to create this interactive experiences. Feels like they will always play catchup, personally I think some more headless setup is better for that. Not a knock on your video though, more a general thought
Very nice video man !
Thank you!
I’m curious and need to play with this. I’ve been loving learning gleam and looking something to use it in. Any approach to use it on web makes easier to find a place I guess, even if just for simplicity, but I’m still wary of how good js transpile… I need to try it myself and check on the ergonomics of this kind o pf solutions
Please do! Let me know what you think :) in my experience, the JS output is probably slightly less performant than vanilla JS, but the type guarantees you get outweigh that tenfold.
This is pretty cool. I have a question though. How does the browser interpret the interaction? Does it get compiled to javascript ? Is it possible to just return HTML from lustre endpoints and use something like HTMX ?
It does compile to JS, yes. You CAN use HTMX with Lustre SSR, but it's kinda pointless. Lustre is full stack, so you can use it on the backend too. I just haven't got that far in the series!
@@IsaacHarrisHolt Interesting. You can build both your FE and BE in gleam and leverage BEAM on the backend and type-safety on the frontend, right? If so, what would be the pros and cons of this approach ?
The biggest pro is that you get full stack type safety, and you get to leverage the BEAM to create a really scalable backend. Cons wise, you're locking yourself into Gleam. I don't see that as a massive problem though, to be honest
@@IsaacHarrisHoltLocking yourself into Gleam is also Pro that's why JavaScript devolopers want to write servers in node because using the same language for frontend and backend makes things easier
also the team understand each others code and make it easy for full stack devs to learn one language and be great at BE and FE
@@سنابل-الفردوس It's a great language for sure
Does it transpile into JS? Then what stops runtime code in JS (which have weak typing) to create runtime errors? What about external data, eg from API? At least, WebAssembly is typesafe
External data can be a source of errors regardless of the language. Thankfully, Gleam decoders prevent it from crashing your code and provide a nice way to handle it.
And yes, it does transpile to JS, but the type guarantees you get from Gleam's type system work really nicely, and Gleam code won't throw exceptions (unless you FFI to JS code that throws)
Doesn't Typescript have a tsconfig file that will let you be extra strict on type safety? In ur example @0:22, I'm under the impression the tsconfig you had setup w/ loose restrictions.
Very possibly - I just had it on default, but for a "type safe" language, it's still pretty bad
@@IsaacHarrisHolt Gleam with lustre looks promising. If UI 3rd party UI Libraries grow to industry standard, I'll consider using it for larger projects.
@@user-eg4qz9yc7elook at elm language its very stable ask the people who have used it in production one company said it was using it for years and finnaly got a runtime exception after having no runtime errors for years
Lustre is taking the way Elm is doing Ui so its stable also ...untill you use JavaScript inside your gleam project you might have runtime exception in your JavaScript code just like you would normally but if you implement small functions that won't give runtime exceptions you will be fine
I get the following error when trying to run the app as you do (7:40)
error: Unknown module
error: Unknown module
┌─ D:\gleam programs\app\src\app.gleam:31:26
│
31 │ fn view(model: Model) -> element.Element(Msg) {
│ ^^^^^^^^^^^^^^^^^^^^ Did you mean `lustre/element`?
No module has been found with the name `element`.
I haven't shown all the imports in my code. You'll need to import `lustre/element` like the error message says
looks very promising, but is it performant comparing to vanilla js?
It's unlikely to be exactly as performant, but browsers are so fast these days that you're not going to notice the difference.
It also depends on your code. It's really easy to write really slow JS
Looking good, I wonder what it would look like when the application is at the production scale 😂 tons of effects and states inside the modal?
You'd generally split your model and message types, and then have an update and view function per page that gets called from the main ones depending on the view!
so gleam is fullstack?
Absolutely! You can use Gleam for your backend and your frontend, and Lustre can cross both!
@@IsaacHarrisHolt amazing!
Lustre is so dang cool
I know, right. It's the only reason Gleam is any good, tbh
You creator of gleam?
Louis? Yeah he is
@@OfficialLify yup
🎉 amazing! Introduce a little bit of interactivity such as AlpineJS. It would be amazing.
But I can already add interactivity with Lustre. I'm not sure I see the need for Alpine
your videos are really good
Thank you so much! I've got more coming 😉
Looks great!
It is! Highly recommend checking it out
I am totally new to the elixir erlang thing, phoenix really something like not using json my mind broke. Can I do the same thing with gleam or am I misunderstood.
Thanks
Yes! Lustre supports sending updates over websockets. That's a future video :)
@@IsaacHarrisHolt how can I learn these? Like I learnt the struct and basics of elixir and now thinking about phoenix but I never wrote Ruby on rails so pattern is something else. I was thinking of switching to gleam and your videos really motivate me
@@cig_in_mouth3786 I would take a look at the Lustre docs, which are linked in the description
Wow the last part is amazing so I can generate a static site, so cloudflare can cache those and even my server is down, my blog will be up
@@cig_in_mouth3786 it's good stuff!
Its fast and cool , but what the problem with the syntaxe , uts totally different ? 😅
Gleam is a functional programming language, so the syntax will be different to non functional languages somewhat. That said, Gleam still aims to be readable for non functional programmers
does lustre work like Phoenix liveview under the hood, i.e. does state live on the backend?
Not in this example - here we're just serving HTML, CSS and JS (compiled from Gleam) to the frontend.
Lustre supports server components which work on the way you're describing
Why would I use that?
It's a different way of thinking and it actually makes a lot of sense. Give it a go and you'll understand :)
I'm an alternative timeline, Lua became the backbone of the web, and in that timeline, I'd be happy... 😔
What's stopping you from making it happen 👀
I feel like the view will look messed up when the html has to be nested a lot
Why? You can break it out into view functions :)
GREAT INFO!
Thanks!
Already made one 2 weeks ago. Was nice
Awesome! Are you planning to do it again?
Bro how come number/0 is 0 in gleam :(((
why
There are good reasons for it, and they're well documented!
@@IsaacHarrisHolt i bet its some optimization thing but yeah gotta be careful (i dont know enough about web dev)
@@hoteny there's a GitHub issue explaining everything here: github.com/gleam-lang/gleam/issues/895
The only big problem is the html represented in this programmatically way. If is html, should have some way to write just old simple html.
It's no different to JSX. It's still a fake-HTML that ultimately just renders to a HTML string
@@IsaacHarrisHolt Yeah i understand but, in jsx you still see the html easy syntax (mixed with big chunks of js logic wich i don't like it too). A front designer can not event touch this level of abstraction of html. Thats my point.
In that case you probably need a new frontend designer 😅 this is barely an abstraction, and should take someone 20-30 minutes to learn at worst, and not that much longer to feel comfortable.
So I can't just write xml, I have to nest functions? that is pretty off putting.
It feels a little strange, but you get used to it pretty quickly. Louis (Gleam creator) has also made a tool that translates XML to Lustre
It’s giving great content
Thanks!
Woaw, another tool to create basic CRUD stuff, that's what we needed
It's not just CRUD stuff - that's just what I've shown off here. You can do a whole lot with Lustre! Would you say React is something for "basic CRUD stuff"?
Useless complaint
Beautifull!
I know right!
Ha, the description initially about state is literally identical to how Dan Abramov talked about redux in like 2015/14.
Interesting! That's well before my time I'm afraid
(Unfortunately I couldn't give you the direct URL to another RUclips video in response because RUclips thought it was spam 🤦🏻♀️
Ah that's annoying. I'll find it :)
@@IsaacHarrisHolt there's also a really interesting talk from Mark Erikson at React Summit 2024 that gives the history of redux & shows the diagram I was talking about which originally came from a thing called Flux Architecture from Facebook.
Interesting! I do think that, while the idea behind Redux was good, there are better alternatives in the React space that fit React's rendering model better. It works well in Lustre and Elm because they were built from the group up for this approach, but iirc Redux would cause a lot of unnecessary rerenders
SSR for all the times you don’t need a SPA with offline functionality, WASM for when you do.
Enough with awful JS and the endless front end frameworks, libraries, and languages that transpile to JS.
JS is not just about having offline functionality, it's about delivering experiences that delight your users, and more importantly, ones that don't frustrate them.
I don't wanna have to wait for a server roundtrip to open a modal
@@IsaacHarrisHolt If you legitimately have users on very poor connections and a request to the server for interactions are frequent and slow enough to be noticeably worse than downloading a bunch of JS which is probably going to mostly make requests for JSON for most interactions, go for it.
Also, SSR frameworks don’t stop you from still using JS for trivial things if you want, it lets you stop using it for the other 90%+.
But for non-edge cases, let’s be real here, nobody’s “waiting” on that 20-30ms delay to show some UI element.
Especially after you’ve made them wait to download your front end framework and the endless libraries that make up the rest of the stack.
I agree about slow connections, but that's why progressive enhancement exists.
Also, 20-30ms is unrealistic for anything that also needs a database call, which a lot of things do these days.
But I do get your point, however this video was meant to show off Lustre. The next video in the series is good to use Lustre in SSR mode :)
I think Gleam is cool, but I also don't see this succeeding in the industry. Thing is modern applications are built on a ton of libraries, some really complex ones, and just like dart didn't succeed, until you can directly tap into those libraries and interop then it won't be adopted for real world products (or at least not complex apps). Also, in the end browsers run html, css and javascript. So when you need to debug or tap in very specific web behaviours, you need to do it in its original language.
Sure, but Gleam makes it VERY easy to grab those things. It's what the Plinth lib does, and writing your own FFI is easy (see my video on the topic.
@@IsaacHarrisHolt Most dev teams have enough backlog as it is. Writing FFI is also error prone if you have to do it in a rush, so greatly diminishing the advantages Gleam would bring. Strict typescript is enough, with a good linter. And my argument remains, for instance I work a lot with web standards such as web components, which are essential for our primary business concern. Luster would just be a pain point. There are other use cases where it would only create friction. Like I said, cool project, but I have my doubts it'll be adopted at scale
So, on the web component front, Lustre has its own component system which essentially just registers a Lustre view function as a web component, so it's totally interoperable with standard JS stuff.
And on your FFI point, I agree that it's an extra step, but I've so far found very few instances where I've needed it. Usually it's only to use very specialised libraries - the Gleam philosophy leans more towards implementing things yourself than pulling in loads of third party libs.
While yes, this does mean there's an initial hit to development speed, it's a massive boon in the mid- to long-term as your code is more maintainable and extensible. The proliferation of libraries in the JS ecosystem because people can't be bothered to write simple functions like left pad or, honestly, most of lodash, causes innumerable problems and build-time slowdowns.
I don't totally disagree with everything you've said, but I do think Lustre has a place. Being type safe makes it a great choice for larger applications, and Gleam's full stack type safety is also a huge boon if you're developing something more complex.
@@IsaacHarrisHolt I think gleam has a place, but where I think we disagree, is that I think it has a place in small applications. Not on enterprise grade. Writing your own left pad is not an issue. But writing a production ready, large scale and well tested library for a complex use case from scratch just won’t cut it. Let’s say you have part of your application that needs a multi-user real time text editor. You could use something like liveblocks in js land. Now with gleam, writing ffi for a code base that is 1.5mb is a project of its own. And if I need SLA and support I will have it with the official library. Now, you can probably reimplement all the protocols (because those are open source) and make it yourself in Gleam, but if I just need that for a small part of my app, and I make mine in typescript, I can probably ship that feature in less than a week. But with gleam from scratch, then you just added 1-2 months for that one feature. And it won’t be better tested that a dedicated library in JS. The language in theory allows to write safer code, but it does not negate the fact that well tested software needs a lot of engineering time. For a personal blog, or a Pokédex, then yes, Gleam is fun a fresh. But for enterprise applications, used in production, I don’t see gleam/luster making a dent any time soon. Bigger projects like flutter, backed by large corporations also didn’t make a dent. Hence my skepticism
I don't necessarily disagree here, but you've picked out one very niche use case.
Sure, if your entire app is gonna revolve around a single library you're probably better off in JS. But if that's the case, what you're building is probably not worth building anyway - you want to be building your own technologies so you have a moat nobody else can copy.
If you're only using it for a small part of the app, it's not a big deal to write a bit of FFI, and writing the whole app in a more error prone language for the sake of a single feature is not a wise choice.
I'd pay for an Udemy course on this.
You won't need to! It's all gonna come to RUclips :)
looks interesting, but in real project this architecture doesn't work
context and local state really necessary features
It does, and plenty of large apps were put into production using Elm. You have to break things down, but ultimately you still have a single model at the top of everything.
@@IsaacHarrisHolt support of it will be headacke actually. I had expreience with Elm, and to move slower and slower. And hard connections doesn't help. Split system by features too. For instance you can have platform, where is a lot of forms, graphs, chat with clients. You wanna avoid load code for graphs before open the route and etc. You need controll data load and free manually. When I use react - I can write such code, if my branch's created, I load data, when it's removed, it'll be free
I didn't cover it in this video, but Lustre has a component model you can delegate to if you really need to. It's good for really interactive things like graphs and chats, but ultimately you'd keep your page state at the top level
@@IsaacHarrisHolt maybe it needs to see for understand how is it good/bad for change opinion. I tried to use Elm and in some time I fell like I am in swamp))
Also there is really hard to do something not in the loop(outside of architecture). Gleam does not have this drawback
Give it a go!
This is exactly how RxJS and NgRX work in Angular.
Yes, it's very similar, but Lustre is designed from the ground up for this pattern
Github code is 404'd :(
I forgot to merge the PR! All sorted :)
Thanks for calling me out
Isn't this extremely slow though? Productivity wise I mean.
What you did in the first 8 minutes could be done in a minute using any modern JS framework.
That's because in the first 8 minutes I was exploring the core concepts and building up to an application with effects.
In reality you'd go straight into building your model and so forth. This video is meant for learning, not necessarily a "here's the step by step guide to create an app from scratch if you already know what you're doing". You'd skip the first few steps, as you would with JS.
@@IsaacHarrisHoltthis looks also a bit unscalable in my opinion, having a single massive enumeration for all your messages in your entire app sounds.. bad?
You'd typically break it down and have one per page that are then encapsulated by one at the top level
tailwind, tailwind, tailwind
It's great! Pairs really well with Lustre
not a fan of elm architecture. i remember when all of the rust wasm frameworks used to be based on this. they shifted to signals and hooks which is much better.
If it's not for you, that's totally fair
algo rhythm
It ain't typesafe if it is compiled to JS
It still is as long as you primarily write your program in Gleam. It's like TypeScript... but better
@@IsaacHarrisHolt Still doesn't make Javascript typesafe ;) It is time for something new...
@@iKyroja By that logic anything that compiles to native code isn't type safe
@@MoehreMoe100 Thats not the case, the difference is that it is not typesafe in runtime.
Rust. We use Rust.
Totally fair! But I don't have to fight a borrow checker 😉
@@IsaacHarrisHolt with leptos you don't have to fight the borrow checker
@@crab-cake i had to
Nice, been keeping an eye on Gleam. But the real reason I'm commenting is to say that Pevensie is a uniquely horrible name for a framework :P
Adding ':P' doesn't make a rude comment less rude 😅 but I'm curious why you think so
@@IsaacHarrisHolt Two syllable words are best for mind share, or at least something that is punchy, easy to pronounce and remember. I know Gleam community is mainly british but if you are successful you might want to have your stuff easily pronounced and understood by others. Lustre = good. Gleam = Good. Pevensie = Huh? Pensive, pvc, peevency?
Also, rude?
Yeah, I would argue that "I'm only bothering to comment because I think something you've done is horrible in such a way that nothing else is" is not the nicest of ways of phrasing something.
On your two syllable point... Laravel.
@@IsaacHarrisHolt sensitive
Again, this is just a kinda unnecessary comment? I'm not sure what you get out of it; you're deliberately doing more harm than good
These are not revolutionary techniques. Fable, ReScript, ReasonML, many more existed before Gleam.
Never claimed they were! I was just showing off the Lustre framework
@@IsaacHarrisHolt yeah but a lot content like this hypes it so.
I think I tried to provide a fair overview
who said it was revolutionary?
he was just showing off some cool tools for a cool new language
It was going so well until you added tailwind to the project
You don't have to use it 👀
@@IsaacHarrisHolt I know, it just makes me sad; and I wanted to see how styles would normally be applied to components
(The video is fantastic, the tailwind is the only bit that isn’t excellent)
You'd just use a normal stylesheet and link it in the way I do with the Tailwind one. Ultimately Tailwind is just being used as a CSS generator here
@@IsaacHarrisHolt aha I see, I assume there probably are options available for styled components type of thing - I’ll have a look
Lustre UI might be worth a look
I hate this gifs so much, all others is great
Any particular gif you don't like?
FP concepts are fine, but trying to solve real-world problems solely through pure programming is wrong. Computers are machines with mutable state. Accept it.
That's exactly why effects exist!
old man yelling at cloud! lol
@@rogergalindo7318 guess what is your cloud made of, sweet baby pony
@@Tirka100 a lot of Erlang
Gleam has ffi, you can make external JavaScript files that can mutate state of your own gleam files and types
Lustre has a JavaScript runtime for their framework that allows mutability via effects
I find your number of random memes disturbing
Thank you, I have quite the collection
@@IsaacHarrisHolt please validate your assumption that it’s a good thing
I'm a glass half full kinda guy, and I assumed that people on the internet wouldn't go out of their way to try and knock someone down, especially over something small like this, because that would be unnecessary and mean. I prefer to hope that people aren't mean :)
@@IsaacHarrisHolt I see it as helping each other to make the world better - the memes don’t contribute to the process, nothing personal. I like the intellectual part of the content but it’s hard to watch most of the time because of them )
Understandable. What would you suggest instead?
ngl I thought I was watching @Fireship
Is that a compliment 👀
@@IsaacHarrisHolt Depending on who you ask :))
@@fortwentiblazeit4177 and if I ask you? 👀