201–210 of 256 posts
Earlier quoted context omitted.
I like using Nim or Rust, or TypeScript, depends on the script. If it's just a few lines, sure I'll write it in bash, but if it gets a little larger, I convert it into a real programming language.
But TypeScript doesn’t have ADTs which you stated was a hard requirement. It has some other features that can achieve similar things though, so maybe that’s good enough?
Earlier quoted context omitted.
While Astro has a lot of impressive features I found that it was the "developer experience" (god I hate that term) that was superior compared to everything I've tried before. With Hugo and Jekyll I always needed to go revisit the docs whenever I hadn't worked with it for a while. I never got to the "oh, I get this tool now" phase, where the content generation could just flow without issues. Publii was cool, but tryin…
> "developer experience" (god I hate that term) Why do you hate it? It's useful to have a term to differentiate between the experience of the person using the output of the tool (user experience) versus that of the people developing with the tool (developer experience). Honestly we need more DX improvements in this industry. Especially look at DevOps - the user experience of Chef's output (I'm picking on Chef here, i…
Nope, we need to roll back everything that happened in the last ~10 years. We at the very least need to stop sticking JS and the web stack everywhere. Use the right tool for the job, NOT pick up a shiny tool and try to do literally everything with it. NOT stumble upon solution and start looking for problems to it. Finally realize that software engineering is actual engineering that, like other forms of engineering, has a sizable impact on other people's lives. Unlike in other forms of engineering, the cost of a mistake might feel diminutive enough, but people do suffer trying to use modern software products. I wish I was joking.
It always annoys me when I read something like: To try Astro on your local machine, run npm create astro@latest in any terminal. because it doesn't make it clear to me what to do before this command will actually do anything. No, running this command will not work in any terminal.
the reason node based documentation sucks so bad, is that generally by the time you read it, it's already deprecated.
s/
I'm looking at https://docs.astro.build/en/concepts/why-astro/ and I still can't tell what's interesting and unique about this as compared to other options in this space. I acknowledge that this might be a PEBKAC situation, but I'd love to hear thoughts from people who used Next.js, Remix, or whatever and found Astro to be a revelation. It seems like Astro's creators believe "content-focused" is a differentiator, but…
For me it's the pre-rendering. I've used Next.js, Nuxt.js, Remix etc and they all server-render great. But for deploying SPAs to file-hosting (S3 + Cloud Front or Firebase Hosting) without a server runtime, you end up with empty HTML on request which is worse for SEO, social previews etc. There are solutions to pre-rendering for these stacks but they're more focused on deploying to Vercel or Netlify functions, or hav…
Might even sneak in a fourth level, "server side, but cached until marked dirty". For when you are set up for static rendering, but want to reduce backend load for rarely changing stuff. I'd expect that it would be quite powerful to have that capability inside the engine that handles rendering, on component level if necessary,and not just on some internal microservice boundary (where I think it's quite common?).
Earlier quoted context omitted.
As someone who started building web pages in the 90s, the "islands architecture" (generating HTML server-side) of Astro and others makes me laugh because it's literally what we used to do with XMLHttpRequest in IE 5/6 20+ years ago. We generated page partials (or used static ones) and pulled them in with "Ajax" (for the oldies out there) and then inserted them in the right place on the page using innerHTML. There's n…
Sure, and I was also around when XMLHttpRequest was new and innovative. And development then was awful compared to where webdev is today - I've been in the industry that entire time. And it's not quite the same thing - we're not talking about injecting server-side HTML snippets into other HTML pages (which never actually went away). This is more like optional, self-contained but fully-featured web applications that l…
Earlier quoted context omitted.
> "developer experience" (god I hate that term) Why do you hate it? It's useful to have a term to differentiate between the experience of the person using the output of the tool (user experience) versus that of the people developing with the tool (developer experience). Honestly we need more DX improvements in this industry. Especially look at DevOps - the user experience of Chef's output (I'm picking on Chef here, i…
it is subjective and overused - perfect storm for industry jargon that takes up a lot of space without saying anything more than "this thing sparks joy"
It might be overused, that’s an opinion, I don’t agree.
Earlier quoted context omitted.
Sure, and I was also around when XMLHttpRequest was new and innovative. And development then was awful compared to where webdev is today - I've been in the industry that entire time. And it's not quite the same thing - we're not talking about injecting server-side HTML snippets into other HTML pages (which never actually went away). This is more like optional, self-contained but fully-featured web applications that l…
Yes I understand (and even said) there's a difference and that things are better now, I certainly didn't imply otherwise. :-)
> it's literally what we used to do with XMLHttpRequest in IE 5/6 20+ years ago. We generated page partials (or used static ones) and pulled them in with "Ajax" (for the oldies out there) and then inserted them in the right place on the page using innerHTML.
That’s not what Astro is doing, or how it’ll mostly be used (though you could do that)
Earlier quoted context omitted.
Not getting it tbh. Why would you go nuclear and develop a React or Vue app and then not actually use it on the browser side? For content-oriented websites there are much simpler workflows based on SGML and other classic markup processing and content management practices. I mean the point of "content-oriented" and web sites in general really is that an expert in the field, rather than a web developer, can achieve use…
Developer experience writing React is much nicer than using other markup languages. That's why I use it at least, the fact that it spits out a fully JS-free website at the end is the icing on the top.
Specifically I can think of parts of the websites' functionality is editing highly technical structured data documents by highly trained domain experts.
I mean basically where years of developer productivity was thrown down a React hole when it could have been months in SGML / XML based tooling for what was required.
I can say that because I have built big solutions in both stacks, though.
Earlier quoted context omitted.
Some day we have to stop repeating this nonsense. JSX requires much more learning than simple templating, there is no inherent benefit. Even a simple conditional is more complex than your average template.
The thing is, if you know JS, then a conditional is JSX is the same as in JS. Contrast that with every new templating language under the sun which might have its own way of doing conditionals and loops and control flow. That to me is much more annoying.
I used Astro recently to rebuild my personal website/portfolio, and I really enjoyed it. I'm not a frontend dev and I quickly get overwhelmed by all of the choices and the breakneck speed that the web ecosystem changes at. Astro was exactly what I needed. It's optimized for spending most of your time writing content in markdown, but it gives you complete freedom to seamlessly add web code of any complexity you like.…
I'd like to check it out.