felipeccastro

This is a great point, but I wonder if it's all there is to it. I grew up in the 90s, yet for a long time preferred music from 60s to 80s (I like some things from all decades, but not as much), and I know a lot of people that find the same, regardless of when they were born. I've heard many arguments against this "nostalgia", including the always present "there's still great music, you just need to know where to look" (almost always without any specific examples).

Perhaps there's a case to be made that these older songs are still listened so much today, even by those who weren't alive back then, because by some abstract measure of soul satisfaction they were better? I'm careful with this hypothesis as I don't want to be unfair with newer generations of artists, but I don't think it's so crazy to consider either.

For example, the last 10 years or so have been greatly influenced by social media and fear of saying the wrong thing and being "cancelled". Of voluntarily silencing ourselves. How wouldn't that impact the artistic output of this generation? Couldn't this be a reason for a lot of modern music "lacking a sense of personality"?

I feel with social media we have gone pretty far into investing in appearances alone, and I think I'm not alone in this belief. Maybe the next years will be marked by more and more people sharing a wish to return to the overlooked authenticity which we used to call "art with a soul".

Build your own project for learning and make your own choices. Ideally, something that you intend actual people to use, not just toys, so real-world constraints become a factor in the decisions.

There's usually no right or wrong answer - it's all about tradeoffs. I personally prefer to keep the stack and architecture as simple as possible, but many others prefer to rely on 3rd party code as much as possible, regardless of added complexity. Sometimes my choices bite me (I have to reinvent more wheels than I was expecting), sometimes the too-many-layers-of-abstraction approach will bite too (like errors you have no idea why they happen).

Compare different solutions available to the same problem, understand their tradeoffs, and then pick what better aligns to the needs of your project. If you're working with a team, you probably will not be making that decision alone, but the process could be the same.

It depends on the needs of the mobile version. Often, a well designed responsive version of the same web app is enough. Even if it's a mobile native app, you might still be able to reuse some/most of the screens with the same html in a webview.

Even if you really needed it to be an API, you can always make the server side return either html or json depending on some request header. There's also a chance that the mobile version will be different enough from the desktop that it warrants new, custom built endpoints anyway.

The main advantage I see of traditional server side rendering (like in Rails/Django) is that you develop a single project, not two (SPA + API).

Instead of api models and client models, you just have models.

Instead of api routes and client routes, you just have routes.

Instead of unit testing api and client, you test one project.

Instead of having the client making N requests to load all the data it needs from the server (and being careful not to return more data than you need for performance reasons), you return an html with all the data it needs in a single request, and nothing more.

In the case of client stacks using SSR (like Next/Nuxt):

Instead of running the SPA on the server so the server returns the html rendered, you just make the server return the html rendered.

The benefit to the developer is higher productivity. The benefit to the end user should follow from that.

The problem is if you started with no code, can you round the rough edges? One reason we use code instead of no code is so we can extend the product in any direction that is necessary, not just the few that were anticipated by a tool.

Perhaps sharding data by geographical location could be one path - e.g. deploy one server in the US and another in Europe, each with its own database.

