I think most of the complaints about moment are that it's really big (because of i18n and timezones). Obsidian isn't a web page/app, so it doesn't need to optimize bundle size too much.
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-...
> 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.
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.
Looked at SolidJS, it's primary mechanism is signals, which are essentially runtime edit maps. They have the same downside as all other types of edit maps - programmer needs to compose them manually, which becomes messy very quickly with loops and conditions.
Mapping between reactive variable and DOM element. I first heard this term in Million.js docs, but it explains very well what most 'reactive' frameworks are doing. For example, a Signal creates the mapping at runtime on first render.
It's different with solid-js, which is more of a library than a real framework.
The solid-js surface is relatively small, the jsx / css is identical to the native, the Hook simply builds the DOM once. solid-js therefore brings above all a createSignal that adds an observer where it is called in the DOM to directly update the DOM accordingly.
You might think of solid-js more as a signal primitive than a real framework.
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.
These frameworks have so many versions over time because the web, browsers, and people’s expectations of the capabilities of websites are a moving target.
Over time you’ll see many major revisions as you do in every other framework in existence.
SolidJS is extremely well crafted signaling, I like it.
However, the SolidJS ecosystem falls behind when building a full web application: The router is okay? Metadata is very separate... and SolidStart isn't pulling it all together in the way it should. Working with async is also a mess.
This makes it feel like you're having to learn 3-4 entirely separate systems.
That’s technically true but Svelte had a major paradigm shift in v4 and an extension of that paradigm in v5. The name is older, but the underlying code is newer.
They more or less did say that. They said that people are reporting these things but they haven’t detected anything. If you read between the lines, I think they’re insinuating this is mass hysteria but need to continue investigating to be sure.
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.
A reasonable requirement would be having the server code, data, and assets be released to public domain when they shut down the service. If they're not operating it, I don't see any good reason to allow people to squat on content that people want to run for themselves. A year after the last commercial offering is sufficient time.
If you run a SaaS and then shut it down, game or otherwise, then you should have to release that software under a permissive license, or to the public domain, along with any non-code assets necessary for functionality equivalent to the last commercially offered state.
The world would be better, we'd end up with fewer leeches and rent seekers.
By selling software, the developers benefit from the protections of copyrights. Mandating the release of source and assets after the end of commercial activity benefits society. This would require government to work with an archive organization of some sort - maybe offer tax incentives to any site that freely hosts said content, for up to 5 years after the release.
There are all sorts of valuable things we could be doing that benefits society and individuals instead of making it all about ruthless corporate bloodsucking and maximizing markets.
Part of the problem is sometimes the company doesn't have the license to release (i.e. "redistribute") the server code. In that case they're stuck - the law requires them to both release and not release the code.
Or what about scenarios where the company doesn't have code access to a critical dependency? It's not so unusual either - using a non-OSS DB or cloud service would qualify.
I think a better version of the law should mirror right-to-repair efforts: service providers have to release an API spec and not block attempts to point the client code at the new server, analogous to improving the "repairability" of the software with third party components. Constraining this event to when the service shuts down should mitigate economic concerns for companies.
Something like mandating the binary be released for the version operating at the end of the product's life would be good - not ideal, but since making everything open source by fiat isn't feasible, this would still allow people to operate software after it's been abandoned.
Since the only wording is "providing reasonable means to continue functioning of" when someone interprets this as extreme as "MMORPGs must run their servers in the cloud forever in case someone tries to sign on 70 years from now" and someone else interprets this as mildly as "Games with single player modes must be allowed to launch without server connectivity at the time cloud services are retired" it becomes difficult to immediately refocus talk about how "this" does/doesn't should/shouldn't will/won't apply to other software since it's not even a strong agreement on "what" we're really talking about.
That said I'd hazard a bet most people supporting this also support similar feelings about generic software as well. Sometimes it's just easier for regulation to start in one "obvious" case and spread out from there rather than hope to wait for everyone to agree to change everything at once.
" 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? "
I am neutral to the iniative but I can answer this question very clearly: Games are cultural products and you want to get the exact same experience (as you want to see the same film and not something else)
Using GIMP or Photoshop is a very different experience: Does it matter? Not so much. You can use an alternative and in case user will change. The Crew or Gran Turismo? You don't want to change so much.
>I am neutral to the iniative but I can answer this question very clearly: Games are cultural products and you want to get the exact same experience (as you want to see the same film and not something else)
Maybe this is a bit too philosophical, but: you'll never get the exact same experience. Year 1 Wow is not even the same game as year 20 WoW. Braid in 2008 won't give the same "wow" factor in 2024, be it due to stiffer competition or your opinion of the creator himself over the course of 16 years. these will affect a game no matter the state, single or multiplayer, indie or AAA.
There can be some archival benefits, but I don't think anyone would expect to start a MP game 10 years from now and get the exact experience as a day one player (for better and worse).
Some people do want to use an older version of Photoshop though. The people who do want older gimp can still pull it from somewhere. Pretty sure Adobe's been hell bent on making sure CS6 is as useless as possible.
I feel it goes the same for games (a most proprietary platform). There will be some playing pokemon Red in 2024, but most people moved on to Sword/Shield or Scarlet/Violet. Most don't necessarily care if Red/Blue is legally available (and with the 3ds shop gone, I don't think it is as of now).
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.
" 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. " Does it? That is a strong conclusion. Also we can distinguish between different solutions in this discussion anyway.
" 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. " From a regulation point this is easy to tackle: Just give some sort of limit to tackle only the big players.
Respecting basic property rights is not up for debate. If a business model relies on violating them, then it probably doesn't deserve to exist in the first place.
The problem there is that games don't usually advertise a subscription, like basicall all SaaS products do. They masquerade as a good for a one-time payment, then turn around and pretend it was a rental all along.
Note that it's not about running servers for all eternity. It's about patching out the requirement of an _official_ server and/or releasing dedicated server software, at least _after support ends_, like games have done for decades already.
MMOs can be both. If it quacks like a good, it is one, no matter what they say in the ToS/EULA. Stuff like World of Warcraft would likely be unaffected, because they are up-front about the duration you pay for.
> 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.
> 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.
The campaign is about the software that being made unusable specifically by choice of the entity responsible for it. MacOS/Windows updates breaking an existing app is completely out of scope of the initiative, and nobody will be penalized for that, it would be very unreasonable from any angle.
