- smaller (it compiles your app, and doesn't include itself in the results)
- faster (no virtual DOM, the data to elements are mapped at compile time)
- simpler - `age = 30` no boring state management.
You're right about the web page - I wanted them to drop 'Cybernetically enhanced web apps' for 'smaller faster simpler' - there was a GitHub issue for it: https://github.com/sveltejs/svelte/issues/3269
>> Why would anyone keep creating cool new frameworks?
That’s a weird question because the answer is so obvious. There’s massive innovation in front end development because billlions of users are using ever more sophisticated applications created by millions of programmers backed by virtually infinite money. Of course people keep looking for and finding better ways to do things. Do you think that process has come to an end?
See, all the innovations are about code management and tracking. There has been nothing new for users for many years. In 2004 Gmail made AJAX popular and updating pages without reloading was a big deal. Later we had rounded corners, video without the Adobe Flash player, then came the websites that fit the screen size(the responsive web stuff) and later, we got some WebSocket stuff making possible real-time communications even snappier than AJAX.
That said, this is 15 years of time and the innovations came as browsers got better, IE died off but all these JS frameworks were always about making the codebase nicer.
Is there anything new for the users here? If not, why keep spawning new frameworks? Do these frameworks make anything better for the developers? In my experience, the JS world is a giant mess mostly because of the excess of frameworks that do the same things essentially.
That's why I felt burned out of web dev. I found out that all these frameworks that are supposed to make something easier to do are only making problems infinitely complex.
There's nothing new that you couldn't have done with 10 years old frameworks but now you need specialized knowledge on tons of tools.
The reason there are so many frameworks for UI out there is probably due to the same response you are having.
People doing a lot of web development wanted to make their lives easier but found the way other frameworks are doing it to be really convoluted. So they created their own framework which makes perfect sense to them.
As a developer getting into this, just pick any well-maintained framework and you should be able to get your job done.
> There’s massive innovation in front end development because billions of users are using ever more sophisticated applications created by millions of programmers backed by virtually infinite money.
There's no real innovation on the web. As another commenter pointed out, all the "innovation" is around tools. And even those innovations are meh at best.
Web has been busy reinventing things that desktop programming has had probably for decades, and what mobile development has had for years. And that's when we consider tools only.
On the app/client side the situation is even more bleak and dire. We get a 100th store implementation. A 1000th drag and drop implementation. A 10000th file upload manager. A 100000th state manager. A...
The "ever more sophisticated" applications can barely scratch the surface of native apps. And the actual more sophisticated apps like Figma are busy re-inventing and re-building the past 20 years of desktop UIs from scratch [1].
For people not expert or completely current in web development - especially in the context of a field not unknown for jumping on every shiny new magic bullet - it's quite reasonable to ask what major problems are arising that need a new framework learning every week.
In fact reactjs found an even simpler programming model and is leading with this new approach ... it is called hooks.
Vuejs is copying the same concept and in fact wanted to dump it’s old way to fully embrace react hooks style programming but that angered the vuejs community.
Don't get me wrong, I love hooks because I know how to use them, but there's so many easy pitfalls with them, and I constantly have to pester people about them in code reviews, if so many people in my company (and wider) misuse them by accident, it makes me me doubt how well thought out they are.
I know some people have a thing for arcane programming (for a lack of better word), but in my opinion it just makes code harder to write, understand, and even statically analyse.
Not to mention, the official lining for hooks leaves a lot to be desired for, especially because some internal React return values are treated magically by the linter (useState, useReducer to name a few) when it comes to hook dependency management.
I love React and my first experience with hooks has been mostly positive, but how is it that something as simple as data fetching is not completely sorted out by now?
I'd say for 95% of data fetches https://github.com/slorber/react-async-hook works really well without needing generator syntax or explicit promise cancellation boilerplate. I'm not the author but a satisfied user.
I don't think React is really competing with Vue as much anymore. Solving the problems of a virtual DOM in a better way is a minor improvement compared to not having a virtual DOM at all. The older virtual DOM frameworks are competing with Svelte.
I wouldn't argue that hooks is a simpler programming model, except perhaps under the hood. The Hooks API is not intuitive. I'm sure once you get a hang of it it's not hard, but as a Vue developer reading Hooks code it's not very clear.
While there was some backlash to the initial Hooks-inspired style in Vue, they went back to the drawing board and came up with a better way to explain it to the community that has gotten a much better response. I also find Vue's API for "hooks" much more intuitive/readable than React hooks, because it maps pretty well to the old style of writing code.
I have trained a dozen or so developers on React and for less experienced developers, hooks are much more intuitive because they don't rely on an abstract understanding of arbitrary lifecycle identifiers, instead, hooks are explicitly executed in application code that is logically accessible to the programmer.
I have a hard time seeing how lifecycle identifiers could be called "arbitrary" except perhaps (again) from an "under the hood" viewpoint. From an API standpoint they are explicit and extremely simple.
I don't have anything against hooks except the API. There is no way for someone who isn't intimate with the ecosystem to understand the difference between these:
The main draw is that Svelte apps have no dependencies at runtime, instead it compiles a pure vanilla js bundle that relies on existing web APIs to do updates. This is attractive to a lot of people, me included, but imo Svelte isn’t quite production ready yet (at least for complex apps). It’s great for small projects though and I highly recommend checking it out
That's partially true. The other benefit is that there's no vDOM, the way things change is reactive (kinda like in react), but there's no such thing as a no-op change. if you set something to what it was, it would trigger a partial rerender so you have to check before setting. With react you get those checks for free (provided you comply to certain restrictions).
There is even an RSS feed. It doesn't cover every breach but certainly significant verified ones - details in the site FAQ. There is even such a thing as faked breaches!
The best site I've used is haveibeenpwned.com, seems to be the go-to for most security breaches and has a tool that can notify you when some of your information has been compromised tied to an email address.
I don't like that because if you put in an email address it doesn't reveal whether you've already addressed the issue or not. It just shows if it was included in a breach, great for newbs to go "ooOOOooooOOoo" but useless for anything else.
I also alias email addresses for every service that allows a + sign in the email field, so now I have no way to notice quickly if the email was included in a leak. But I do have a way to know which service got breached or sold info if I start getting additional emails to any particular alias.
Cesium (in the +1 state) appears to be barely toxic at all. Wikipedia puts its LD50 around that of sodium. Cesium metal is extraordinarily dangerous, but it’s so reactive that none of it will survive long enough to get anywhere near the ground.
> Same line of thinking that results in depleted uranium tank shells.
Yeah, since neither was particularly toxic, and both offered significant performance gains over the alternatives. (Uranium is extremely dense, self-sharpens on impact instead of mushrooming, and catches fire after penetration giving you an incendiary payload for free. Supposedly, nothing else comes close for tank rounds)
The problem here is that armor piercing rounds need to be made of heavy metals in order to work and heavy metals are generally toxic. Even lead, which old fashioned bullets and shells are made of is toxic.
Uranium is more likely to distribute that toxicity in a convenient dust cloud, though. Tungsten and lead for the most part stay in one piece on impact.
Perhaps I should have said "not outrageously toxic" or something of that sort, because that does not sound worse than the stuff we make normal bullets out of - lead.
That's true! Lead does tend to stay more clumped up than uranium dust. But isn't it also easier for lead to become bioavailable and/or enter the water supply?
If you call “toxic” and non biodegradable “political”, I agree with you. I think you will find that countries that expect the fighting to be largely in their backyard selected Tungsten and the countries that fight “overseas” selected Uranium.
Ah, yes, because all lead bullets turn into a thousand degree cloud of dust, which you can later accidentally inhale or adsorb through your skin decades afterwards.
The concerns I have around the project are more in the FAA certification process than in the EPA. I don’t believe this is a partisan issue; it’s stalled under both Democrat and Republican administrations.
I think that the 737-Max issue will put so much more spotlight and brakes on anything that seems remotely risky, that the alternative fuels program (which was already struggling as you note) is unlikely to make serious near-term progress.
Almost tangentially, I believe that we have a viable fuel technically (G100UL) that is likely to be (or be the template for) the fuel ultimately selected, albeit possibly a decade or more in the future.
Apparently back in the day they were seriously considering ClF5 as the next generation oxidizer for rocket propellants. Implying that the rocket exhaust would to a large extent consist of HF and HCl. Yikes!
Equally funny is where someone thought that it would be a wonderful idea to burn mercaptans in a rocket, which wasn't quite as toxic, but caused the test site to become a no-go zone just from the unbearable stench.
As described in Clark's book, ClF3 was discovered first (before WWII actually). But sometime later someone managed to synthesize ClF5 as well, which had slightly better performance as a rocket fuel oxidizer. Although it retained all the other fun properties of ClF3.
