221–230 of 354 posts
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.
One thing that site does not specify is the Imba's license (MIT)
Earlier quoted context omitted.
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…
But then how do you gather promises together to run them in parallel? For sophisticated apps this is crucial.
Launch HN: Scrimba (YC S20) – Interactive video for learning to code - https://news.ycombinator.com/item?id=24579699 - Sept 2020 (72 comments)
Imba – Create complex web apps with ease - https://news.ycombinator.com/item?id=20487972 - July 2019 (36 comments)
Imba the new JavaScript based language having Python,Ruby inspired syntax - https://news.ycombinator.com/item?id=18487942 - Nov 2018 (3 comments)
IMBA the new programming language for web apps - https://news.ycombinator.com/item?id=17505816 - July 2018 (2 comments)
Imba – 10 times faster than React - https://news.ycombinator.com/item?id=14837231 - July 2017 (1 comment)
Imba: A new programming language for web apps - https://news.ycombinator.com/item?id=10901054 - Jan 2016 (128 comments)
Imba - create complex web apps with ease! - https://news.ycombinator.com/item?id=10863827 - Jan 2016 (8 comments)
Imba – A new programming language for the web - https://news.ycombinator.com/item?id=10091454 - Aug 2015 (171 comments)
Earlier quoted context omitted.
This is exactly why I prefer Angular to React. Our designer wouldn't have been able to deal with HTML markup within the JS files in React. Having the HTML and (S)CSS separated out made life much easier for him in Angular. (edit: Naturally downvoted due to being slightly critical of React on HN. Which happens every time.)
I'm not sure you are being critical of React. There is nothing about React that prevents you from separating the HTML and CSS into separate files. You are being critical of separation choices. To which I am curious why embedding the CSS and HTML inside a Javascript file makes any difference to the designer? In practice, we often see slightly different syntax to accommodate, but I cannot imagine that is a true barrier…
He has no idea about how the TypeScript/JavaScript files work. He doesn't really have to touch them, unless to maybe see what extra data the component model contains if he wanted to dig deeper and display other things.
But with that said, the author has done an amazing job with the website and materials, and it's clear this language has a lot of upsides given that it's already been running in production as much as it has
I am also a big believer in the premise that we need a dedicated Web Language that incorporates client/server and logic/markup/styles into a coherent package (disclosure: I'm also working on my own version of that)
All in all, cool stuff, lots of takeaways to be found here at the very least
Earlier quoted context omitted.
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 :)
Thats a very good point. In my company whoever writes the most valuable and extensive docs are looked up by people automatically. Either for clarifications or just networking. For the past couple of months I have been making devtools for QA and documenting them and just recently found out that every single team uses them and got recognized for it in the all hands!!
Earlier quoted context omitted.
Thats a very good point. In my company whoever writes the most valuable and extensive docs are looked up by people automatically. Either for clarifications or just networking. For the past couple of months I have been making devtools for QA and documenting them and just recently found out that every single team uses them and got recognized for it in the all hands!!
Any extra salary? No of course not. Lol.
FWIW, my experience reflects GP that people really appreciate someone who takes the time to teach/help others. YMMV.
I've never heard of Imba before this post and haven't seen any real-world projects (besides Scrimba). If this is as good as it looks we'll probably get some soon.
Reminds me of Elm which took a similar route and seems to be successful.
As someone else said, one thing you probably want is static typing. Also make sure your language works well on larger projects. Everyone thinks they're making a simple website, but then it scales.
Earlier quoted context omitted.
Most frontend frameworks are not created to solve performance of vanilla web applications, but rather to make engineering larger and complex applications easier.
Your comment reminds of the Facebook blog complaining that Apple couldn't handle their app's scale, and that's why it was so slow. Most "larger and complex [frontend/client] applications" don't need to be as large and complex. By "most" I mean "almost all." In fact, I can't think of a single web application or mobile app I've used that can justify all the terribly complex garbage that goes into many of them.
For example, interaction analytics, A/B testing support, targeted updates, predictive caching, obfuscation and security, etc. For large companies, setting up the code base so new junior employees can start making contributions fast is also important and that adds to the total complexity too.
It's so much simpler to build an app if all you needed to do is get the minimum features done.
Earlier quoted context omitted.
Exact opposite of Elastic.co.
Every time I consult their docs, I feel like I have less of a handle on the topic than when I started.