Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Imba – I have spent 7 years creating a programming language for the web

news.ycombinator.com

Post reply on HN
Print view View original

241–250 of 354 posts

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#241

Post by vijaybritto »

peakaboo wrote: post #226
vijaybritto wrote: post #195

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.

Ha ha no. I didnt even have a discussion about that. I think i need to talk to my manager at some point. But he has been very supportive!

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#242

Post by Osiris »

inlined wrote: post #194
derangedHorse wrote: post #36

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.

I would assume they would create an array with a bunch of Futures that would resolve at the end of the assignment, or the std lib would offer some ability to explicitly make things run in parallel.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#243

Post by Osiris »

derangedHorse wrote: post #36
mstade wrote: post #23

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 started working in node around version 0.8, before both native Promises and async/await.

I worked with guys that started after async/await.

The new guys just think of everything like it's synchronous. They don't understand Promises. They never look at code and think "I can run this in parallel with Promise.all and a reducer". They just await each thing one at a time.

So, I'm not sure the async/await annotations are really helping us when devs just use them like decorations that just have to be there for it to work.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#244

Post by sidlls »

lyaa wrote: post #229
sidlls wrote: post #109

Earlier quoted context omitted.

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.

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. Then it cascades when the feature is integrated into the rest of the app.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#245

Post by q-rews »

dtagames wrote: post #148
q-rews wrote: post #40

Earlier quoted context omitted.

The distinction makes sense on documents but it starts to break on apps. Javascript depends on HTML and HTML is generated by JS.

Your concept is right but that wording isn't quite right. JS runs fine without HTML and thousands of lines in any web app don't even touch HTML. Node is HTML-free, for example. Also, of course, HTML, can be generated in a thousand ways and has no dependencies on JS. I think what you were going for is the idea that, beyond a trivial application, the visual appearance stuff is always going to be tied to some app logic…

You read that out of context. We’re talking about apps, web apps, SPAs, and specifically situations that bring you to mix HTML and CSS into a JavaScript module.

That situation most likely requires HTML (DOM) generation in the browser, which can only happen in JavaScript.

So, I reiterate, the HTML is generated by JS in these interactive modules.

You could generate the HTML on the server and then use jQuery to toggle elements… or just create full-JS components that take care of everything, giving some input data, instead of separating the HTML from the JS.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#246

Post by RussianCow »

klibertp wrote: post #171
kingdomcome50 wrote: post #146

Earlier quoted context omitted.

I don’t see any added value of separating pieces of a component into different files. The CSS, JS, and HTML are all logically coupled no matter how you organize them. At best you will achieved a few smaller files. At worst you make working within the system a real pain.

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. In both cases the switching is not free - unless you do something about it (like spliting panes/windows in your editor; bonus: it works for both separate files and long files in the same way!). It's also trivial (well... depending on the IDE/editor I guess) to make it open all 3 files…

> 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 functions/methods/points within a file these days, so traversing a large file is not really an issue IME.

Personally, I don't understand the fascination with splitting everything into super small files; given the large number of files I generally have open in my editor, I'd rather look at one file with 1k lines of code than 3 files with 100-500 each. With separate files, if I'm trying to debug something that touches three different components, I need to have 9 files open instead of just 3.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#247

Post by cubano »

shatteredspace wrote: post #134
49531 wrote: post #98

Earlier quoted context omitted.

A couple reasons I can think of: - The less logic you do on the client means more data required to be sent over the wire. - Connections are getting faster but we aren't at the point where they're negligible. For example, if I need to do complex form validation in real time I could send the form value to the backend, have it validate, and receive a response which introduces a lot potential of failure points. Alternati…

I'm just starting out in the journey of front-end development as a hobby and have been doing server-side infrastructure automation for my career for almost a decade now - so please bear that in mind with might seem like an ignorant question. Let's say I have the client-side pick up the bill for logic/computing for form validation. Now for security reasons would I also want validation on the server-side as well due to…

browser validation keeps honest people out.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#248

Post by armchairhacker »

brundolf wrote: post #238
armchairhacker wrote: post #228

Usually I think trying to make your own language for anything more than a DSL is a bad idea. But this project looks very impressive. 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 i…

> Usually I think trying to make your own language for anything more than a DSL is a bad idea. Depends what "your own" means. If it's a one-off language just for one specific project, then you're right. But this one is much more than that. Surely you don't think people should stop making new languages entirely?

No i mean that a single person or small group can’t make a general-purpose language that would beat TS, Rust, Java, Swift, Go, etc.

All these languages are supported by huge groups. They have hyper-optimized compilers or JIT, IDE integration, libraries, and adoption.

If you can form a huge group, then you can beat these languages. Or if you target a niche. Or if you can use existing tooling (transpiling, LSP, effective existing libraries), and spend a lot of time and effort. Imba seems to be taking the third approach.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#249

Post by q-rews »

tannhaeuser wrote: post #55
dt2m wrote: post #31

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?

> 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…

Ok CSS sucks but what are the alternatives? What I see on other platforms requires some sort of WYSYWYG, which you can sort of do in the browser as well. They all generate XML, which I doubt is any more writable than CSS.

What I’ll forever complain about (as a front end developer) is that there’s no distinction between a document and an app. You can start from a blog post and turn it into a rocket just by throwing more JS at it.

I think only Google can fix it at this point:

- come up with a better alternative for apps

- reward websites that are content-only (or are guaranteed to support Reader view)

Now you could start to have simple documents and a powerful app platform.

Unfortunately this is hard to do as most developers will call bloody murder. So let’s enjoy CSS for the next hundred years, shall we?

Post reply on HN