5 ms·
I really didn’t hear about Astro until more recently after I started playing with blogging using Next.js. I gave Astro a look over and promised myself to be op
by hoofhearted 3y ago
I really didn’t hear about Astro until more recently after I started playing with blogging using Next.js.
I gave Astro a look over and promised myself to be open minded; but I wasn’t really digging how opinionated their code was to themselves. Thousands and thousands of devs built on top of each others JavaScript improvements for years, and then Astro comes along and decides that us developers need to learn a new “.astro” syntax as well.
Imagine if Tailwind or Laravel forced you into funky .tailwind/.laravel named files because they felt a certain way about their name.
I took this as a sign that Astro might become a very money hunger shark at the first drop of blood like other popular CMS providers have done in recent memory.
I’m working on a free open source side project now for fun with the goal of helping more people create and own their own content online, without paying an arm and a leg for it.
I’d love more support and feedback if anyone has any to give :)
If you feel that developers need an open and extensible product for creating content, please give me a star, and open some PR’s and issues.
https://github.com/elegantframework/elegant-cli https://github.com/elegantframework/elegant-cli
- dmix 3y agoI develop my company front end in Vue 3 and as much as I love Vue I'm constantly looking over at React with a bit of jealousy. There is massive value in being the most popular framework. Even if it's not as nice as the other ones just the pure scale and quality of the 3rd party packages, plug and play integrations, component libraries, support posts, etc... that stuff really matters when it's your day job. One big one that's burned me is a lack of (well supported) Vue SSR integration in Ruby on Rails. I'd personally just stick to Next.
- hoofhearted 3y agoYeah I hear your complaints about Vue 3. I had the same experiences when I was building a few apps with it pre 2020. Next/Nuxt really take Vue and React to a whole new level when building a wet application. I’m very well versed in all 3 of big reactive JavaScript frameworks, and React is my go to for now. I switched from Vue to React as my default after struggling with complex data tables in Vue; when React had a bunch of libraries on GitHub that would work for my project at the time. The final nail in the coffin was a contract requirement for .Net core framework, and it came bundled with React in it already. From there, I found Next, Typescript, and Tailwind, and haven’t looked back :)
- fkyoureadthedoc 3y agoI've worked in Vue since 0.12, and have done a few React projects along the way, and mainly manage projects using React now. Overall I've seen people make a mess of both. More packages is good and bad. Any given project you picked up in Vue over the years mostly used the same router, store, etc. You didn't have to learn a new css-in-js library every time you work on a different codebase. The only thing consistent was everyone (over)using Redux, which I honestly wasn't a big fan of vs Vuex. React did / does have a much larger selection of quality ui component libraries, which is nice. The biggest upsides imo were that Vue has relatively bad typescript support vs React, and it's easier to hire shitty contractors that already know React.
- dmix 3y ago> given project you picked up in Vue over the years mostly used the same router, store, etc. You didn't have to learn a new css-in-js library every time you work on a different codebase That's a very good point
- hoofhearted 3y agoYeah, I share this same sentiment. I look at each of the 3 big reactive frameworks as different types of screwdrivers in my tool belt; each with their own pros/cons, and purposes. As commenter above said, I’ve seen a mess of all 3 frameworks; and I’ve also seen some beautiful works of art, with even Angular too lol.
- shubhamjain 3y ago> Imagine if Tailwind or Laravel forced you into funky .tailwind/.laravel named files because they felt a certain way about their name. > I took this as a sign that Astro might become a very money hunger shark at the first drop of blood like other popular CMS providers have done in recent memory. You’re reading way more than what’s reasonable. Vue, React, Svelte have their own file types. The reason has nothing to do with branding. Astro’s syntax is just different from anything that exists and having a dedicated file type makes sense.
- hoofhearted 3y agoWas .ts or .tsx not available or something?
- mrcwinn 3y agoThat would a very misleading choice. .astro files are not .ts or .tsx. Similar to .vue files, they have their own structure that needs to be interpreted.
- hoofhearted 3y ago.tsx would be a totally practical use for their files. Please explain why they needed to create their own style?
- chromakode 3y agoAstro files contain markup and separators which are not valid Typescript. They also have a different execution model.
- wruza 3y agoI just read the part about astro components and reasoning about “code fence”. How exactly do you propose to use .tsx files for their case? Specifically, how would you extract a template but run the rest of the code? I have some ideas, but they aren’t more practical than just splitting it across that fence.
- mplewis 3y agoYou can use Astro as a build system for React if you want. But using Astro files lets you do some more interesting compile-time stuff, like resizing images for production from their sources.
- ricardobeat 3y agoI suggest a second look, its actually quite nice being able to build a project with only a handful of files. The .astro extension is the glue needed to put together react/vue/svelte under the same project. You don’t even have to use any of it’s features.
- hoofhearted 3y agoHas anybody had a real world practical use for using React, Vue, and Svelte together under the same project?
- ricardobeat 3y agoIt can be a great way of migrating from one another while allowing them to coexist. But that's not the only use case - it's actually simpler to setup any of those libraries with Astro, than using their own recommended frameworks. And you get partial hydration as a default, instead of sending your entire app over the wire including all static content.