Nice! I've been writing for a long time as well. I've found writing consistently and in a stream of consciousness manner is very helpful. This being HN, you can bet that I also wrote an app for my practice ;) https://www.indelibleapp.com/
I've been looking for something just like Indelible!
I just tried it out but got the error when I tried to save a draft: "Argument schedule for data.prompt.create.schedule must not be null. Please use undefined instead." — this is from starting off of the tutorial, and trying to hit save.
It's interesting their blog post doesn't mention some of the benefits. Neither does the doc page you linked—at least it doesn't do it succinctly.
Essentially Astro lets you build sites using a JS framework like React or Vue without requiring that framework to be loaded on the frontend. By default, components are just HTML content. Super nice for building very fast static sites using a technology you may already be fluent in.
You can still add interactivity to components if you'd like—just tag components that require interactivity and Astro will bundle the requisite JS for the client.
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 useful results as an author.
Component-based UI frameworks and ecosystem has made building frontends much nicer, especially when you need some optional interactivity since you're already writing in JS.
Having that productivity and flexibility without the SPA complexity and other JS cruft has real value.
Frameworks like Gatsby didnt have any special support for interactive islands. You can choose to have:
a. A completely static site with no frontend javascript and no client side hydration, or
b. client hydration in which case all the components needed in the page will need to be loaded in the client.
If you want something in between, ie. only some sections need to be interactive, it requires jumping through some hoops eg. creating separate webpack entrypoints that call ReactDOM.render for specific DOM nodes. It is doable but more work and maintenance effort.
Astro simplifies handling for these kind of islands by using a server side templating language that is component aware and familiar to users already writing jsx.
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.
Nothing about the developer experience of React seems better than any old HTML template language (and hardly better even than plain HTML), if you're not doing any interactivity and are just going to render once and spit out the HTML.
Have you used React before? It's miles above HTML templating. I honestly don't use frameworks that have regular templating anymore, like Vue or Svelte.
I have used React. I'm a huge fan and I also prefer it over its most common "competitors" like Vue and Svelte.
But React (like Vue and Svelte) are fundamentally about interactivity. If I had a project where I knew for sure that I only wanted to generate HTML sans JS on the server (or with a static build process) I wouldn't even consider using React.
It barely even makes sense. Your "React components" would just be JavaScript functions that take props and return some JSX. None of the interesting React features and hooks would even make sense, other than maybe context (and presumably most or all popular static HTML templating tools have comparable features).
Yes. JSX is nice for escaping by default but encourages total spaghetti coding hiding app logic in the templates and various footguns like non-standard attributes className and breaking id. Running it on the server side mitigates the React performance hit somewhat but the selling point is interactivity.
What are you referring to? I am unaware of what “regular” templating you’re referring to or what react is achieving that is not available or cumbersome under react or svelte.
Think of JSX as a macro, rather than "regular" templating, which is typically string substitution.
For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.
You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).
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.
How so? Any expression is valid within JSX- ternaries, function calls, binary and unary operators are all valid. If you know JavaScript, you already know all of the control mechanisms that are valid.
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.
This is a dubious claim, since JSX is limited to expressions. If you ask people for “a conditional in JS”, they’ll very probably go for `if (…) { … } else { … }` first, not `… ? … : …` (if you can even rewrite it as a ternary). Same deal with loops: you’re limited to expressions, so you can’t use the normal way of writing a loop (and this regularly leads to mild contortions as you deal with iterables of diverse types). Therefore I’d tend to (qualifiedly) describe JSX as doing its own thing too.
Plenty of people are taught that ternary operators are evil and should never be used.
Plenty of people were also taught that proper architecture involved an AbstractGetterVisitorFactoryFactory.
That doesn't make either of those things true.
As a side note, if you find yourself wanting a loop but using `map` isn't sufficient, you should probably be preparing the values ahead of time and still using map. It'll be more efficient, and the code easier to read.
Separation of concerns is different from separation of languages.
PHP intermingled with HTML was bad because developers would do things like run database queries and other operations that caused side effects directly in the markup. Every templating system still has logic in it, and almost every templating system as a way to create custom helpers which are written in the host language.
Since API calls and calls to react's `setState` are asynchronous, and the rendering pipeline is synchronous, it is still obvious that you can't put code that makes an AJAX call in your html markup.
JSX doesn't separate languages, you're mixing HTML with TypeScript. You can absolutely do database queries in your template. What is keeping you from doing `fetch('https://side-effect.ts').then(() => doSomethingHorrible())` in your template? Or invoking an `alert()`?
You can do those things, but you're not going to capture the effect that you want. Renders happen frequently, and the render process will complete before your `fetch` resolves. As for alert, the alert will pop up immediately before the render is applied to the DOM- and will likely pop up many times more than you thought it would, assuming you're popping it up based on some state variable.
In short, you can do those things maliciously, but if you do them naively it is immediately obvious when you run the code that it's not correct.
Compare that to the original analogy to mixing raw PHP and HTML templates. Since the rendering process is blocking, you can easily stuff form handling, remote API calls, and database calls in amongst your markup, and can make it "work" even if it's not clean.
Even Laravel's blade components let you write custom components and helpers in PHP which can do all of those things from the template- you just don't see the actual SQL mixed with the HTML in the same file. The problem is still there, just now it is harder to see.
> Nothing about the developer experience of React seems better than any old HTML template language
Is that a joke? You get autocomplete from typescript and props to be fully typed functions, or any kind of object for that matter. That compares to autocomplete that's just some ad-hoc, bug ridden tools that locks you into some IDE or editor, and who cares because all the attributes have the same type (string) anyway.
and what's your experience writing other markup languages that you base this statement on? I can definitely agree it is nicer for a data intensive sites, and with effort can be made somewhat equivalent in most document heavy sites, but there are definitely some scenarios I've encountered where the match of technology to use case was disastrously not in React's favor.
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.
I've used many, Handlebars, Pug, Vue's, Svelte's, Zola's, many. They're all somewhat similar in that they try to recreate loops and conditionals, all without strong type support unlike in JSX. I've never used SGML though, another commenter told me that it is more powerful.
You have to be joking, surely? React/Vue as a mere static template languages? Dedicated static site frameworks such as Jekyll and Middleman are a much better experience. My favourite is still Perl's Template::Toolkit.
TypeScript, that's the differentiator. Having fully typed variables in the templates cannot be replicated in templating languages (well technically they might be able to but that's not as ergonomic as fact).
Talk about sledgehammer to crack a nut - honestly, why does anyone need type safety in a simple templating operation? Dynamic languages have their uses, you know. Type safety is a tool, not an ideology.
because it's nice to know whether that `post` variable contains a property `createdAt` or `published` At without leaving the template. Arguing "I don't use it why should you" is unproductive.
Agreed, you get all the benefits of type inference even in a template. It's a pain to debug template variables that don't exist, I've written enough Handlebars to know.
I basically never use dynamic languages anymore. If there aren't algebraic data types in a language I simply don't use it. Sometimes people think I'm exaggerating but it's truly great to use a language with ADTs that you get spoiled.
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.
My bash scripts are often edited, I could not imagine using a compiled language where I would have to store the source as a separate file from the executable, then compile it each time.
I'd love to know your more specific use cases, if you don't mind. I'm always happy to learn something new. Could you share some Rust that most people would script in Bash as an example? What's your build and deploy (to ~/.local/bin I presume) strategy?
> where I would have to store the source as a separate file from the executable, then compile it each time
> What's your build and deploy (to ~/.local/bin I presume) strategy?
You can run scripts as you would with bash, you don't have to manually build and run the executable. For example, `cargo run (inside the script source folder)` and `sh script.sh` do basically the same thing, end user wise. `nim compile --run script.nim` is similar in that the language compiler will automatically compile and run it together.
> Could you share some Rust that most people would script in Bash as an example?
I was creating dotfiles the other day and I didn't want to use some dotfile manager program as I had some specific steps I wanted to follow, so I started it as a bash script. Well, it got kind of annoying so I made it into a Rust script with some nice features like interactive prompts, text coloring, etc with libraries like `clap`. You can do this in bash of course, but the Rust version was more ergonomic. When I need to run the script, I just did `cargo run` and it worked great.
I see, but then your scripts are not nice compact commands.
For instance, my most-used bash script takes a file as input and opens either VIM or Emacs depending on whether the file is a .md or .org (simplified example). I run it like so:
$ n foo.org
I can edit ~/.local/bin/n and update the file, and use it immediately. I actually have my whole ~/.local/bin in version control. Having to type out e.g.
$ nim compile --run n foo.org
...would make the whole experience far less fluent. I probably would never use it.
I'm asking because I'd love to rewrite this script in e.g. Rust, but I don't see any good way to deploy it to ~/.local/bin/n.
For nim, you could use something like nimcr (https://nimble.directory/pkg/nimcr). You put a shebang in your script `#!/usr/bin/env nimcr` and then call it like a normal script.
Just alias the command in your .bashrc? e.g. `alias n="nim compile --run n"`. I'm not sure what the issue is with longer commands because the benefits of writing in a strongly statically typed language definitely outweigh a few extra characters to type, which you don't even need to do with aliases.
For what it's worth, you need only type "nim r n". If "n.nim" is marked executable and begins with "#!/usr/bin/nim r" then you also need only type "n.nim".
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?
Kinda nitpicky. Sure ADTs are a pattern in Typescript rather than a first-class entity, but they're an extremely well-supported pattern, exhaustiveness checking and all.
type ADT =
| { case : 'a', a : Number }
| { case : 'b', b : string }
function f (c : ADT) {
switch(c.case) {
case 'a' : return c.a
case 'b' : return Number.parseInt(c.b)
// case 'c' : return 0 // compile error
// case 'b' : return c.a // also compile error
}
}
For sure. I'm a big fan of type safety in larger codebases with reasonably stable domains. But when a project's small or new enough to be relatively volatile, the overhead just isn't worth it for me.
There are "templating languages" such as SGML for generating type-checked markup ie. respecting the regular content model and lexical types expressed in DTDs and other markup declarations. This results in injection-free, HTML-aware templating ie. templating engines can properly quote/escape content in attributes, CDATA sections, etc. and can enforce content model rules (that eg lists consist of nothing but list items, that script elements aren't placed where forbidden as would be required in user content such as comments provided by your web site visitors, etc.) Much more powerful than programming language types, and needed in CMSs.
I suppose it's just a different templating engine (plus some optional features for the client side). Probably as a front-end developer people are more familiar with that compared to Jinja for example? Though I think if the target is static web sites then it's simply overkill.
I wish. AFAIK it's just classic server-side rendering with full-page navigation. Mind you, that's the optimal solution in many cases. But a full-stack JavaScript web framework with something like Phoenix's channels and LiveView built in would be a killer combination.
I just started working on something like this. It's a VDOM implemented in Ruby and it streams updates to the browser via Server-Sent Events which are then applied by a tiny bit of JavaScript.
A basic counter component would look something like this:
initial_state do |props|
{ count: 0 }
end
handler(:increment) do |e|
update do |count:|
{ count: count + 1 }
end
end
render do
<div>
<p>Count: {state[:count]}</p>
<button on-click={handler(:increment)}>Increment</button>
</div>
end
There are some things I'm used to in the JavaScript world that I'm trying to introduce here. I got hot reloading which is pretty cool. And CSS modules... and static typing with Sorbet.
Events are handled on the server, so there's no need for an API... You could just talk to your database directly in your onsubmit-handler. I think that might be the largest benefit from using something like this.
If the app is deployed in a region close to you, you won't barely notice the latency.
I've been journaling for over 10 years, and I can empathize with everything you're saying here. I wrote a short guide for effective journaling here[1], and plan on writing a lot more on the topic soon. I do have some thoughts about what you've written specifically though—I hope it's helpful.
> I find it just ends up my going around in circles or getting frustrated, but I think that's just me
It's not just you. Circular thinking or rumination is very common. I find journaling helpful in these instances because it is a lot easier for me to recognize that I'm ruminating when I write my thoughts down. When they're physically in front of me, you can see the looping. When it's ephemeral thoughtstuff in your head, it can be a lot harder to recognize.
The trick (for me) is finding a way to escape that loop once I've recognized it. That's why I edit all my journal entries after an initial stream-of-consciousness braindump.
There are a number of techniques you can play with to broaden your viewpoint—write down an interpretation of events that is the opposite of what you think, imagine the situation from a caring friend's perspective, etc.
It's helpful to think of this as play, which brings me to my next thought.
> whenever i sit down to think about anything and try and make sense of anything in my life, I really struggle ... i'm just overwhelmed.
> It's also hard to do at the end of the day due to low energy.
It is possible you have set too-high expectations for your journal entries. You will look at a majority of entries, immediately after writing them, and think, "What trash, I will never want to read this again."
That's fine. You might be right—maybe it's worthless. But you'll be surprised at how frequently, a year later, you find that you were wrong. It is interesting to read those honest entries that are twisted and convoluted and just messed up.
And you will make progress over time, if you're flexible with your mindset and open to change. Most entries will be ugly and definitely not revelatory. That's fine—it's the accumulation of observations that leads to breakthroughs. Putting too much pressure on the individual entries themselves can actually be counterproductive.
> The trouble is there are so many things I can do for my mental health and improve myself ... when am i meant to get anything done after i finish work if I do all of these?
This is a real problem. I don't love the narrative around "self-care" I'm frequently exposed to. Industry has a vested interest in making you feel like their solution is one you absolutely need to incorporate, to the point that self-care becomes yet another external imposition for many people.
To be sure, all these things you list can be helpful, but getting in touch with yourself and deciding what you need and when you need it is most important.
I've been journaling for a very long time, and have thought about building a tool to encapsulate the "best practices" I've come up with over that time.
Finally gave it a shot and whipped up a site this week. I'm having fun building it while using it. I hope it'll be helpful to some other people too, but even if it isn't it's enough for me.
BranchLabs | Magento Developer | Denver, CO | Remote
This is a hands-on, remote, contract, Magento programming position. You'll be working on eCommerce platforms and CMSes like Magento, Shopify and WordPress. The core technologies you'll be working with are PHP, HTML, CSS, and JS.
Our projects are generally focused around making large, material changes to our clients' sites or designing and developing new sites from the ground up. We are heavily data-driven and provide robust tracking and reporting capabilities for our clients' initiatives.
An ideal applicant will be ready to hit the ground running with Magento.
About BranchLabs
BranchLabs is a rapidly growing eCommerce consultancy based in the LoHi neighborhood of Denver, CO.
Our reputation is built on delivering results. We take pride in the work we produce. The products we deliver are high quality inside and out, and they help our clients capitalize on real opportunities. We work closely with founders and stakeholders, combining their understanding of their business with our understanding of all things eCommerce. Together, we craft solutions that work for our clients and their customers.
About the position: This is a hands-on, contract-to-hire programming position in our Denver office (most of the time). You'll be working on eCommerce platforms and CMSes like Magento, Shopify and WordPress. The core technologies you'll be working with are PHP, HTML, CSS, and JS. Our projects are generally focused around making large, material changes to our clients' sites or designing and developing new sites from the ground up.
An ideal applicant will be ready to hit the ground running with Magento projects.
This is our first non-remote hire. As such, this will be a high impact position. Whoever fills this position will have huge opportunity to lay the groundwork of the company's future.
About BranchLabs:
BranchLabs is a small eCommerce consultancy based in the LoHi neighborhood of Denver, CO. This is our first non-remote hire.
Our reputation is built on delivering results. We take pride in the work we produce. The products we deliver are high quality inside and out, and they help our clients capitalize on real opportunities. We work closely with founders and stakeholders, combining their understanding of their business with our understanding of all things eCommerce. Together, we craft solutions that work for our clients and their customers.
Applying:
If you're interested, email a cover letter and a resume to graham@branchlabs.com and I'll be in touch. Looking forward to hearing from you!
I'm at Defcon and was able to catch this talk. Someone asked this exact question after the talk—how can you deal with spam if you you can't scan encrypted messages for trigger words on the server. I'll try to explain what I remember: Ladar mentioned that DIME heavily encourages the use of DNSSEC, so you can verify the sender is definitely coming from the domain they're representing which should reduce spam. He also said everything we're currently doing on the server-side like keyword scanning can be done on the client side. Pretty sure he also acknowledged that it's a nontrivial problem and that the team is still investigating.
I think they mean scanning on the receiver's client, not the sender's. There's no security problem there - a spammer with a rogue client will just send spam that's blocked by each client, and if you don't want to get spam, upgrade your client.
I am still doubtful that this will work - spam filtering a la GMail requires a good deal of aggregated data, being able to piece together related e-mails from many people's inboxes. It's effectively the reverse problem as NSA surveillance: instead of piecing together patterns in messages to highlight them, you piece together the patterns to block them. And so anything that blocks the NSA will make the spam filters we've come to depend upon non-functional. But that's because of lack of data, not because of client insecurity.
As nostrademons said, I meant on the receiving client, not the sender. Other than it being a potentially difficult nut to crack I don't really see any technical reason it'd be infeasible. Is that what you meant?
Advocating against certain tools absolutely makes sense. A well marketed but fundamentally flawed piece of foundational infrastructure is incredibly dangerous. Whether or not someone uses Bitcoin is not merely a decision that affects the implementer. If Patrick believes that's what Bitcoin is then it makes sense for him to be strongly advocating against it.
While, I agree with your statement; that a "fundamentally flawed piece of foundational infrastructure is incredibly dangerous".
I was not aware that patio11 nor anyone for that matter, have presented any "fundamental flaw" within the "engineering artifact" known as bitcoin. Which apparently, has also been elected to the position of "foundational infrastructure".
Advocation requires an argument, in this case one which I am actually quite interested in reading.
The deflationary fixed amount of BTC is certainly enough of a "fundamental flaw" for me. I don't think you need to be an economist to recognize the problems inherent in that.
"No credit" is an exaggeration: gold and silver (and notes redeemable for gold and silver) were the standard currencies in Europe (and probably other place) for many centuries, during which time there was plenty of lending and borrowing going on.
For most of that time, the total quantity of gold and silver in existence remained approximately constant.
"Systems" are irrelevant to the discussion of crypto-currencies. No nation ever will have an economy based on BTC. The halfway argument (if a BTC-based economy would be bad, economies exposed to some BTC would be sort-of bad) doesn't work, either: the global economy has survived many other assets that appreciated in value.
Bitcoin isn't supposed to be an asset though, it's meant to be used as a currency. Unless it's no longer a currency, and the bitcoiners have all changed their tune.
Front-end oriented programmer with a zeal to ship. I have around 20 hours of availability per week coming up I'm looking to fill. Looking for opportunities to collaborate and build something great from start to finish.
Lots of experience in Ember.js, a bit in Angular too. Also experienced in automating deploys using GruntJS and Capistrano. I've also worked extensively on the Magento eCommerce platform.
Backend languages include Ruby/Rails and PHP. Misc. languages: Bash, MySQL, MongoDB.
Let's talk about your goals, shoot me an email: graham@branchlabs.com
Wrote reviews on both Obviously Awesome[0] and StoryBrand[1] for anyone interested.
[0] https://www.goodreads.com/review/show/5369411790 [1] https://www.goodreads.com/review/show/5686301930