271–280 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.
Earlier quoted context omitted.
Considering Javascript is the only language supported on the frontend, claiming to be more productive is definitely valid. Coffeescript was a breath of fresh air compared to writing ES5.
We need a Coffeescript Renaissance!
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.
Is it just me? This website is super laggy on my PC (which can run modern games just fine). Hardly hits 50 fps when scrolling. How slow can one get and still claim to be fast?
EDIT: ah - butter smooth in edge (and presumably chrome too), but laggy in firefox.
Earlier quoted context omitted.
> I don't see a difference between switching between files and switching between positions in a file which is longer than a page or two. Exactly! By putting everything into one file, you give the reader the option of splitting their view if they want, or looking at the file all in one pane; with multiple files, you have to have each file open independently. Editors give pretty nice ways of navigating to specific func…
This really depends heavily on how you use your editor, on its specific features. For example, you qualify the "navigating to specific definition" with "within the file", but in my editor jumping to definition across multiple files works exactly the same way as within a single file, and due to a stack of jumps that you can pop, there is usually no need to know or care in which file you are currently, or were previous…
If your convention involves using the same name throughout different files (e.g. every component has a `styles` object), this becomes cumbersome to do. (Arguably, that's a problem with the convention, but sometimes you don't have control over this...)
Other than that, I mostly agree with you and fully admit that it's a matter of preference and highly dependent on your workflow; I was just trying to point out that a single file is generally easier to navigate with an out-of-the-box experience in most editors. I also agree with your stance on when to split files, with a small caveat: even when splitting something into multiple files, I still tend to group them by their high-level function as opposed to by "type". In other words, I would rather split a helper component into its own file with its own styling in the same file, rather than split all of the styling into its own file. (Of course, sometimes you really do have 800 lines of styles, in which case they probably need to be in their own file regardless.)
> That being said, I also don't advocate "splitting everything into super small files".
That's great! :) I see this too often in frontend web development, though: people will go out of their way to keep their files as small as possible to an irrational degree—almost as if they are trying to ensure that you can view every file in its entirety without scrolling.
This read like gibberish to me name Why are we moving away from elegant legible HTML/JS/CSS stack to no nightmares like this and React where everything is smooshed together? > bringing the elegance and concision of Ruby into the browser As a big fan of Ruby how does this tap into the elegance of Ruby? Ruby is readable, this is not. In Ruby it's very difficult to write code that makes people suffer greatly to understa…
> Create a good language and people will flock. What a truthfully useless statement. "Good" means having opinions about things that dont matter? Like "I don't like that css uses full words, I prefer these acronyms" Who gives a shit? Is this language designed to prevent copy pasting? You may be on to something here.
Earlier quoted context omitted.
The complexity of many applications does not come from the client-facing features but rather from other business requirements. 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.…
Yeah, not really. I've worked at some big companies, and currently at one you almost certainly have heard about in the news. The features you describe don't justify the complexity of these apps. Usually these features are implemented without any real consideration for the overall architecture, independently, and within a bubble such that the engineers and PMs on the project locally maximize the feature's complexity.…
For a company which needs teams to implement features independently, the bubble you judge to be negative could indeed be an acceptable, or even necessary, compromise. The business decision to have independent teams might introduce complexity, sure, but within the context of the company's needs and goals, it might be a good choice and thus the added complexity is justified in my view.
The goal of any company is not to generate the most optimized code base. It only needs code that works for its purposes. It's a necessary balance which carries risks and opportunities.
Earlier quoted context omitted.
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…
I like the components. I do not like having to do everything through a JSX template. I do not like debugging through a transpiler. I do not like testing a DOM tree I didn’t build. Just my novice view.
What does this mean?
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 love the font chosen for the demo code, the descender on the f is very charming.
Earlier quoted context omitted.
Nothing is holding you back from using it!
lack of types and it used to be ignorant of perf in the generated code (creating IIFE unnecessarily)
Regarding perf (performance, I guess?) - are you speaking of the single, global one? As CS takes care of variable scoping automatically, I think it makes a lot of sense (and is deactivatable anyway)