Live data from Hacker News

Astro: Ship Less JavaScript

astro.build

161–170 of 171 posts

Re: Astro: Ship Less JavaScript

#161

Earlier quoted context omitted.

Spoken like someone that has never actually created an webapp with significant scope. Reading your comments in this thread is a good reminder how strongly the clueless argue about things they don't understand.

I once created a language parser that supported over 40 languages and was used by over thousand other projects. It was interesting when I discovered it being used at my company. It wouldn't exist if I were crying about how hard life is without tools to do my job for me.

Thanks for confirming that you have no clue about frontend development and it's up- and downsides while running around with a big mouth claiming competence.

You really are an extreme case of the dunning kruger effect in action.

Re: Astro: Ship Less JavaScript

#162

Earlier quoted context omitted.

I once created a language parser that supported over 40 languages and was used by over thousand other projects. It was interesting when I discovered it being used at my company. It wouldn't exist if I were crying about how hard life is without tools to do my job for me.

Thanks for confirming that you have no clue about frontend development and it's up- and downsides while running around with a big mouth claiming competence. You really are an extreme case of the dunning kruger effect in action.

The application I mentioned is written in JavaScript and runs in both the browser and with node.

I don't think you know what Dunning Kruger is. I have never claimed to be anything great. I only mentioned I wrote an application and other people used (continue to use) it.

Re: Astro: Ship Less JavaScript

#163

Earlier quoted context omitted.

Thanks for confirming that you have no clue about frontend development and it's up- and downsides while running around with a big mouth claiming competence. You really are an extreme case of the dunning kruger effect in action.

The application I mentioned is written in JavaScript and runs in both the browser and with node. I don't think you know what Dunning Kruger is. I have never claimed to be anything great. I only mentioned I wrote an application and other people used (continue to use) it.

Or maybe you have to little self awareness that you haven't even realized how heavily it applies.

And I am surprised that I have to point it out again: that you once wrote something which people used in java script says nothing whatsoever about your experience in frontend development.

In fact, it kinda confirms that you don't have any.

You sound like a grouchy old man that got left behind and loudly complains about it.

Re: Astro: Ship Less JavaScript

#164

Earlier quoted context omitted.

Imperative UI sucks. There is a very good reason everyone is using declarative UI frameworks these days

Because they are afraid of the DOM and yell at each other about code style? This is common, but it’s still very junior thinking. The best way to minimize tech debt is to supply the most direct solution to a given problem and refactor along the way to bring similar solutions together into a single delivery. Decoration in the code is not that.

I am very familiar with the DOM and have no problem using the DOM apis. You seem to have no experience writing complex Web apps, and seem to give little thought to maintainability. I'd never hire you.

Re: Astro: Ship Less JavaScript

#165

Earlier quoted context omitted.

There is an ebb and flow in the JS ecosystem. First we get a framework. That framework is missing some key functionality or features so we get plugins and eventually a meta-framework standardising the new behaviour and maybe introducing a slightly new paradigm. That meta framework gets unwieldy and we get a ground up rewrite (new framework) that trims the fat and uses the new evolved features as first class concepts.…

Svelte has everything I need to build websites and apps. The performance, bundle size, and DX combo is unparalleled. All vanilla JS libs are plug-and-play. Building production-ready apps is incredibly fast, and done with less code than any other framework. Svelte's compiler-first approach really fixes all of my problems with the JS ecosystem. Compile-to-JS langs aren't new, but learning a whole new language has non-0…

I like Svelte a lot but haven't dived in deep yet. I'm currently waiting for SvelteKit to reach 1.0. What does your general setup look like for something relatively large and complex?

Re: Astro: Ship Less JavaScript

#166

Earlier quoted context omitted.

Because they are afraid of the DOM and yell at each other about code style? This is common, but it’s still very junior thinking. The best way to minimize tech debt is to supply the most direct solution to a given problem and refactor along the way to bring similar solutions together into a single delivery. Decoration in the code is not that.

I am very familiar with the DOM and have no problem using the DOM apis. You seem to have no experience writing complex Web apps, and seem to give little thought to maintainability. I'd never hire you.

Complexity is bad. I prefer to write simple web apps. Less is more.

> I'd never hire you.

You probably couldn’t afford me.

Re: Astro: Ship Less JavaScript

#167
post #146
post #136

Earlier quoted context omitted.

I don’t use this, but I do something similar for my personal blog. JSX (and components) is possibly the nicest templating language I’ve ever used. The problem with almost all others is that they are based on strings, so you lose type-safety (and more importantly completions) for the template parameters. However, the current ecosystem makes it really hard to use JSX for just templating. There are libraries that do exa…

I'm sorry, but how is JSX a good templating language? I much prefer Svelte's approach where you have native HTML and script/css tags within which lives native (scoped) code.

Svelte being good doesn’t stop JSX from also being good.

I haven’t used Svelte (but I’ve given it a brief look), so some of these might be wrong.

Scoped CSS is nice but not a necessity by any means (I use Tailwind). Svelte is very restrictive, as it basically forces 1 component per file. Svelte also introduces new syntax to to handle conditional HTML and iterated HTML, which I personally don’t like. With JSX, everything is just Typescript. I’m a bit torn on slots, but I think I prefer JSX’s everything is a prop approach.

Re: Astro: Ship Less JavaScript

#168

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…

> Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages

Sure. Then try to write a highly complex e-commerce frontend app with this approach and tell me how does it work out.

If notepad + HTML is enough tooling for your web development, you are not a potential user of such a framework.

Good news then, you can just ignore it!

Re: Astro: Ship Less JavaScript

#169
post #132

Earlier quoted context omitted.

Problems start when you need to change the HTML structure, the CSS file name, or having a paginated list of your blog. If you do publish a lot , you'll need some sort of CMS. These frameworks/libraries are trying to replace WordPress, because WordPress is also a mess to work with.

> you'll need some sort of CMS. You will not need a CMS unless you publish multiple articles per day (and even then...). That's far beyond anything the preceding posts were talking about, so it's not really relevant.

or unless you build a site for somebody for whom editing Markdown files is too much

Re: Astro: Ship Less JavaScript

#170
post #113

Earlier quoted context omitted.

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.

The irritating thing is that this is often possible even with modern JS. I shipped a rather complex app (though still essentially CRUD that's used internally) this winter that is Vue 3 based. It's just the Vue library itself plus the app logic, directly included using script tags. No other libraries for Vue, no build steps and so on. It just feels great that I could just immediately start fixing things on any compute…

Just from what I've heard about Deno - isn't this exactly what they are aiming for? Bring Node/JS back closer to the browsers and make use of ES modules etc?
Post reply on HN