HN user

pdoub

111 karma
Posts4
Comments27
View on HN

Except for politicians and VCs (that each have their very own agenda), airtaxi enthusiasts give me the same vibe as "crypto enthusiasts" (not: the overly sales-y type) - I get and agree that the general, naive value proposition is "great", but it's just not feasible and there's so many lower hanging fruit that could be adressed in the meantime.

And no one seems to address the often brought-up hard questions:

- Look at the (often) questionable security theater at airports and tell me how you'd scale it down to airtaxis?

- The people that for the foreseeable future will be able to afford airtaxis? Celebrities and enterprise C-level persons, not _you_

- Even if "free sky cars that run on zero energy" popped up from nowhere? The average person has a hard time navigating in 2D and can barely leave their hands off their cellphone

- "AI will fix it"? Sure, dream on.

IIRC I've payed it via Paypal (you need an account with the official national railway provider though, which kinda makes sense for a subscription service) and it was available instantly as a QR code

While I'm also unhappy it's not being offered as a physical ticket, I can say from roughly 10 trips between 200 and 500km and a lot of local metro/bus riding that the frequency with which your ticket is actually checked shouldn't be enough to provide enough data for sophisticated tracking (esp. in comparison to "the normal amount" of GPS/tracking/movement data that smartphones already produce throughout the various apps we all have installed and that are being used on during trainrides)

Boy you'll love e.g. "My Uncle Oswald" - I've only consciously discovered Dahl while looking for dark humored books in my teens and then was surprised to find out he was the author behind a lot of very well known childrens books also!

For anyone wanting to dig deeper, I think the term "flat file CMS" has been coined quite a while ago (and is what the author is aiming at with the Git-based flow). I'd agree that "lack of options for (accessible) visual editing UIs" is true, while flat-file-, database- or API-powered (which in the end is a wrapper over a DB, usually) CMS seem to exist for any reasonably popular programming language - with different levels of maintenance/recent development happening, granted.

I've reported them to abuse@sendgrid.com hoping that - given enough complaints - some action is taken from their side. From my understanding I can't delete myself from their sendgrid campaign/list since they only allow to unsubscribe from all their types of newsletters, meaning my mail address (which is public in my GH commit history anyways, but that's missing the point) will stay

I'd be interested if anyone here can shed some light on whether this counts as a GDPR breach for European citizens (as myself)?

Seconded that in another comment in this thread. Lots of "fullstack JS saves you money since you can hire the same devs for web, backend & mobile" in Berlin, with varying success

A lot of companies I'm speaking to (mostly Berlin/Germany based startups) have drank the "we have to use JS on the frontend anyways, and by going fullstack JS we can reduce our payroll since we can focus on only hiring JS devs and they magically work on ReactNative, the React web app and the Node.JS backend at the sime time" koolaid. Works super well for some, less so for others...

Edit: Explicitly added Node.JS since that's what they rave about for making it possible.

You're always welcome to ask, of course!

Regarding choice of FE framework: Back when Jonas started the prototyping (late 2017), Vue.js seemed to fit our needs perfectly due to its simple-and-leightweight-component architecture, I guess. It was also on a sweet spot between Angular and Ember (for which had you buy in on full SPA mode), React (which wasn't as lightweight back then as it has become by now, IIRC) and having to write everything in Vanilla JS. There were a bunch of other projects (like Mithril.js, Elm and Swelte, amongst others) where I'm not sure if they already were around / popular enough for us to know them, and (perhaps understandably) an existing, healthy ecosystem and some popularity & traction for other people to be able to use & extend what would eventually become Matestack were other contributing factors, and I think Vue.js continues to shine here.

Since we're getting a lot of requests on being able to use React (and now Stimulus) with the same DSL this is definitely on the roadmap, not sure on how it's going to get prioritized though. Perhaps best if you reach out to Jonas (https://twitter.com/JonasJabari), he's a lovely guy!

As someone who's been involved with the project from day one, I'm genuinely interested in what other suggestion you have for making a living while wrinting OS software. There's a lot of discussions around sustainable open source, and I wonder what's so wrong about asking people that find the project supportable enough to become a GH sponsor (I myself am one, since leaving the company around Matestack as a co-founder due to mental health issues), asking companies that profit from it for a tiny compensation and offering premium add-ons & consulting (like, e.g., the people behind Sidekick, Trailblazer or Laravel do). Tough ask when tons of OSS is free & high quality, but then again not everybody has the luxury of either already being famous and/or being employed at $bigcorp to write OSS for a living (and we as a community perhaps should embrace different paths?!). Looking forward to a constructive discussion if you find the time :)

Also, there's a lot of "I think the DSL ends up a hinderance" in this threat from people that (perhaps) haven't tried it and judge from the looks. Maybe that's just the tough HN crowd, but every single person we've actually had using it was pretty happy to with it once they were fully onboarded :)

Technically yes, we're abstracting away complexity and as always, this comes with a price and has the potential to fall on your toes down the road ;) In my eyes the available core components get you quite far already, and then, once you hit a certain threshold, it's "just" Vue.js and a therefore - in our eyes - a managable and approachable additional effort given you have some experience in JS (it's not like we make you buy into a whole new paradigm/programming language/an outdated framework)

Thank you for the feedback!

As someone who's been involved with the project from the very beginning, this is immensly valuable to hear. Could you elaborate on how we could've gotten you to tell us? :)

(I get that GH issues is probably not the way to go, but wondering what other tool/channel would work? Also I think there'll be no silver bullet since it requires some energy & care to actually jump to action over a random project you find interesting and that will never be the case all the time, but then again this is basically what we need to work on to get people like you to try/use it!)

Technical clarification: We don't "generate" Vue.js components. Matestack generates HTML that contains component tags. Those tags reference existing Vue.js components and hand over some configuration.

This enables us/you to define interactive UI behavior by just configuring predefined Vue.js components in pure Ruby.

If one needs custom UI behavior here and there, just add your own Vue.js components (write some lines of JavaScript) and then add and controll them like you do with the predefined dynamic (=Vue.js) core components. this approach is much easier than creating a standalone JS frontend app. You might end up writing 90-99% Ruby and just some lines of JS while getting an interactive, dynamic UI (or even a PWA if you add some meta information).

Since we're not compiling Ruby into JS (I think Opal/Hyperstack does this) debugging can be done using the Vue Dev Tools in the browser, so you're not worse off there.

Most basic use cases (show/hide/rerender on event, deferred loading, onclick...) are part of the Matestack core and have good test coverage. For special use cases there's a guide on creating custom dynamic components, but yeah we could add some more info on debugging I guess. Not sure if my comment helped?

Basically, you're right. In a JS-free world this would be probably overblown (or a niche thing for Ruby fanatics).

Where Matestack shines is when it comes to very generic JS behaviour that you don't want to recreate for the 100st time in a project - just wrap it into Matestack component and tell it what to do. I suggest watching my co-founder and Matestack creater Jonas introduce the concepts behind it: https://www.youtube.com/watch?v=OY5AeGhgK7I

I feel you and yes, there's plans to make it more into a PORO core and Rails/Hanami/Sinatra/personal flavor adapters. But we're a small team and Rails has the biggest market share & ecosystem, so it's the focus right now.

Feel free to reach out if you want to help! :)

Core contributor here: Happy we made it to HN, maybe a notch too early :)

Right now there's only two not very supporting comments here. Glad the authors have solutions that work for them, but Rest + SPA is overly complicated for most small/mid sized projects in our opion.

Everyone else: Feel free to join our Gitter if you like what you see!