Hacker Newsnew | past | comments | ask | show | jobs | submit | karhuton's commentslogin

Atleast some EU countries have ”strong authentication” services, which work like Google login, except there’s a network of trusted providers - like banks or telecoms.

To get started, you need get an account at one of the providers by physically visiting their store or office and show your ID. With their account you can sign up to the services or other auth providers fully online. Auth providers use 2-factor auth (typically website username + phone app), but they also include physical sim cards or key generator devices…

Anyways, while it’s currently used to pass some required personal info to the other party (name, social security number), it could propbably be changed to send just one bit: adult true/false.


> Probably

Your government probably doing this is as probable as the US government not starting a foreign war for Israel.


Your cheesing startegy sounds more like what would actually happen in movies, where the protagonists get a last minute dangerous idea to skip jump past the overwhelming enemies and save the day…

Funnily enough doing it yourself in the game may feel like just cheating, but watching a movie one would be celebrating along.


Ad/paywall.

Direct link to ranking data source: https://www.passportindex.org/

Menu > Rank > Global


Big thank you for your work!

Has made managing kid’s TV viewing at home easier over streaming services.


My understanding is Apple / Webkit is blocking custom element extension on native HTML elements, which would cut down this 500 line monster to:

class SaganButton extends HTMLButtonElement { … }

Anyone know the reasoning they’re blocking this?


But why bother when you can just use <button>?


The is="" customized-built-in path (extends HTMLButtonElement) is exactly what would collapse that 500-line reimplementation. Safari refusing it is why you still fall back to a full autonomous element + ElementInternals.


The only browser Apple is blocking it on is Safari: other browsers implement it just fine, and the standard passed over Apple's objections. The rationale was architectural, arguing that extending built-in components would lead either to brittle components that would break when new properties were added or causing the specification of builtin components to freeze forever to avoid such breakage. I'm not sure I buy the arguments 100%, but for sure it's not evil/incompetent board executives twirling their mustaches as they deliberately break the web: https://github.com/WICG/webcomponents/issues/509#issuecommen...


This is sort of correct on webkits side. inheritance chains especially when you don't control who is inheriting from you are going to be very brittle. The standard would probably have been better if it had been specified as a form of composition instead. However not supporting something like this is largely worse than just doing the inheritance. I'm not sure this is a hill I would die on despite largely agreeing with the webkit folks here philosophically.


That's my take on it too. The DOM itself is full of issues from its naive inheritance-happy OO design, and could use a refresh into something with better separation between data and presentation, but it's what we have right now in the real world. There's always going to be footguns, we can't put safeties on all of them. I have to wonder if it's something in the design of WebKit that makes inheritance particularly difficult to implement.

As for potential property collisions, I think the common wisdom is to just ensure the property name contains a dash, since the html5 spec goes out of its way to avoid using them. Doesn't solve brittle inheritance hierarchies in general, but it does at least stay out of the way of built-in behavior.


Standard practice in every decent frontend framework has been to create a component, that wraps the <button> without rendering its own dom node. This avoids the typical downsides of inheritance.

Can we not just do `:host { display: contents }` and use the same approach?


I’m currently living in a Northern European one and the income island thing was solved with city planning: the same area has mix of private and city owned apartment buildings. Some buildings are mix-owned too, so city owns like 50% of the apartments.

Here you’m find a person living on social security and someone with half a million apartment loan, having a neighbourly chat while their kids playtogether in the common courtyard.


These are amazing. It feels so clear to see a visual ”map” of the cooking process before you even start.

This would help coordinate two cooks to make prepping more independent.

I’m trying to figure out if an landscape Ipad, with interactive elements for extra details if needed, would be a good UI for this.

-

Edit: Showed it to my non-Engineer wife and she said ”this is horrible” after staring at it for 10 seconds. Maybe not for everyone…


Stein means rock. Wolfenstein is something like Wolf’s rock.

Eisen means Iron. You could name it Wolfeneisen?


Great work. As a European designer, really happy to see competition. Figma is slowly jacking up prices and companies are starting to lean on seats.

Figma has pretty much reached the point that they’re inventing features, pushing AI and expanding to other products (figjam, slides), because they’ve reached feature maturity on UI design long time ago and they need to make more money by expanding the other roles (PO, dev) from viewers to paid seats that actually use the tool.

So, you have a good fixed target here for Europeans: keep copying UI features from Figma and get European businesses to start switching over.

Your pricing is way too high.

World’s best UI design tool with all the extra tools? 16€. Your limited offer? 12€!

How about: 16€ ANNUAL. ”For the price of one month of Figma, get Vecti for the whole year.” - there’s a promotion text for the website too.

P.s. My list of must haves before I could consider switching:

- auto layout (w/ slots if possible!!)

- components

- very simple prototyping with click & scroll support

Prototyping is required for user testing, so I’d have to buy software for that if I’d use yours.

Edit: I want to follow your progress. Could you have a mailing list where you update your feature implementation progress - let’s say once a month?


Hi karhuton,

Thanks for your honest and thoughtful feedback.

Re: the features that you mentioned - these are definitely on my list. I thought that getting the product out there sooner was preferable to waiting longer at this stage. But I fully resonate with you, and I’m working on releasing them shortly.

Re: pricing, this is something I gave a lot of thought to, and I came to the conclusion that instead of participating in a race to the bottom, I prefer that the paying customers really see value in my product. I would like to offer a more generous free plan and find the right niche in the design field for those paying customers.

With this in mind, here’s a 50% discount code for any plan, for this community and anyone who would like to support this project: HN50

Re: the mailing list, it’s a great idea. I’ll implement a subscription list soon for the people who are interested. In the meantime, you can send me an email at contact@vecti.com with your email, and you will be the first person to get notified of the product progress.


They won’t see value unless they try. And by lowering price (maybe for a year or two?) you will compete strongly with figma and other design tools. Then you can increase price and see who sees value and who doesn’t.


Did it and can’t say yet I’d be very happy with the decision.

The first new feature we got on BOTH models was synced alarms! Why? It was already most hated feature on a stand-alone setup.

Also, their communication system between the models is a VERY noisy ad hoc wiresless audio mesh network.

(I have to admit it works better than our Wifi across the apartment – but I guess it’s because there’s no legal TX Watt limits!)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: