HN user

gg2222

56 karma
Posts0
Comments30
View on HN
No posts found.

This blog post and others are from 'security saas' that also try to make money off how bad NPM package security safety is.

Why can't npm maintainers just implement something similar?

Maybe at least have a default setting (or an option) that packages newer than X days are never automatically installed unless forced? That would at least give time for people to review and notice if the package has been compromised.

Also, there really needs to be a standard library or at least a central community approved library of safe packages for all standard stuff.

For people wanting to try something else, I recommend SolidJS and SolidStart. Personally I never tried Next.js exactly because it feels like too many decisions are being made for me without having any choice. And I don't trust frameworks like that.

Depending on the project, just write an SPA with an API server, or if it is a static website just prerender it and serve on Cloudflare. I don't get the appeal of all the complexity. If you need SSR for SEO, then SolidStart is a nice and simple solution.

Hello, congrats on the release of your framework! I myself also wrote a reactive library for my own projects long ago when jquery was still widely used.

Anyways, these days I moved from React to Solid.js so I know a bit how Solid works.

1. Solid.js also has "stores" and "createMutable" which allow deep tracking of objects and are also built on Proxy objects. Signals are great for single values, but Solid stores and createMutable are for more complex data.

2. Solid.js doesn't redraw entire components. (It's not like React.) It is fine grained and only updates the minimal exact DOM nodes required. This is why it is so fast and topped benchmarks when it first came out. https://dev.to/ryansolid/introducing-the-solidjs-ui-library-...

I found https://blog.theodo.com/2023/07/solidjs-beginner-virtual-dom... which might be a good intro explanation to it.

Yeah, until you want to add some loops and conditionals in there. That's what regular programming languages are really good at. But it's a trade-off for sure.

Solid's <For> and <Show when={}> and <Switch> tags are actually quite nice and very easy to parse visually.

Regarding the "gaslighting" comments, I kind of feel the same way as the grandparent. No offense meant and I support everyone coding new open source frameworks, but it does kind of feel like that.

I suggest doing a deep dive into Solid and even checking Ryan's blog https://dev.to/ryansolid or YouTube channel. There are a ton of concepts and good ideas to learn. He and tanstack are like at the forefront of web dev today.

Exactly. SolidJS api itself is very small, there is not much you actually have to learn. This makes it simple to reason about and at the same time gives you the confidence to wield it, which makes it actually feel more powerful.

Yes I know SolidJS 2.0 is coming. I said "it doesn't need so many major revisions", key word being "so many".

