For me the physicality of books give it more authority in my mind over blogs or articles. I know that's very absurd cause words are words, but I think it's a result of education.
That said it's hard to deny that books don't have comments and can get quickly outdated.
Anyway, one of my most prized possessions is a copy of A Dream of Wessex which I bought from Christopher Priest when he was clearing out his garage, that turned out to be an author's copy where he penciled in some notes on improvements he thought he should have done.
I think there's also something to be said about the effort required and barrier to entry for writing a book. You can put any fleeting thought into a blog post. If you're writing a book, it's something you know and care a lot about, and that will have an impact on the content you're providing, and make it less likely to be outdated quickly.
Comparing Rails to Flask is a bit like comparing a car to a pushbike. You'd be better comparing Rack or Sinatra from the Ruby side, or comparing it to Django on the Python side I think. They're a bit more equivalent.
The smallest Hello World (which still isn't as simple as PHP, for sure) in Ruby would be something like
Hrm, reading it again I can see how it can read as comparing big framework to PHP, then comparing small framework to PHP. Wasn't how I first read it though, and without you pointing it out I'm not sure I'd ever read it that way.
I don't disagree with the article though, its a semi-frequent discussion/lament for the old ways between me and a couple of friends, we all started on PHP.
reading it again I can see how it can read as comparing big framework to PHP, then comparing small framework to PHP.
This is what I intended, but I also don't think flask is a strawman. If you're curious about web development beyond just static files, these days there's a decent chance that you come across flask as the "simplest" option.
It's hard to judge this level of simplicity if you've worked with it for a couple years. it's like level 3 of 100 vs level 1 of 100.
But I also think while the flask/sinatra (or the janet one above) example is the pure minimum - nothing beats echo Hello world, although the complexity is hidden with the webserver/backend.
My first Ruby web application used Camping. It's a bit more complicated than the PHP example due to using a DSL to generate HTML, but still pretty easy to start wrapping your head around.
one route to becoming is a software professional is to have a delightful experience as a software amateur.
Indeed! And I appreciate that this author both mentions that, drawing a clear line from those kinds of pleasurable experiments to later endeavors, and says that it is one of the routes available.
But sometimes dumb ideas evolve into good ideas, or they teach you something that’s later used to make a good idea, or they just make you chuckle. Or none of the above. The best thing about websites is that you don’t have to justify them to anyone—you can just make them.
This may be why I avoided the most of web development during my bachelors. Working with algorithms, writing CLI apps and UI toolkits were for the most part delightful to work with. But web always felt overly complex and hacky. You have to set up a database, backend and frontend. Running the application itself is a lot of work with all the things that has to fit together. Compared to a standalone binary for a CLI app or native GUI applications it wasn't delightful at all.
I love the combination of base-level styles for semantic HTML, utility classes for adhoc adjustments, and components for self-contained functionality. Feels like they nailed the sweet spot.
The fact that it’s local to where the change needs to happen is great too because it lets you decide in the moment while working on that piece of code if it’s worth doing or not, vs having it buried in the backlog somewhere where it will definitely never get done.
Eh, Tailwind is fine. It has high locality of behavior and plays really well with server side templating. Slap TailwindUI or Daisy or Flowbite on top and you’ve got VB6-level productivity levels.
I don’t like working with tailwind but I’m inclined to agree, the fact that tailwind is popular says something, and yes it’s technically not how you “should” write styles etc but it does seem to prove valuable to people so imo that has weight
What you've just described is CSS. Well written CSS has a high locality of behavior and plays well with server-side templating. It also doesn't require multiple third party libraries to make it work well.
Tailwind is popular because it's used in a ton of popular projects and because LLM's really like Tailwind. And just cause it's popular doesn't mean it's good.
Elm Land is great! Gren is not compatible with Elm though. For a full stack Gren web framework you can take a look at https://github.com/blaix/prettynice
This is an old favorite. I love how it gets into the nitty gritty low-level details of 8-bit programming on the NES, especially the the limitations and how to get around them, but also doesn't assume any advanced knowledge. He does a really good job explaining it.
There was a point at which I really liked Elm; it was the first typed functional language I've ever used seriously, and I probably have to thank it for getting me into frontend development as well. Then I started getting frustrated with its limitations and probably wanted something more... exciting? I think I was annoyed at the lack of "native" support for some JS APIs, which meant that to interact with e.g. localStorage I would have to go through ports, and by how Evan's response to that was (and still is) to block the community from thinking about it and wait until he personally got some inspiration for how to map that API to Elm in a clean manner. I also did not like that infix operator support was just removed from one release to the next.
I'm still a bit annoyed by those things, but thinking back maybe I just got whiplash from how quickly Elm turned from something new and exciting to "boring technology" that's meant to be stable. Maybe if I tried it today I would appreciate the constraints a bit more.
I personally love the "boring" stability of Elm, but it sounds like you might like what we're doing over at https://gren-lang.org/ - Similar goals as elm from a core language perspective but actively evolving with support for more native web apis like local storage and web crypto, running on nodejs, and a desire for community input and involvement.
I definitely see the visual basic vibes. I remember seeing visual basic on a friend's computer and it's what gave me the original spark to learn programming, and it's now been my career for decades. So this is really cool to see and I'm so glad people are making things like this!
I'm really curious to know the value of investing in a niche language is when there are so many better options for compiling to wasm. Gren reminds me of Imba and Elm where they go too far with their syntax without changing any paradigms. Typescript has already proved that the best approach is JS++.
Core team member here. I would recommend trying out Elm (which is less niche than Gren) even on a small app to see that it really is changing paradigms. After getting a feel for it I found myself coding quite differently, and with a lot more confidence and peace of mind. Even in ways that translated to my work in other languages. Gren follows that same path, but with some different decisions and expanded scope.
Also the goal with targeting wasm isn't to provide another option for getting wasm. The goal is to provide a language that makes it easy to write "simple and correct" applications, and we believe wasm is just a better compile target than js (for the reasons listed in the video).
The Why Gren? section of the book covers that "simple and correct" idea and might be a good place to start to answer why you might want to choose Gren, but you're right that it's a niche language, and still very young. So you have to consider all the trade-offs that come along with that.
One of the reasons I use Obsidian is because of the lack of lock-in since the text format is just md with yaml front matter (and a small extension for wiki links that I think would be easy to patch into an existing markdown parser), and I'm glad to see they're continuing that with .base syntax (so far, anyway) being easy to work with.
I get what you mean, but when you really lock-in with bases or obsidian plugins like tasks and dataview, you really rely on thing, not being that easily to replicate if obsidian would go paid or something else.
This is part of why I don't go super hard on plugins. I have some Dataview tables showing books I haven't finished and so on, but all the "meat" is in the tags of the files for each book.
But that's just a link to: https://help.obsidian.md/bases@blaix You should edit the link to this, as is, it seems like spam (better word needed), requiring clicking through 2 redirects.
Thanks. Looks like the link has already been edited. I tried posting the direct link but since I'm still a new user and it was a new domain the site would not allow it. And I missed that I wasn't linking to the original mastodon server. For what it's worth, this link is exactly where I first saw this feature mentioned. But thanks for the heads up, I will avoid roundabout links like this in the future.
I've been using the Tasks community plugin but this looks like it might fit my needs much better. More fine-grained control and using frontmatter properties instead of emoji inline syntax.
Each task as its own note, yeah. Which is originally how I liked to manage things, and had my own custom tool for it before moving to Obsidian because I wanted something that worked well on mobile.
I like knowing that in another two decades from now I will still be able to compile my game without needing to pirate an ancient version of a broken game engine.
I feel the same way about a lot of javascript frameworks and tooling...
I remember having problems with the 1Password integration last time I tried switching to LibreWolf. Anyone have experience with that? Maybe I just needed to loosen some of the default settings. Would much rather opt-in to that kind of stuff anyway.
For me the physicality of books give it more authority in my mind over blogs or articles. I know that's very absurd cause words are words, but I think it's a result of education.
That said it's hard to deny that books don't have comments and can get quickly outdated.
I'm very glad books don't have comments.
If you use a library they might have.
Anyway, one of my most prized possessions is a copy of A Dream of Wessex which I bought from Christopher Priest when he was clearing out his garage, that turned out to be an author's copy where he penciled in some notes on improvements he thought he should have done.
I think there's also something to be said about the effort required and barrier to entry for writing a book. You can put any fleeting thought into a blog post. If you're writing a book, it's something you know and care a lot about, and that will have an impact on the content you're providing, and make it less likely to be outdated quickly.
Comparing Rails to Flask is a bit like comparing a car to a pushbike. You'd be better comparing Rack or Sinatra from the Ruby side, or comparing it to Django on the Python side I think. They're a bit more equivalent.
The smallest Hello World (which still isn't as simple as PHP, for sure) in Ruby would be something like
They're not comparing ruby to python though, they're comparing different framework's approaches and how they still don't match a one line .php file.
Hrm, reading it again I can see how it can read as comparing big framework to PHP, then comparing small framework to PHP. Wasn't how I first read it though, and without you pointing it out I'm not sure I'd ever read it that way.
I don't disagree with the article though, its a semi-frequent discussion/lament for the old ways between me and a couple of friends, we all started on PHP.
This is what I intended, but I also don't think flask is a strawman. If you're curious about web development beyond just static files, these days there's a decent chance that you come across flask as the "simplest" option.
It's hard to judge this level of simplicity if you've worked with it for a couple years. it's like level 3 of 100 vs level 1 of 100.
But I also think while the flask/sinatra (or the janet one above) example is the pure minimum - nothing beats echo Hello world, although the complexity is hidden with the webserver/backend.
My first Ruby web application used Camping. It's a bit more complicated than the PHP example due to using a DSL to generate HTML, but still pretty easy to start wrapping your head around.
https://github.com/camping/camping/blob/main/book/02_getting_started.md
Indeed! And I appreciate that this author both mentions that, drawing a clear line from those kinds of pleasurable experiments to later endeavors, and says that it is one of the routes available.
Loved that quote. And this one:
This may be why I avoided the most of web development during my bachelors. Working with algorithms, writing CLI apps and UI toolkits were for the most part delightful to work with. But web always felt overly complex and hacky. You have to set up a database, backend and frontend. Running the application itself is a lot of work with all the things that has to fit together. Compared to a standalone binary for a CLI app or native GUI applications it wasn't delightful at all.
Not crazy about the "windoze sux" tone towards the end but love seeing Codeberg getting more love!
It does, though.
Combative/edgy tone without substance is typically considered immature, but the substance for the criticism is there.
Sent a title change suggestion for the typo, but please @blaix fix it upstream? :)
Sorry I'm not sure what you're referring to?
The GitHub repo description reads "framwork".
Hah, thanks! Fixed.
I love the combination of base-level styles for semantic HTML, utility classes for adhoc adjustments, and components for self-contained functionality. Feels like they nailed the sweet spot.
Also learning that HUG is an acronym I can use when I talk about HTML is really fun.
The fact that it’s local to where the change needs to happen is great too because it lets you decide in the moment while working on that piece of code if it’s worth doing or not, vs having it buried in the backlog somewhere where it will definitely never get done.
Eh, Tailwind is fine. It has high locality of behavior and plays really well with server side templating. Slap TailwindUI or Daisy or Flowbite on top and you’ve got VB6-level productivity levels.
Absolutely nailed it in 2 short sentences. The utility class of comments right here.
I don’t like working with tailwind but I’m inclined to agree, the fact that tailwind is popular says something, and yes it’s technically not how you “should” write styles etc but it does seem to prove valuable to people so imo that has weight
What you've just described is CSS. Well written CSS has a high locality of behavior and plays well with server-side templating. It also doesn't require multiple third party libraries to make it work well.
Tailwind is popular because it's used in a ton of popular projects and because LLM's really like Tailwind. And just cause it's popular doesn't mean it's good.
We're using https://elm.land/, but I'd love to switch to Gren if it was supported (don't mind a fork).
Elm Land is great! Gren is not compatible with Elm though. For a full stack Gren web framework you can take a look at https://github.com/blaix/prettynice
This is an old favorite. I love how it gets into the nitty gritty low-level details of 8-bit programming on the NES, especially the the limitations and how to get around them, but also doesn't assume any advanced knowledge. He does a really good job explaining it.
There was a point at which I really liked Elm; it was the first typed functional language I've ever used seriously, and I probably have to thank it for getting me into frontend development as well. Then I started getting frustrated with its limitations and probably wanted something more... exciting? I think I was annoyed at the lack of "native" support for some JS APIs, which meant that to interact with e.g.
localStorageI would have to go through ports, and by how Evan's response to that was (and still is) to block the community from thinking about it and wait until he personally got some inspiration for how to map that API to Elm in a clean manner. I also did not like that infix operator support was just removed from one release to the next.I'm still a bit annoyed by those things, but thinking back maybe I just got whiplash from how quickly Elm turned from something new and exciting to "boring technology" that's meant to be stable. Maybe if I tried it today I would appreciate the constraints a bit more.
I personally love the "boring" stability of Elm, but it sounds like you might like what we're doing over at https://gren-lang.org/ - Similar goals as elm from a core language perspective but actively evolving with support for more native web apis like local storage and web crypto, running on nodejs, and a desire for community input and involvement.
I never used Elm, but I've really enjoyed using Lustre which is essentially Elm as a Gleam library.
Lustre and Gleam are fantastic. It's really cool to see the impact of elm on other languages and frameworks.
I am loving this resurgence in sqlite. And my favorite part of the README: "What can you do with this? I don't know but it sounds cool!"
I definitely see the visual basic vibes. I remember seeing visual basic on a friend's computer and it's what gave me the original spark to learn programming, and it's now been my career for decades. So this is really cool to see and I'm so glad people are making things like this!
Visual Basic was peak programming.
Have you seen Gambas?
I'm really curious to know the value of investing in a niche language is when there are so many better options for compiling to wasm. Gren reminds me of Imba and Elm where they go too far with their syntax without changing any paradigms. Typescript has already proved that the best approach is JS++.
Core team member here. I would recommend trying out Elm (which is less niche than Gren) even on a small app to see that it really is changing paradigms. After getting a feel for it I found myself coding quite differently, and with a lot more confidence and peace of mind. Even in ways that translated to my work in other languages. Gren follows that same path, but with some different decisions and expanded scope.
Also the goal with targeting wasm isn't to provide another option for getting wasm. The goal is to provide a language that makes it easy to write "simple and correct" applications, and we believe wasm is just a better compile target than js (for the reasons listed in the video).
The Why Gren? section of the book covers that "simple and correct" idea and might be a good place to start to answer why you might want to choose Gren, but you're right that it's a niche language, and still very young. So you have to consider all the trade-offs that come along with that.
One of the reasons I use Obsidian is because of the lack of lock-in since the text format is just md with yaml front matter (and a small extension for wiki links that I think would be easy to patch into an existing markdown parser), and I'm glad to see they're continuing that with .base syntax (so far, anyway) being easy to work with.
I get what you mean, but when you really lock-in with bases or obsidian plugins like tasks and dataview, you really rely on thing, not being that easily to replicate if obsidian would go paid or something else.
I like that there's at least a little less lock in since the format is yaml instead of a custom query language.
This is part of why I don't go super hard on plugins. I have some Dataview tables showing books I haven't finished and so on, but all the "meat" is in the tags of the files for each book.
Real link https://mas.to/@obsidian/114546538858212821
But that's just a link to: https://help.obsidian.md/bases @blaix You should edit the link to this, as is, it seems like spam (better word needed), requiring clicking through 2 redirects.
Thanks. Looks like the link has already been edited. I tried posting the direct link but since I'm still a new user and it was a new domain the site would not allow it. And I missed that I wasn't linking to the original mastodon server. For what it's worth, this link is exactly where I first saw this feature mentioned. But thanks for the heads up, I will avoid roundabout links like this in the future.
I've been using the Tasks community plugin but this looks like it might fit my needs much better. More fine-grained control and using frontmatter properties instead of emoji inline syntax.
I'm interested to know how Bases would replace tasks in your workflow. Would each task be a note/file rolled up into a Base?
Each task as its own note, yeah. Which is originally how I liked to manage things, and had my own custom tool for it before moving to Obsidian because I wanted something that worked well on mobile.
Hm, actually I guess there's no reason I couldn't use this and the tasks plugin together.
Love this line:
I feel the same way about a lot of javascript frameworks and tooling...
I remember having problems with the 1Password integration last time I tried switching to LibreWolf. Anyone have experience with that? Maybe I just needed to loosen some of the default settings. Would much rather opt-in to that kind of stuff anyway.
I used LibreWolf until very recently, and I had no issues with 1Password. The plugin worked exactly as it did with other Firefox-based browsers.