Diving back into a project that used Vue and it seems to be throwing an error when I add a data- attribute to a HTML element. It's a static string which I use for something else.
Spent a bit of time early this morning to knock out the most basic vector editing features in my SCI0 pic editor. The SCI0 pic byte-code is very terse; it doesn't even have closed polygons, just lines that happen to touch each other when rendered to the frame-buffer.
I'm sure this whole UI layer will need a refactor soon, but its definitely another step in a "useful" direction. Just a few core features left before a "beta" is viable.
This project is actually a byproduct of another big thing I'm working on.
Currently, I use YNAB for budgeting, but I've been putting sustained effort into getting my data out of the cloud and self-hosting everything.
I started researching options for budgeting software, and I really couldn't find anything I liked or that felt like it had enough features.
I decided, then, to just whip up something in Excel... which led me to the discovery of Office.js and the ability to build Add-ins for Excel using web tech.
Thus, vue-excel was born.
I may eventually release my budgeting tool for Excel, when it's feeling a little more mature and stable. Stay tuned... ❤️
After a bit of playing with #FastAPI, I feel like it's really, well, API-oriented. You can have templating of course, but it's just a liiiittle clumsier than returning JSON (e. g., you need to manually inject the request into it).
So I'm not entirely sure if I should stick to my original plan of mostly rendering HTML and using #htmx, or if I should go with the framework flow and make a #Vue app. Probably the latter TBH.
I'm pretty amazed with #Laravel+ #Vue+ #Inertia. In a nutshell, you don't have to write routes for your API endpoints and then routes in your frontend views, and then frontend methods to retrieve data and so on. You mostly work as if you were serving your server-side rendered views, write your models and controllers, and then you just pass the data as props to your Vue pages and components, and bang, done! I'm really having fun with my pet project. :)
When I started #Questlog the plan was to use the same tech stack as we use at work to use learnings from private projects for work and vice versa.
But Questlog doesn't have to be a single page app. And this annoys me. I have to go the extra mile for so many things that just should work.
I really think about completely rewrite the front end with #Laravel#Livewire instead of #Vue.js with #Inertia in between.
I would definitely have to think more to achieve some things I currently do, but the result would be a much faster and smaller page that isn't completely dependent on JavaScript. Most of the stuff I do would probably completely doable without JS these days.
Well, that fucking sucks. I just went into my o3 meeting with the boss and was told that I don't have a job anymore. If anybody is looking for an experienced #vue / #node / #php dev in the #Milwaukee area (or remote), let me know.
This is my second try to move to Mastodon or at least to try to convince myself to use it instead of X. Do you have any recommendations for whom I should follow? I'm interested in #webdev#frontend#javascript#react#vue#next#nuxt
phanpy.social is cool, very well-designed, but after trying it for a couple days I still think I prefer Elk. Phanpy is just too slow. Every action has several seconds of lag, especially after scrolling for a while. And this makes it completely unusable on mobile.
I wonder if this is related to their tech stacks. Phanpy uses Preact, Elk uses Vue. React sites always feel slow. I'm not very familiar with Vue, but this is a point in favor of it. Elk always feels snappy.
Honestly getting really discouraged by all these layoffs. I had high hopes in the beginning because companies typically do a lot of hiring in Q1, but with big tech companies doing sweeping layoffs again the market is being flooded with highly qualified devs.
That being said, if you need an experienced engineer, I'm here.