(Telling myself: damn should of put that in my original comment cause of course someone's gonna comment that.)

To the author: Yes, do consider SolidJS seriously. I find that its reactivity system is simple and the easiest to reason about, with none of the messiness and constant changes to "the best practice way to do things" like React has gone through the years.

SolidJS seems designed right so that it doesn't need so many major revisions and it feels quite stable.

It feels like an evolved React that is simpler to use.

Also its signals and stores can be used in normal .ts files, so it is easier to create re-usable "stores".

edit: BTW haven't been following Svelte but it's already version 5? I thought it was the newest framework.

Stop Killing Games 2 years ago

Their FAQ talks about using games as the first step in fighting companies discontinuing services of various kinds (not only cultural products).

It is true there is a cultural aspect for games and they mention it, but if a regulation like this passes, then it is easy to imagine what other regulations would be pushed next.

Yes it could be great for consumers, but too many regulations means it becomes harder to start and do businesses and the advantages fall to the established players and in the end there are less options in the market(s) due to monopolies so the consumer is actually worse off.

Stop Killing Games 2 years ago

If games are a kind of software, why must games face this kind of regulation when other kinds of (actually more important) software doesn't / won't?

In saying this, I'm not in favor of this regulation, actually the opposite - because imagine if this regulation passed for games and then passed for software in general next.

MMORPGs are software provided as a service, but this proposed regulation wants to make them playable even after the service provider discontinues service. If applied to software in general then that means all SaaS once it has any customers, then it has the obligation to make (and keep?) that software usable indefinitely.

And what if the reason you had to discontinue was out of your control? Eg. one of your critical service providers went out of business? Guess you'll have to recreate that service provider's whole service so your now open source software can still work on top of it before you can actually go out of business yourself.

It is just an absurd expectation for game companies to have to consider this. And in the end it just makes it harder for the smaller not-established game companies while giving the bigger companies another boost, concentrating their advantage.

Stop Killing Games 2 years ago

the idea of preserving games for future access aligns with broader movements toward digital preservation, similar to efforts in other digital media industries like film and music

And from the FAQ:

If this practice is not stopped, it may be codified into law and spread to other products of more importance over time, such as agricultural equipment, educational products, medical devices, etc.

So there is a notion of using games as a step to 'stop' companies from being able to discontinue services.

If this passes for games, next would be software in general.

Next thing you know if you develop and sell any software you will have to make sure it is usable forever. Any MacOS updates or Windows updates (or iOS/Android updates) breaking a software or app you once sold to a few people and discontinued? You will have to fix it until you die or face penalties.

Do you have software with a cloud component sold under a lifetime license? Be prepared to maintain that service forever or release its complete source code if you don't. Additionally, you would need lifetime licenses for any critical proprietary third-party components your cloud service relies on or be prepared to cover their service fees indefinitely.

While this perspective may seem exaggerated, there is always a double-edged nature to such regulations. The sword slices both ways.

I think all games/software would then convert to a service/subscription based model, cause there would be no limit to future liabilities when selling any lifetime license.

Pay monthly to play the game. Pay monthly to use any software (including downloadable software and apps.) Pay monthly to use the OS.

EDIT: Actually thinking about it, it seems this proposal wants to cover mmorpgs which already are subscription based.

In that case if the same rules applies to software in general, then any software that is subscription based would also have to be usable indefinitely even if you sold just 1 month subscription and went out of business.

This kind of creates a bad incentive where users of software / players of games might want the company to die so they can use the software or play the game for free forever.

Check this response to the article within these HN comments: https://news.ycombinator.com/item?id=40177534

Not actually flaming but quite condescending towards the article writer. Not even properly reading the article and coming to conclusions.

This is on HN which is generally more neutral towards Rust. I imagine in Rust circles these types of responses would come out a lot more.

Nice to see Solid JS mentioned in the article. Its mental model is sooo much simpler than React. It's a joy to use.

I'm lucky that I am an independent developer so I can choose to use Solid JS in my projects.

React has so many gotchas and they keep changing the 'best practices' I can't believe people still stick with it.

Also, well looks like a lot of people here don't like this style of CSS coding.

As someone who's been writing HTML since Netscape days, I find Tailwind/UnoCSS plus a modern web framework (React/Vue/Solid JS) the most productive way to develop websites ever.

The main thing is in a single React or Solid JS component, you can have all the code, html and styling for a component in one file or most of the time in one function even.

No more having to deal with jumping around between template and css files, having to search for where a class or a styling is defined, or trying to figure out how to structure or even name the css classes. No more having to make decisions like "Should I put this styling in this class or that class or in a classless selector."

For me, it just saves too much time to not use.

I was skeptical at first, but once I started using it, I could never go back.

Amazing! Thanks for explaining that.

I think that's a great solution because the biggest thing that makes me afraid of Rust webdev is compile times. Your solution seems perfect as you can get quick compile times during development.

Same. I was about to jump into learning Rust and make it my no.1 language for new projects instead of node.js + TypeScript, but once I learned about the slow compile times I stopped that thought immediately.

I second this opinion. As a (non-hobbyist) game developer, I started my current game with Godot, but after running into many issues including performance which was the final dealbreaker, I decided to port the whole game to Unity.

Finally I could focus on developing the game rather than running into engine related issues and limitations and having access to all the time saving assets in the Asset Store was (literally) game changing. Having the Asset Store is a whole new world. And as a dev with funds, paying for assets to save weeks of time was a no brainer.

Back to Godot, yes deleting stuff in Godot is pretty scary cause there is (or at least was) no way to know what effects/errors it could cause.

GUI system (at least last time I used it) was very unfortunately not well designed making it extremely hard to get consistent positionings. I feel it's so bad that just using HTML+CSS would be better cause then it would be possible to confidently put things and keep them where you want to.

And yes, overall as someone who has also used the C++ side, it does feel like some guy's homebrew engine. I felt things weren't as solidly designed as they could be. And this is talking about foundational stuff.

The C++ source code is really not modern C++ (or you could call it anti-modern C++).

I would not advise anyone to develop a game on it if your livelihood depended on your game's success.

Of course people can and will prove me wrong by still powering through and creating a successful game with it, but your time is better spent using a more mature engine like Unity or Unreal.

Even if you want to get your hands dirty and help fix bugs or add features to the engine, there is no guarantee that your PR will be merged.

Game development is probably the most riskiest type of software development already business-wise. No need to up your risk.

Of course if you are a hobby indie dev and do it just for the enjoyment of building things, then no problem.

As for Godot's future ... well it's been many, many years, but if I understand correctly they're mainly still working on 3D rendering features. There are tons of other areas that are still the same with the same limitations as they were years (5 years+) ago. I think with not so solid foundation and the pace of development, it will take many many years if ever to catch up to Unity.

I do like the way Godot engine does some things and I do hope for it's success as competition is always good. I just don't have much faith in it from what I've seen. I do hope I will be proven wrong though.

I'm wondering ... so when a user requests a page which will have a full hierarchy of blocks, how are the db queries done.

Do you first query the root to see it's content blocks, then make additional queries to load the root's children block, then make additional queries to get those blocks children blocks (ie. recursively) until there are no more children?

Does that result in too many database queries? Or do you have other ways to optimize it?