The training set is huge and model "forgets" some of the stuff, providing docs in context makes sense, plus docs could be up to date comparing to training set.
Javascript has a compiler called Babel, which plays a huge role in modern web development. It is in fact a transcompiler, meaning it doesn't turn your javascript into bytecode, it is just transpiling stuff without changing the level of abstraction.
React Compiler is just a babel plugin for automatic performance improvement, memoization specifically, for never perfectly memoized React code.
Can library have compiler? Well why can't it? For example stdlib has a compiler, because C does.
Nothing in that is actually doing what a compiler does above and beyond what babel, swc and esbuild are capable of.
What they've added is wrapping your code in more memoization functions, basically. All stuff that doesn't fundamentally transform the code, aside from inserting more `useMemo` and the like.
The JSX macro - which is itself already optional but everyone uses it - is just that, a handy macro with implementations available in every common bundler and transpiler out there.
I'd say pull request should be reverted if necessary, but an idea that each commit should be revertable and expectation that project should work after it is unneeded complexity for me.
Smaller, cleaner, and faster code while still focusing on dynamic interfaces? Svelte or SolidJS
Focus on server-side HTML rendering with little to no browser dynamism? PHP (It really is quite nice now.)
Focus on server-side HTML rendering with some browser dynamism? HTMX + server framework (PHP, Django, Go templates, etc.)
Getting a job as quickly and easily as possible, especially at larger companies? React or Angular (You're a cog in the machine, but cogs often get better paychecks to deal with multi-megabyte code blobs.)
Can't decide between code elegance/performance and finding a job, so you're willing to compromise a little on both? Vue
React really is pretty good as long as it keeps evolving. Innovations tend to come from new frameworks such as Svelte and SolidJS, and then React adopts them — this new compiler is an example.
React is hobbled by the need to retain backward compatibility, but it is boosted by sheer scale and a solid underlying philosophy, design, and engineering.
Someday, we will probably find a fundamentally better philosophy for UI frameworks, but I don't know yet what it will be. React replaced its MVC predecessors with a functional approach, the Flux model.
AFAICT, if you pick any of the others options you'll have to refactor your site every 3-4 years as all the tools bit rot. One won't run on the latest version of node so you upgrade node. Now 2 other libraries fail and require an upgrade. Now another library fails because it's not compatible with those upgrades, repeat. You thought you were just going to fix a bug or add a small feature that would take you a few hours but now you've got few days/weeks of refactoring before you can even start.
I'm with you on that. Lit is the way to go. It is in the 3.x version but it never released a real breaking change but also it doesn't carry bloat for compatibility as it is a thin layer on browser APIs. The core dev team is great too, not looking to jump the next hype bandwagon.
WebComponents are the future (and the present) of web development.
Now is WebComponents prime time. Libraries like Lit have just a little bit of code that makes the DX of webcomponents be top notch. Some people like to use TS with it but what I love about lit is how powerful it is with just vanilla JS and no compile/bundling/building phase. Development directly in the browser, sane stack traces and faster than anything I've seen.
Lit code is similar to what React was until the 16 version.
No... You should learn the most popular frameworks. Why just react? Build the same project with svelte, Vue, angular. You'll learn a lot which applies across any web framework, that's more important.
If you're messing around and having fun, sure learn some hipster frameworks.
If you want to have highly saught -after skills years from now, basic web Dev with most popular frameworks on top is by far the safest bet.
You should at least google (or ask chat GPT?) about Lit before calling it some hipster framework. Lit is the old Polymer.js and being under development for the past 10 years. Still small, still making the best use of web standards.
I agree with you about knowing a bit of most popular frameworks tho, they are quite interchangeable and very often adopt each others famous features. The biggest advantage of choosing Lit as your main tool is that it is the one that is more integrated with web components that won't go anywhere, anytime.
I know what lit is, a former colleague tried to pitch my manager on migrating to it because he too loved web components and we were investigating microfrontends.
Turns out, it's quite trivial to publish react and angular components as web compenents.
That completely took the value prop away from lit, and in terms of DX and library support, the other frameworks won easily
I'm not saying don't use smaller frameworks. I'm saying the safest future bet is learning the big ones
Sorry for off-topic, just wanted to say that the price page on mullvad.net is the best one I saw comparing to other SaaS. Everything simple and straight forward!
> Typescript is a pretty nice language but the tooling around it is practically unusable.
I work mainly with node/ts and totally agree, maybe just add that by tooling it is whole ecosystem as well. This problem is not visible if you work either with relatively small code base or new code base. But as soon as you have something old and big you'll see where the pain comes from.
> I am thinking is in IT industry 'too clever and hardworking' the same as 'stupid and hardworking'?
The thought of someone stupid turning out the most code in a team used to make me shudder. But then I got some not so bright people on my team.
It's true that stupid left to their own devices turns out terrible code. But they have their strengths. Janitors for example are often classed as stupid, but a stupid and hardworking janitor will do a far better job than of the other types.
The key insight (and this was pointed out to me by of all people someone in marketing, designing campaigns to make products appeal to certain crowds), is janitors like routine. I guess stupid doesn't like to be made to think, they like to do what they excel at, which is doing. So the key to making it work is the smart (and preferably lazy) people design the routine, and the stupid execute it. You can rely on stupid and hardworking to do it consistently and quickly.
In programming terms, this means you need strong coding rules, lots of examples, thorough reviews which takes enormous amount of patience. A smart programmer will cafe at the oversight required, as it prevents exploration of ideas. Give stupid that and something remarkable happens - they produce very good code. Why is it good? Because it's so simple. Anyone can understand it. It takes almost no effort to read.
An even more surprising thing happens when you get them to design UI's, as in "I want a form that takes in X and does Y with it". Again, what they come us with is so simple, my grandmother could use it. Stupid people don't design complex things. Give them anything more complex than a single form and you are asking for trouble of course, as they can't zoom out and pull in the big picture, then zoom back in and execute it.
So it's horses for courses. Stupid hardworking take a lot of investment in management time. They reward that in the long term by turning out a lot of code. But you need a cookie cutter task that lasts for years at least to make the investment pay back. They don't work in a consulting where novel short term tasks are the rule. But you'll find them happily toiling away in bureaucracies, and being paid stuff all for the privilege of being the backbone of the organisation. Which explains the why stupidest thinks we have to deal with in life are bureaucracy. The people you are dealing with aren't paid to think.
