Live data from Hacker News

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

news.ycombinator.com

131–140 of 354 posts

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

#131
post #5

One thing that irks me about Javascript is "const". I think it should have been called "con". "var", "let", "con". So the first thing I did here is look up the docs and see how variables are declared. Aaarghh.. "let" and "const" again :)

if we want to nitpick I hate the fact that many dynamic languages need keywords to express very little information.

If js was made with types then the syntax `any x` (yeah lose the colon too, who gives a shit) is suficient to express that x is a variable, then `number x` could mean variable of type number, and `const number x` could mean constant of type number.

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

#132
1. Would it be correct to describe memoized DOM approach as combination of direct manipulation (like hand-written jquery, or what svelte compiles to) + a mechanism to avoid invoking selectors by caching references to DOM elements? Or is there more to it?

2. It'd be a good experiment to separate out the memoized DOM implementation from imba codebase in a way it can be used by different frameworks, just as virtual DOM libraries got popular after react. If someone were to attempt this, where would you recommend that they start with the imba codebase?

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

#134
post #98
post #94

I don't get that push to put so much logic in the frontend. Connections are getting faster and if we load only smaller amounts of data in each request we can have a really great experience without the hassle of all this complexity.

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 the fact that client-side JavaScript can be manipulated? Or am I totally off-base in this line of thinking.

I'm personally opposed to how much logic happens on the client-side but I'm open to having conversation and changing my opinion on that.

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

#135
post #114

Earlier quoted context omitted.

It's fine if you have a few colors, but with 50+ lines of SASS/component I'd rather have them separately. > I have a hard time finding related things when they're separate. Store them in the same directory? I agree on the events/business logic that they make sense to couple with the template code.

And have to switch between three files back and forth?

I usually split my IDE to multiple planes. A 4k, large monitor helps though :)

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

#136

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.

Very true! It's a great landing page for a language that gets into the meat of it right away with clear examples in code blocks. Nice work.

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

#138
post #123

I have to say, I don't know if I'll use this language as I'm not a fan of Ruby syntax really, but the landing page presenting Imba is just phenomenally well done. 1. The live demos that you can easily click to open and edit the examples (but doesn't load in a slow, clunky, ad-infested live code editor like some sites do) 2. Those arrows pointing out language features, so compact, succinct and useful 3. A short list o…

Totally agree, this is obviously the work of someone who knows how to teach.

The authors of Imba care a lot about education and are working on Scrimba.

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

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

Validation in the browser is just a UX thing. There's no security in the browser.

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

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

> The end effect is that CSS isn't approachable for even seasoned graphic artists let alone laymen; another effect being browser complexity resulting in monopolies.

This is so true. CSS has become a multi-headed Hydra whose parts appear completely unrelated to each other. I've been a developer and designer for more than 20 years and I have no idea what the parameter names and orders are for position, versus grids, versus float, etc. It's parameter soup. Who said the hardest part of programming is naming things? The CSS folks didn't get the memo.

To do any real work with CSS means you have memorize a bunch of conflicting weirdness and/or keep a reference page open at all times. The idea of CSS frameworks to simplify or fix this doesn't work because, in order to write or debug what you create in those frameworks, you must know regular old CSS!

It's turtles all the way down.

Post reply on HN