icons VS turbo

Not sure if you already are using, but bootstrap has a lot of readymade icons for a project like this.

Bootstrap Icons

You can take the svg element from here. In the filter section type emoji and choose your desired emoji and copy the HTML. It will look like this

💡 This step is optional, but I wanted to use an icon for the close dialog button, which you'll see in a minute, but if you want to follow along, head to https://icons.getbootstrap.com/ ,scroll all the way down, copy the CDN Link, and paste it in the head of index.html

I wouldn't say it is more or less difficult, it is just a lot of work that somebody or something has to do.

Just to take an example, that Excel clone is going to need a whole lot of icons which have to come from somewhere. If you're not picky about what they look like you can find some icon set like

https://icons.getbootstrap.com/

which I picked for my RSS reader because I am using Bootstrap CSS already which itself is a low-effort choice because I use Reactstrap at work. Somebody pickier could look at free and paid icon sets or hire a graphic designer which would involve a significant amount of talking about how you want it made.

I am mainly a coder but my exact responsibilities have varied a lot from place to place. YOShInOn, my RSS reader and intelligent agent, is a one-man show which eliminates the overhead of communicating about things but means I don't get the benefit of other people's insight. I worked at an academic library where my first assignment was to take a very detailed Photoshop comp and make HTML that looked exactly like it. In other places nobody told me how it was supposed to look, or it was obvious from the get-go that I was supposed to add a new field to this form and it is going to have look like the rest of the form. I worked at a web development company where I worked on about 70 web sites in 8 months and we did projects very fast and cheap and forms that we made from scratch always followed a style guide we called "spider forms" which meant we could get better-than-average results without spending much time thinking. Where I work now I don't make decisions about the database schema except when I do, other places I was basically a DBA.

So the point is a "coder" can have varying levels of responsibility for UX, business rules: they can get very vague descriptions of what it supposed to happen and they figure it out, or I can get very detailed storyboards for everything. One way or another a lot of design and planning work has to get done.

A "low code" or "no code" system, whatever technology it is based on, is going to have to have a lot of decisions already made for you within some particular domain. Most of the worlds' business applications involve filling out forms and updating a database. But you might want a toolkit for making games that look like The Legend of Zelda with very little coding, or maybe something for making applications that put objects into your space with a Hololens or Apple Vision.

You could bust out apps really quickly if you take the defaults in a domain but if you want to make something really special the sky is the limit for the talent involved. Take a look at the credits for a major video game for instance.

Bootstrap Icons are packaged up and published to npm. We only include the processed SVGs in this package—it's up to you and your team to implement. Read our docs for usage instructions.

I also recommend checking out the docs for Stimulus and Turbo to familiarise yourself with all their features and the APIs used in this series.

https://github.com/hotwired/turbo

Turbo 8 remove typescript without using JSDOC

Experiment using Turbo to drive front-end behavior: "Turbo 7.2.0 (currently in beta) allows you to define your own Stream actions which can be any JS code you want. By combining a custom Stream action or two with web components, you can essentially drive reactive frontend behavior from the backend stupidly easily. Loooove it! 😍 […] For a turnkey example, you could check out https://github.com/hopsoft/turbo_ready " —Jared White on The Spicy Web Discord

This handles disconnection (as could be done by any destructive change to the DOM, like navigating with Turbo or htmx, I'm not even talking about using the element in a JavaScript-heavy web app) but not reconnection though, and we've exited early from the connectedCallback to avoid initializing the element twice, so this change actually broke our component in these situations where it's moved around, or stashed and then reinserted. To fix that, we need to always call addSparkles in connectedCallback, so move all the rest into an if, that's actually as simple as that… except that when the user prefers reduced motion, sparkles are never removed, so they keep piling in each time the element is connected again. One way to handle that, without introducing our housekeeping of individual timers, is to just remove all sparkles on disconnection. Either that or conditionally add them in connectedCallback if either we're initializing the element (including attaching the shadow DOM) or the user doesn't prefer reduced motion. The difference between both approaches is in whether we want the small animation when the sparkles appear (and appearing at new random locations). I went with the latter.

If you think you have seen enough Rails magic, you are mistaken my friend. Rails have a new trick up its sleeve: Hotwire. And with the magical Turbo tool that comes with it, you can create modern, interactive web applications with minimal, or sometimes no JavaScript at all, providing users with an incredibly smooth experience.

There is also Turbo and the frameworks who adopt them, Ruby on Rails, PHP Symphony and possibly others that solves the same issue in the same manner as HTMX. And the choice for HTMX is only a personal taste in this, but you should definitely learn about this, this is as cool as HTMX!

Most controversially, the Turbo framework dropped TypeScript support altogether after assessing that strong typing was the culprit behind poor developer experience.

Turbo[0] has been solving this for years. Quite the contrary, front-end frameworks have started to think "sending JSON is good, but actually sending HTML could be great!".

DHH's presentation[1] during Rails World 2023 is quite interesting in that regard, I recommend you give it a go (start around minute 16). I am actually very excited with his vision of the web.

[0] https://turbo.hotwired.dev/