Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Astro: Ship Less JavaScript

astro.build

Post reply on HN
Print view View original

111–120 of 171 posts

Re: Astro: Ship Less JavaScript

#111

Post by SebastianKra »

seanp2k2 wrote: post #102

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline s…

In your argument, you could replace HTML/CSS with Assembler and JS/React/whatever with C and everything that came after.

The productivity gained from these Tools is worth it, even if some use cases could be solved without it.

Re: Astro: Ship Less JavaScript

#112

Post by mproud »

seanp2k2 wrote: post #102

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline s…

I’m all for not having dependency hell and a million frameworks. I just want some UI controls like sortables lists, tables and not have to type everything out.

Re: Astro: Ship Less JavaScript

#113

Post by pjmlp »

varrock wrote: post #107
seanp2k2 wrote: post #102

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline s…

I felt this way when approaching my personal site. I was falling into the Gatsby trap and then realized all I needed were HTML, CSS, and a few JavaScript files. I think you see over-engineered solutions as a result of career driven development and the hype around these libraries/frameworks on forums/social media.

My personal website is still based on PHP, after using XML/XSLT for a short while, I rewrote it in PHP 5 shortly after it became available.

While at work, it has been mostly Java JEE/ASP.NET since they exist.

When I play around with WebGL, it is all JavaScript modules and script tags, nothing else.

No babel, no webpack, no npm, nothing, just browser standard capabilities.

Fully agree with your point of view.

Re: Astro: Ship Less JavaScript

#114

Post by hnlmorg »

SebastianKra wrote: post #111
seanp2k2 wrote: post #102

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline s…

In your argument, you could replace HTML/CSS with Assembler and JS/React/whatever with C and everything that came after. The productivity gained from these Tools is worth it, even if some use cases could be solved without it.

That's not really fair. A lot of static sites simply don't need JS at all but they're built with it because it's deemed "best practice". My latest website, for example, has zero Javascript in it.

So much content is published in Github READMEs (typically markdown) and while Github itself will have Javascript elements, it does demonstrate that you don't need Javascript heavy sites to publish content.

I honestly think half the time the front end best practices are based around what's more intellectually interesting for developers rather than what is genuinely a better website.

Re: Astro: Ship Less JavaScript

#115

Post by smt88 »

andrewmcwatters wrote: post #98
smt88 wrote: post #96

Earlier quoted context omitted.

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…

Do you own a company paying people 7 and 8 figures? Oh, OK.

What a weird part of my comment to take out of context and fixate on...

Re: Astro: Ship Less JavaScript

#116

Post by pjmlp »

zx2391 wrote: post #46

Sometimes I wonder what was wrong with a mostly static pages in the first place. Even http://mail.google.com/mail/h/ works fine, even in a slower browser - and I would say 80% of the sites today are less complex than Gmail.

They don't look good on candidates that use github driven resume applications.

Re: Astro: Ship Less JavaScript

#117

Post by pjmlp »

kbenson wrote: post #54
andrewmcwatters wrote: post #53

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…

> 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 A few years back I chose Vue for supplementing the current little bit of web stuff I was doing because I could just include vue from a script to build a new page. The basic idea was // Vue page specific JS goes here There was ze…

I would rather go with WebComponents and lit-html, but I share the same sentiment.

Re: Astro: Ship Less JavaScript

#118

Post by jorisd »

andrewmcwatters wrote: post #53

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…

Counterpoint: build steps allow for the creation of batteries-included systems that magically do things right, instead of requiring the engineers to do it manually and know about it. This allows for horizontal scaling of workforces (just add more people and train them just enough to be proficient), and keeps knowledge requirements of new engineers low (e.g. they don't need to know about image minification and compression because the build steps takes care of that).

I do greatly enjoy no-buildstep projects for the same reasons as you've mentioned, but when working with others I've also seen them fail because of knowledge gaps in more junior engineers. Provisioning a server and CI/CD pipeline to build your projects is a lot easier than ensuring that everyone working on a project has all of the required knowledge to keep it nice and performant at runtime.

Re: Astro: Ship Less JavaScript

#119

Post by nicbou »

seanp2k2 wrote: post #102

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline s…

If I'm writing frontend code alone, I do it by hand. In a team, these heavy tools become important to keep some sort of cohesion. Even then, I'm not entirely sure.

Nonetheless I had a good cycle the other day when I had to pull 400 MB of Javascript to build a single static page.

Re: Astro: Ship Less JavaScript

#120

Post by nicbou »

varrock wrote: post #107
seanp2k2 wrote: post #102

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself. Nothing is stopping anyone from opening notepad and writing HTML with inline s…

I felt this way when approaching my personal site. I was falling into the Gatsby trap and then realized all I needed were HTML, CSS, and a few JavaScript files. I think you see over-engineered solutions as a result of career driven development and the hype around these libraries/frameworks on forums/social media.

This plus a CMS. Writing is a separate activity for me. I also like that it handles tags, metadata and pagination for me. Templating and thumbnail generation is also nice.
Post reply on HN