191–200 of 354 posts
P.S. Nobody calls it San Fran :`D
It’s actually pretty impressive how similar Imba is to motion, our project. We forked Babel at the time, added a “view” expression that worked like a class but far simpler, and within view bodies you’d have full reactivity of variables. What’s nicer than Imba, I think, is that you get mostly vanilla JS syntax, nothing new to learn, and it’s 100% React so click handlers are plain JS expressions just like React.
We ended up not launching it, and we were re-writing it but never ended up launching the re-write or the original (though the original is on my GitHub somewhere I think).
Best of luck!
Earlier quoted context omitted.
> DOM/UI speed of the project's JS toolkit generally has not been any meaningful impact in the projects I've worked on in the last several years Maybe you're the exception among your peers or something, but I'd wager you're wrong. Benchmark or no benchmark, imba.io and the site for Scrimba are way snappy. In contrast, when I find myself having to derp around on a landing page or a UI made with React or contemporary f…
Not sure how you got from this that I was saying that there's no different between react and imba, or that it's not snappy/fast. I was just saying that for the majority of LOB apps I'm working on, whether a table of 2000 entries renders in .2 seconds or .3 seconds has no meaningful impact on the client projects I'm working on. Even though it's a 50% slowdown, or 33% speed up, depending on how you measure, that speed…
And I'm not sure where you got that I got that you were saying that.
What I am saying is a direct challenge to what you wrote—no need to repeat yourself. I'm saying, positively, that the common standards in React projects produce bloat that is perceptible—in cases I had in mind, FWIW, that are even more trivial/lightweight, by comparison, than the example of 2000 entries you're relating here.
That you consider a threshold on the order of 2 seconds as beginning to be worthy of something that might need to be addressed is significant. It reveals a fundamental difference in our expectations of software. That "no impact" 0.3 seconds figure is already itself eons in CPU time.
(This isn't generic anti-JS, anti-Web sentiment, by the way. In the early days of developer.mozilla.org—up until 2008 or so—I poured a lot of effort working on the JS documentation to make sure high quality docs would be available to a wide audience, so that even more people might pick up JS, which wasn't taken very seriously at the time. That's also, though, why I bristle at the state of React and frontend development—it has sowed the idea that JS, or maybe just software in general, has to be inherently slow and bloated. The average modern Web project on modern mid-range hardware is more top-heavy and perceptibly less snappy than the Electron-style applications like Netscape, Firefox, etc. from 15 years ago, which ran unJITted on sub-Ghz machines.)
This looks very cool, thanks for sharing! I took a cursory look at the docs and it looks like async/await is pretty much directly analogous to how it works in JS, with the difference that you don't need to mark functions as async in order to use the await keyword. Does this mean that if you use await in any function then any other function calling it will have to be refactored to add an await keyword, just like you h…
Asynchronous code can sometimes be difficult to write efficiently so having implicit awaits might help with avoiding accidentally made fire and forget calls. An interesting concept might be to explicitly call a function as asynchronous with a new keyword flipping the typical usage of ‘await’. I’d still advocate for the usage of ‘async’ in function signatures though as it helps when reasoning through an asynchronous c…
I just want to compliment the OP on a very clear and comprehensive website at https://imba.io/ . It clearly explains (by showing and telling) what Imba is, why I should care, how it works and how to get started. The floating demo applications even work well on mobile. Rare to see this level of polish for these things.
I've noticed that some projects being complimented for having good docs come from CTOs (esbuild is another example). I'm hoping that by pointing out this little correlation, people might feel more inclined to spend more time on writing docs for their projects if they aspire to climb in the career ladder :)
Relevant links for those who wish to look into it: Repo: https://github.com/imba/imba Docs: https://imba.io/language/introduction Video: https://www.youtube.com/watch?v=8XS5q9xhaMc Article: https://dev.to/somebee/imba-a-javascript-alternative-for-inc... Site: https://imba.io Discord: https://discord.gg/mkcbkRw Twitter: https://twitter.com/imbajs
Thanks for sharing, I really like projects like this. And the website is really informative. I find it less of a new language and more of a JS preprocessor, removing lots of the cruft and integrating XML-tags and CSS in a very neat way. What I miss: 1) I feel the web is shifting to more type checking. TS, Elm, Kotlin.js... I personally also prefer more typesafety, especially if the project grows in LOC/team size. 2)…
Earlier quoted context omitted.
> The distinction between HTML, JS and CSS always made perfect sense to me. Really? HTML is already heavy on syntax, and the whole point of SGML-style angle-bracket markup is to invisibly structure text hierarchically and sneak in rendering properties or other "metadata" not rendered to the user, via attributes. In which universe, then, has it ever made sense to write rather than in a document representation language…
Not that I disagree that what we have today is a big mess but this sounds to me almost like the philosophy behind the old PHP version that everyone seems to hate. Personally I'd much rather have everything separated in a better HTML/CSS/JS than HTML+CSS+JS in one big pile. But I'm also not a fan of JavaScript at all, especially not of the hyped "one framework today, another tomorrow" that is JS development today. In…
I also made SnackUI to solve the last problems of fully inline styles: namely to make them work 100% between React Native and Web, to make them extract to atomic CSS on web automatically, to optimize even conditionals into CSS, and finally to make media queries and themes work the same between Native/Web. We’re launching a very large app with it here in not long, and I absolutely love how clear it is to work on.
Looks cool. I'm honestly curious as to why a lot of new web languages/frameworks are mixing logic and content in the same file again though. The distinction between HTML, JS and CSS always made perfect sense to me. Anyone care to enlighten me?
What is npx?
I read this and still have no idea what the ‘memoized DOM’ is. There is a broken link to ‘how it really works’. Apparently there is a huge speed-up over react. I don’t actually care about this; I’d rather know what the slow parts of browser DOM changes are, and how it gets around them. Forgive my ignorance if I’m missing something obvious; I am completely new to JavaScript, but so far have found react/vue/etc confusi…
I learned React to know what it was about and what people were talking about. I think a lot of people get the wrong idea about React. They say the virtual DOM is the most important feature, but I think it's actually the fact that it forces you to componentize your code. And it does this by making non-componentized code very painful to work with, so you have to componentize to be able to have any shot at getting React…
Just like React encourages components, it also encourages immutable data, one-way data flow, functional reactivity, and thinking in terms of state machines, even if you aren't necessarily familiar with that terminology.
All this stuff makes building a complex UI far more manageable and helps to avoid common pitfalls.