91–100 of 171 posts
> Of course, sometimes client-side JavaScript is inevitable. Image carousels, shopping carts wait, what? I've built shopping carts that didn't need javascript... but that was probably 15 years ago...
Earlier quoted context omitted.
> I can't tell from the homepage or the blog post what this does The passage below, on the linked page, is a dead giveaway of what it does, no? > - 100% Static HTML, No JS: Astro renders your entire page to static HTML, removing all JavaScript from your final build by default. > - On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the us…
Not really, I mean, it says No JS on one hand and then it says you can add JS, and you can even build your whole website using your favourite JS framework. So it is a little contradictory no? At least it does confuse me a little.
I don't want a build process. I don't want to have to use npm, but want the option if I desire, for something like React. And when I use React, because there is unfortunately no better option, I use `"build": "npx babel --watch public/javascripts/src --out-dir public/javascripts/. --presets react-app/prod"` and that's it. I don't want create-react-app lock-in. Eject doesn't count. That's an illusion. My favorite proc…
I don’t understand how any of this is relevant to Astro, beyond “JavaScript”.
Seems they prefer php-style save-and-refresh workflow (at the cost of doing building at runtime on client device)
JS dev: I'm burnt out by having to keep up with all the tools that are releasing all the time! Also JS dev: Look, I've built another tool!
This tool undoes a lot of harm of tool proliferation. It's one of the few JavaScript tools I'll actually approve of. If you're confused, perhaps try not lumping everybody into the homogenous “JS dev”.
I don't want a build process. I don't want to have to use npm, but want the option if I desire, for something like React. And when I use React, because there is unfortunately no better option, I use `"build": "npx babel --watch public/javascripts/src --out-dir public/javascripts/. --presets react-app/prod"` and that's it. I don't want create-react-app lock-in. Eject doesn't count. That's an illusion. My favorite proc…
You're welcome to not want a build step. I love having a build because it automates a lot of useful, difficult work. Tree-shaking is a good example. If you want to do a lot more work because of some hipster devotion to "craft" or whatever (I honestly can't understand your argument beyond its condescending tone), you do you. This is a tool for people who like to make their lives easier by automating things, and you're…
Tree-shaking is treating a symptom of not paying attention to what is in your front-end. It's purely daft to me. This sort of thinking alone is how you get karma.conf.js files with configurations built by 5 teams over 3 years who have no idea what the configuration is doing or why particular versions of Webpack are supposed to be used, or why you have to hire some senior software engineer to do nothing but comb over some gulpfiles across various projects for months at a time that haphazardly move critical shared client/server webapp files for a product moving 80% of your company's revenue, or why a simple front-end change actually requires two weeks of development time, oh and don't forget paying your QA engineer for testing this, for something requires a simple tag change but the build process is out of date, so now you have to fix that first.
You think this is some hipster cry, and yet everything I'm mentioned above is rooted in precise engineering and costs concerns, whereas I have no idea what you're talking about. You know what's a lot more work? A build step. Oh and I've never seen a build process in npm take milliseconds across a large project. But one that has none to begin with doesn't have a creeping perf issue. Because if I do have a build process, it better finish immediately, without cache.
Because if builds don't finish immediately, it's just more overhead in my CI/CD that I don't want outside of testing, and now I have to watch it, because those times only ever grow unless someone cares enough to optimize them.
This isn't a tool for people who like to make their lives easier, because anyone who was in a position to hire wouldn't use tools like this. No one knows what Astro is.
You can't hire for it. If you did, it's a waste of engineering hours to get someone to screw around using this unproven tech versus a typical React stack.
I want tech that lasts for years and years and years that isn't PHP, so I can retain engineers who actually know what they're doing and aren't screwing around relearning something for the 10th time while I pay them 6 figure salaries.
I don't have to change anyone's mind. There are some people that work faster and produce more than others, while others ask themselves how they do it while they toil away relearning.
Earlier quoted context omitted.
You're welcome to not want a build step. I love having a build because it automates a lot of useful, difficult work. Tree-shaking is a good example. If you want to do a lot more work because of some hipster devotion to "craft" or whatever (I honestly can't understand your argument beyond its condescending tone), you do you. This is a tool for people who like to make their lives easier by automating things, and you're…
There's about zero useful or difficult work I ever need to automate in front-end web development, even for large webapps. I'm curious: what is that difficult work that you're doing? Because if it's legitimately difficult, it probably shouldn't be done every single time you're building and deploying your webapp, should it? Because if you have a large webapp, "difficult" is slow , and you should be avoiding "difficult.…
1) That a build step is a bad idea.
2) That this tool, Astro, is a bad idea.
I wasn't arguing against #2 and don't care to. I don't personally use new or niche build tools myself. Some people might have different tradeoffs, but I generally agree that 100% of niche build tools (and 90% of popular ones) end up being unmaintainable technical debt.
> There's about zero useful or difficult work I ever need to automate in front-end web development, even for large webapps.
That's fine. People are free to waste enormous amounts of dev time doing things that build tools can do for them.
> You think this is some hipster cry, and yet everything I'm mentioned above is rooted in precise engineering and costs concerns
I believe you believe this, but it's not black-and-white.
The majority of the dev world (including the people making 7 and 8 figures at Facebook, Google, and Microsoft) has realized that JavaScript, HTML, and CSS are not good languages for writing web apps.
Building from other languages or DSLs (TypeScript, JSX, Svelte, Vue, etc.) allows people to have better developer ergonomics and still get code that can run in a browser. It's not really any different from using a compiler to get assembly.
If you don't build anything, you end up doing tedious optimizations in your code. Tree-shaking was an example I brought up, but there are many more possibilities: minifying, combining assets, etc. Worse, you might just be writing vanilla JS without the benefits of TypeScript or a completely separate language.
Using a poorly-maintained build tool (or an unpopular one) is definitely a problem, but throwing them all out because some of them require devs to spend some time learning them is ridiculous.
:wave: Hey everyone, one of the Astro creators here! Happy to talk Astro or answer any questions you have about what we're building. Our README has a bunch more info that we couldn't fit into the release post: https://github.com/snowpackjs/astro
Embracing the ESM* route and some concepts from Deno and other efforts will greatly simplify the build process. Right now I feel overwhelmed in large frontend projects which have custom Webpack and lots of loaders and stuff.
Going HTML first and adding JS as needed is great, but I am curious if there is any way to not have a large chain of dependencies creep in. The moment a project has a decent developer size, this happens. How do you wish to tackle this?
Earlier quoted context omitted.
There's about zero useful or difficult work I ever need to automate in front-end web development, even for large webapps. I'm curious: what is that difficult work that you're doing? Because if it's legitimately difficult, it probably shouldn't be done every single time you're building and deploying your webapp, should it? Because if you have a large webapp, "difficult" is slow , and you should be avoiding "difficult.…
You're conflating two separate arguments that you made. 1) That a build step is a bad idea. 2) That this tool, Astro, is a bad idea. I wasn't arguing against #2 and don't care to. I don't personally use new or niche build tools myself. Some people might have different tradeoffs, but I generally agree that 100% of niche build tools (and 90% of popular ones) end up being unmaintainable technical debt. > There's about z…
Earlier quoted context omitted.
Congrats on the release. For some reason when I heard of Astro, I thought it was a dynamic server-side rendering framework, not a static site builder. But I'm sure someone else will take on SSR with islands if they haven't already. Also: > Astro is and always will be free. It is an open source project released under the MIT license. > We care deeply about building a more sustainable future for open source software. A…
Elder.js supports Islands with SSR. It is also MIT. I released it as an SEO experiment as much as anything else. I’m enjoying the dev process and am committed to facilitating (myself or paying another) it’s maintenance for several years. I can do that because my prior successes can subsidize the cost. If I had to do it again, I’d probably pick another license. As a first time maintainer of a project that is hitting t…
2 decades back people built things for fun and learning. We wanted to have the freedoms and pass it on. Now anything that has any commercial value gets most attention from developers whose day job does not encourage tinkering. They use your code, ask for more and pay nothing.
This is not sustainable.
I see we’ve discovered the idea of DLLs for the web.