The whole concept of edge computing - deploying app servers closer to your users for minimal network latency - seems to go hand in hand with using an embedded database like SQLite. (I haven't tried it in production yet, but looking forward to.)

Yeah, I meant the goal was good, even if the current implementations didn't work out as expected (at least, as far as I know). But if not the token economy, what other advantage can new entrants offer to compete with the network effects of larger companies?

The goal wasn't just to replace the existing winners with others, but to do so in a way that ensured the gains of the enterprise would be more equally shared with the community. If the token economy can't do this, might there be another way? Or should we declare this a utopia and give up trying?

It was also a way that enabled new entrants to be competitive against larger business with network effects, by using a win-win structure of incentives (the earlier you join the community, the more you gain if the community takes off). If not tokens, I’m curious what else could fulfill this function.

I would love to try Deno deploy, but right now there are two deal breakers for me:

- why is the CPU time limit so low? 10ms (or even 50ms in Pro version) seems a limit very easy to blow for any sufficiently complex app

- why is there no data storage offering available? I'm not sure I see the point of edge deploys while data is still only accessible through a centralized database server. Having a way to deploy a sqlite database next to the running app seems like an easy way to realize the gains of edge deployments.

I'm currently trying Fly.io which seems to cover both of these issues, but I wonder if I'm missing something here - or perhaps this service is intended for very different use cases.

HTMX is a middle ground - using it involves not having "full-page reloads" like traditional server rendered apps, but still having the productivity of server only apps.

The main advantage I see with this approach is you'll have only one set of models/actions in the server, instead of models in server + models in client. The logic won't be spread between client and server, which make for easier testing among other benefits. For larger apps, this is a significant win.

I tried adding this to a new Rails project with no luck. Is there a sample Rails app with Sorbet fully configured (i.e. most gems typed) available on github for reference?

I've been wanting to do this switch too and have the same concern. One option worth investigating is Shoelace - https://shoelace.style/, a library of nice looking web components that you can just add to your page without setting up a whole build pipeline.

I haven't tried it yet, but this article reminds me of a CSS-only library with hstack and vstack elements: https://almonk.github.io/pylon/

"mongoose relationships" is not always what you would expect, either.

I use Rails and Mongo at work. There is a schema, enforced declaratively at the application layer (mongoid). With Rails Console querying the database ad hoc is even easier than with SQL, thanks to mongoid api and Ruby’s expressiveness. There are no transactions, but single document writes are atomic. Performance is pretty good; the one hardship I run into is that the mongoid api is so high level that you don’t see when you’re firing way too many queries at the dB (but that’s an ODM issue, not mongo’s, other ODMs might not do that).

That's great news! Is the interpreter being developed already? Anywhere we can follow the progress?

For me, it’s also because of IDE tooling. Nim syntax supports so many different call styles that when you press dot for autocomplete you always see so many options to the point it’s not helpful anymore. I’d love to know if there’s a way around that issue.

It seems a lot more similar to Vue.js than htmx.

Yes, but still I think it's great news as it looks like we can realistically make forms using native inputs only and validation, complex inputs (like date pickers) all can be setup with little to no javascript. This enables much simpler architectures, like traditional server side rendered apps, that still have a great UX.

Apparently it will be supported in the next version! https://webkit.org/blog/11648/new-webkit-features-in-safari-...

I get how static sites are useful for readonly content, but what do you mean by "financial transactions without a DB in sight"? Even in jamstack you still have an API backed by a DB, no?

I’m seriously asking for new ideas. This space is new and free to rethink incentives in all sorts of ways, it doesn’t need to repeat the same mistakes as fiat.

I like this crypto UBI idea! But without the early movers incentive to increase the coin value, how could that work?

Frameworks mean React, Vue, Angular, etc. Usually, if you make a TextInput component in React, you can't use it in Vue and vice-versa. If you create a <text-input> web component, then you can use it in any of these frameworks (or with no framework at all), like a native html tag.

Having only played a little with both (Kotlin and Nim), I enjoy Kotlin syntax but overall it feels as heavy as Java (need to setup an IDE for even getting started, choose and understand some package manager, slow compile times, etc.)

Nim feels as lightweight as Go, but with great syntax. The main thing holding me back now is the lack of libraries, but it's definitely on my radar.

I think this is where intelligence gets you in trouble. You say this as if it was the whole story, and you trust your own beliefs too much to let them go. High intelligence may not be as harmful if you use it as a tool where appropriate, and don’t use where it falls short.

I've been working with Rails for several years. First, it was fullstack rails, then we got a giant mess of jquery, tried to solve it by moving to an SPA with Vue... and since then our productivity really dropped.

While Vue works, I miss the productivity of having a single server app to maintain, instead of two. I'm considering moving back to Rails only, with the aid of some library like Unpoly for the nice ajax unobtrusive javascript helpers.

Congrats on the release, and thanks for helping to keep alive the model of server-rendered apps, while everyone else appears to be moving to SPAs.

Oh, I must have skipped that part... nice! Yeah, I'm definitely looking forward to see where that goes. Having reliable, easy distributed data storage + edge functions would certainly be a game changer.

This is the second post I see about this edge functions, and while I appreciate the advantages (decreasing network latency should definitely have an impact), will this matter much if the database is still centralized? If most edge functions still need to talk to a centralized database, won’t that be essentially the same, performance wise?

Yeah but when you do need to mutate state, why returning a new object is any clearer than modifying an object and returning it? Especially when the new object you return is going to be used to update a state tree later. Isn’t this a side effect too, even if more indirect?