[HN Gopher] Show HN: Imba - I have spent 7 years creating a prog...
___________________________________________________________________
Show HN: Imba - I have spent 7 years creating a programming
language for the web
Hey all My name is Sindre, and I am the CTO of Scrimba (YC S20).
For the last 7 years, I have written all my web apps in a full-
stack programming language called Imba. It compiles to JavaScript
and its main goal is to make web developers more productive. I
just launched a major overhaul of Imba, so I wanted to share it
here on HN, in case anyone are interested in learning more about
it. It is very opinionated, so some of you might not like it, but I
would love to hear anyones feedback regardless. Constructive
criticism appreciated! The backstory: Imba initially started in
2012 as an effort to bring the elegance and conciseness of Ruby
into the browser, and also because I felt that JavaScript and the
DOM should be more tightly coupled together. Over the years, I have
taken inspiration from React/JSX, and also Tailwind. Since 2013, I
have built several business-critical apps in Imba, so this is not a
toy project or an academic exercise, it is extracted from a real
project trying to solve real problems. Today, we are currently a
small but passionate community of devs who use Imba all over the
world. The nitty-gritty details: As mentioned, Imba compiles to
JavaScript, and it works on both the frontend and backend. The
quickest way to get a feeling of how it works is by checking out
this video: https://www.youtube.com/watch?v=8XS5q9xhaMc
Alternatively, here is a list of the main benefits of the language:
* Clean syntax with built-in tags and inline styles * Imba's
Memoized DOM approach is *an order of magnitude* faster than
Virtual DOMs (Vue, React). Learn more here:
https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me... *
Imba works with Node and the npm ecosystem, and integrates tightly
with both JS and TypeScript * Blazing-fast dev/build tools based
on esbuild Each of the benefits above are explained more
thoroughly in our docs here, so please check it out if any of the
above points spark your interest: https://imba.io With this
version I feel that I am very close to my vision for what Imba
should be. In other words; it is finally ready for public
consumption. I'd wholeheartedly advice you to look into it and give
it a whirl if you are interested in web development :) Hope you
like it, and please share any feedback you might have in the
comments! PS! We're also hiring Imba developers at Scrimba - see
https://jobs.scrimba.com/. We don't expect you to be a seasoned
Imba developer, but we expect you to pick it up fast :)
Author : somebee
Score : 994 points
Date : 2021-08-17 08:55 UTC (14 hours ago)
| truthwhisperer wrote:
| sorry waste of time
| mstade wrote:
| 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 have
| to refactor any call sites in JS if you make a function async?
|
| I remember seeing someone here on HN showcasing a language where
| they did the opposite, making it so that await is implicit, so
| calling fetch or anything async doesn't require an additional
| keyword, and functions don't need to be refactored just to
| sprinkle async/await everywhere. I'll see if I can find that
| language again, but it seems to me there may be some idea sharing
| between the two that could perhaps yield some amazing features...
| minxomat wrote:
| That pretty much describes Lua.
| mstade wrote:
| Thanks for mentioning it, I don't know much about Lua. I
| found the language I was thinking of, it's called
| hyperscript. Here's an article about how async works in that
| language: https://hyperscript.org/posts/2021-04-06-aysnc-
| transparency-...
| masklinn wrote:
| So... bog standard blocking interface, except it compiles
| to JS so it has to "surface" the async during the
| compilation process?
| recursivedoubts wrote:
| https://hyperscript.org
|
| and its async transparency in particular:
|
| https://hyperscript.org/docs/#async
|
| hyperscript isn't a general, full-stack programming language
| though, it's focused on pure front end stuff, sort of a modern
| jQuery replacement.
| derangedHorse wrote:
| 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 code base.
| mstade wrote:
| This is exactly how I remember it working in the language I
| mention (which, by the way, is called hyperscript[1].) The
| semantics where flipped such that you'd explicitly mark calls
| or functions as async, rather than await, if you wanted them
| to run asynchronously.
|
| I run into subtle bugs all the time due to missing awaits,
| it's incredibly frustrating.
|
| [1]: https://hyperscript.org/posts/2021-04-06-aysnc-
| transparency-...
| williamdclt wrote:
| > I run into subtle bugs all the time due to missing
| awaits, it's incredibly frustrating.
|
| If you use TS, ESLint's `no-floating-promises` rule (or the
| equivalent in other linters) is _such_ a requirement
| masklinn wrote:
| That assumes all promise-generating code can be and is
| properly annotated, though.
| yunyu wrote:
| Typescript will cover this!
| masklinn wrote:
| Typescript lets you call into un-annotated libraries or
| annotate things as `any` or whatever.
| Osiris wrote:
| 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.
| z3t4 wrote:
| Don't forget to put each await in a try/catch. You are
| handling all errors aren't you!? ;)
| inlined wrote:
| But then how do you gather promises together to run them in
| parallel? For sophisticated apps this is crucial.
| hashkb wrote:
| Or queues, graphs, or other chaining behavior I can't
| predict you'll need as a tool author.
| Osiris wrote:
| 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.
| coding123 wrote:
| I think it would be awesome for Typescript to introduce sync
| functions. So think of that as completely flipping the dialog
| on async/await to await by default: sync
| function x() { const taco = getTaco() // getTaco
| returns Promise<Taco>, but taco automatically resolves it in
| a sync function // Similarly, you can tell it to
| not wait const ptaco = nowait getTaco();
| // ptaco is a Promise<Taco> const taco2 = ptaco;
| // taco2 is a Taco because the ptaco symbol is treated like
| (await ptaco) without nowait // Also, since ptaco
| has already "awaited", future // access would be
| 0 delay as it's basically a resolved promise. }
|
| Of course, similar to an async function, sync functions would
| also return a promise.
|
| Probably a dumb idea but I would use it personally.
| jessmartin wrote:
| I literally googled to see if this existed last week. Would
| also use!
| dmead wrote:
| does this take any inspiration from links?
|
| https://links-lang.org/
| 0xcoffee wrote:
| Really amazing landing page, normally I just scroll though in one
| second but now I'm really taking the time to try and understand
| the examples.
|
| Small note, the clock demos don't update every second in Firefox
| for some reason. On Edge it worked fine.
| yewenjie wrote:
| Quick question - how does the memoized DOM compare with no-
| virtual-dom-at-all approach of something like Svelte?
| lowercased wrote:
| https://krausest.github.io/js-framework-benchmark/2020/table...
|
| This lets you choose from multiple frameworks - comparing
| svelte against a few react variations, what I saw was that
| svelte was always fastest, but usually by a factor less than 2
| (any react was 1.x times slower than the svelte).
|
| The imba vs react numbers (from the article at
| https://www.freecodecamp.org/news/the-virtual-dom-is-slow-
| me...) shows a 30-40x speed difference.
| codesections wrote:
| This is a very misleading way to report those results (likely
| unintentionally). The JS Framework site includes benchmarks
| for imba-v1.5.2 and svelte-v3.29.4 and reports that they are
| equally fast (1.04 and 1.05). It shows both as similarly
| faster than React.
|
| As described in your second link, that benchmark is timing
| something a bit different - and we don't know how well Svelte
| would perform on it (I'm guessing fairly similarly, since the
| overall approach seems similar. But there's no way to know
| without measuring.)
| somebee wrote:
| Tbh, I think the js-framework-benchmark is flawed. It mostly
| tests the performance of the browser. I should write a whole
| blog post about this. Just as an example, all the table
| benchmarks uses a table with non-fixed width, which results
| in a full repaint AND layout of the whole table+page whenever
| a cell changes. If you change the table to a fixed width (as
| all real tables are) the relative difference between the
| frameworks increase by a factor of 5 or more.
|
| And when you benchmark the speed of creating 10000 dom
| elements in an instant, less than 5% of the time should
| really be spent inside the framework one is supposed to test.
|
| I stand by my claim in the mentioned article that tiny
| changes to a larger dom tree is a far better indicator of
| real world performance than anything else. Here Imba is
| really orders of magnitudes faster than react.
|
| The last time I tested it, Imba was more than 10x faster than
| Svelte as well, but I'm not proficient enough in Svelte to
| claim that as a fact, and I have tremendous respect for Rich
| Harris and everything he's done with Svelte and other
| libraries.
| lowercased wrote:
| Flawed in what sense? I don't doubt that there are some
| conceptual drawbacks, and this only benchmarked chrome, not
| other browsers. I do think there's some utility in relative
| comparisons that have a standard/fixed baseline, as it
| would still seem to show what overhead a framework/library
| brings to the table.
|
| FWIW, my initial impression of imba is that it's very
| impressive. I do think you rightly point out that, at this
| point, it may still be hard to leave larger ecosystems of
| react/vue/etc. 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 - the
| data size and audience and app space just don't really call
| for it. However... as my needs change, imba will be
| something I'll revisit. Thank you.
| cxr wrote:
| > 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
| frameworks, I can feel the bloat. Is it possible that
| being elbow deep in this stuff has dulled your senses?
| lowercased wrote:
| 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 difference has no impact on these projects. If
| we got up to 20000 entries, and we were hitting 2sec vs
| 3sec, that might be noticeable and something to address.
| cxr wrote:
| > 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
|
| 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.)
| [deleted]
| codesections wrote:
| Setting aside _performance_ comparisons, how does Imba 's
| approach compare to Svelte's from a design perspective?
| From your _Meet the Memoized DOM_ article, I take it that
| Imba is basically converting declarative code into
| imperative code that mutates the DOM - on first glance,
| that sounds very similar to Svelte 's compiler-driven
| approach.
|
| Are the two strategies as similar as they sound, or am I
| misunderstanding something?
| lhorie wrote:
| I have to echo somebee about that benchmark suite. It's
| fairly well known in the framework-bulding community that
| this is not a very good benchmark (just ask Boris Kaul of
| Ivy.js, Ryan Carniato of Solid.js, Leon Sorokin of domvm, etc
| etc).
|
| Some "frameworks" achieve good numbers there by being utterly
| unusable in real life, others miss the spirit of the
| benchmark completely (e.g. submitting a non-keyed
| implementation as keyed thereby gaining an unfair/misleading
| advantage), and as somebee said, the benchmark itself largely
| measures repaint time (and does so in a less than ideal way,
| by using setTimeout macro queue as a proxy for repaint time
| measurement, in band, instead of instrumenting performance
| via CDP). It lacks rigor in many ways (the most blatant was
| that initially it considered keyed and non-keyed
| implementations on par, but there are other issues such as
| putting a lot of weight into DOM creation compared to e.g.
| array diff, or as somebee said, not measuring low repaint
| load diffs)
|
| IMHO, it only has two things going for it: a) it has a lot of
| frameworks listed b) it does at least attempt to measure
| repaint times unlike other benchmarks that only measure JS
| time (which has become somewhat irrelevant since V8 et al now
| offload repaints out of the JS thread)
| hydroxideOH- wrote:
| There's a lot of css issues on mobile on imba.io
| johschmitz wrote:
| True, it doesn't seem to work so well, see screenshot:
| https://pasteboard.co/KgkhOEo.jpg
| warent wrote:
| Yep, I'm on mobile and the website doesn't really give me much
| confidence in how Imba works with responsive development
| graderjs wrote:
| Wow you are clearly a genius. The syntax looks beautiful! This is
| great. I don't want to use it (the best tool for the job for me
| is one that fits my own mental models, my own mind, and this is
| not it) but you are a genius.
|
| Also -- wow those Nordics are super productive
| programmers/coders/developers/open-sorcerers (Sindre Aarsaether &
| Sindre Sorhus & Linus Torvalds & ...<please insert other names
| below to educate me>...) -- could it maybe have something to do
| with: The low GNI, the high HDI and the great weather for coding?
| (cold, blistery, bleak, focused, electrons-and-light universe is
| only outlet in a desolate landscape)? I have been to Oslo. The
| architecture is great.
|
| PS - I use my own memoized DOM with minimal/granular updates in
| my own quirky framework (https://github.com/i5ik/vanillaview)
|
| PPS - BTW memoized DOM is a _great_ term of art. I perhaps shall
| be using it from now.
|
| CONGRATULATIONS, SIR!
|
| PPPS - Also what you are doing with Scrimba is so incredible. And
| _GOOD_. You are such a fuqing genius. Wow!
| xavloper wrote:
| This is very cool. It seems like the perfect language for making
| web components. Do you have a "compile as component" mode to
| output components or component-like packages (like Angular
| Elements)?
| micheljansen wrote:
| 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.
| dtagames wrote:
| 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.
| nailer wrote:
| One piece of feedback: it took me a moment to work out what
| 'pt', 'o' and 'fs' were. Single character variables are fine
| for algorithms but for demos you really want to use actual
| words.
| linux2647 wrote:
| I'd agree If I'm using css daily I might know what these
| mean, but I only edit css once in a while, so most of these
| properties are lost on me
| greggturkington wrote:
| I write CSS everyday and I had no idea what "fs" meant.
|
| "fz" is the typical shorthand used for font-size (at least
| by Emmet-style autocompleters). "fs" is used for font-style
| instead.
| scotty79 wrote:
| Those shorthands are optional.
| js6i wrote:
| 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?
| p1necone wrote:
| Not just you, I have a pretty beefy desktop and it's
| noticeably laggy when scrolling for me too.
|
| EDIT: ah - butter smooth in edge (and presumably chrome too),
| but laggy in firefox.
| antattack wrote:
| One thing that site does not specify is the Imba's license
| (MIT)
| Bellamy wrote:
| What does it mean for projects build using imba?
| lhorie wrote:
| Nothing you should worry about. MIT is a very permissive
| license.
| lhorie wrote:
| 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 :)
| vijaybritto wrote:
| 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!!
| peakaboo wrote:
| Any extra salary? No of course not. Lol.
| lhorie wrote:
| Anecdata, but after I released Mithril.js, I started
| getting contacted by recruiters from Bay Area companies.
| I now make 4 times as much as I did when I first started
| working on it. I know of other folks that got poached by
| high tech companies due to growing prominence in open
| source.
|
| FWIW, my experience reflects GP that people really
| appreciate someone who takes the time to teach/help
| others. YMMV.
| xwdv wrote:
| Was your original salary at the average market rate?
| lhorie wrote:
| It was on the higher side of the bell curve (in Toronto,
| Canada, if you're curious)
| vijaybritto wrote:
| 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!
| fwip wrote:
| I love the font chosen for the demo code, the descender on the
| f is very charming.
| cutemonster wrote:
| I thought so too
| system2 wrote:
| Exact opposite of Elastic.co.
| meepmorp wrote:
| Every time I consult their docs, I feel like I have less of a
| handle on the topic than when I started.
| ziftface wrote:
| Hate to pile on, but I'm glad it's not just me. When I read
| their docs, I just get the feeling that I'm kind of dumb,
| or I just don't have the context they expect me to have.
| vosper wrote:
| I think this might be partly due to the query language
| being JSON? It makes every example huge and hard to
| understand. JSON is a serialization format that's human-
| readable, it's not a human-first language. So it's a pity
| that's how you're expected to write searches (I know they
| have some SQL support now, but I've never seen it in the
| docs)
| gregsadetsky wrote:
| Very true!
|
| One small note to the author: the "We are hiring" at the very
| top, on mobile, is a bit broken. It appears on three lines. It
| looks great in mobile landscape, but not in mobile portrait
| mode.
| nickthemagicman wrote:
| Looks great!
|
| From a first look, I love the dimension types and the tags which
| compile down to native web components.
|
| Hope good things for this.
| jsf01 wrote:
| Really interesting project! I will definitely be trying it out
| today. One question--although you criticize some of the more
| common vdom benchmarks, I think it is still valuable to see where
| the dom updating strengths and weaknesses are in various
| approaches. Have you run any of the more standard frontend
| benchmarks on this and compared? I think it would be cool to see
| an entry for imba in the js-framework-benchmark table, especially
| considering your claim of low memory footprint.
|
| https://github.com/krausest/js-framework-benchmark
|
| Great work so far, I'm excited to give imba a spin.
| somebee wrote:
| I will try to add v2 to that benchmark relatively soon - it is
| a lot faster than v1 and has a much lower memory footprint and
| faster initial load time :) Should probably combine it with a
| few pull requests to the benchmark itself - as I consider it
| pretty flawed (see another comment here).
| ita wrote:
| Is there an example of importing js functions to imba, or calling
| imba from inside js or ts? I could not find this.
|
| In Scala js, this interoperability is quite painful, so I wanted
| to see how easy it is in imba.
| wccrawford wrote:
| How does it know whether to run the code client-side or server-
| side? How easy is it to accidentally end up creating SQL
| statements client-side and running them on the server?
|
| If all the code runs server-side, is it not possible to create
| modern web apps on it where most interactions happen client-side,
| or does every request have to wait for the server's response?
| armchairhacker wrote:
| 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 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.
| brundolf wrote:
| > 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?
| armchairhacker wrote:
| 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.
| xutopia wrote:
| 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.
| 49531 wrote:
| 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. Alternatively I could write some
| logic on the frontend to validate, and this problem expands as
| the amount of fields in your form increases.
| handrous wrote:
| I distinctly recall using a vendor's demo in a no-nonsense
| show-me-the-money kind of industry, about 4 years back. It
| was something that would definitely have been built as a "web
| app" at most shops I've known since, oh, 2012 or 2013.
|
| It was _remarkably_ responsive, fast, and light. Everyone who
| used it commented on how snappy it was.
|
| It was PHP, doing full-page reloads on damn near every
| interaction, with minimal Javascript.
| shatteredspace wrote:
| 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.
| pier25 wrote:
| Validation in the browser is just a UX thing. There's no
| security in the browser.
| cubano wrote:
| browser validation keeps honest people out.
| juanramos wrote:
| Imba looks great! Now that v2 is out, what would you say are your
| priorities regarding Imba? Is there a roadmap somewhere?
| still_grokking wrote:
| It feels indeed snappy and fast.
|
| I'm impressed!
| shaunxcode wrote:
| This is the first time I have seen a language that
| extends/integrates markup in a way that does not feel
| superfluous.
| dang wrote:
| Past related threads:
|
| _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)
| mkl wrote:
| Hi Dan, I noticed that the links in the post are actual links
| here, unlike usual and what
| https://news.ycombinator.com/formatdoc says. Is this new? Is it
| just for Show HNs?
| zenosmosis wrote:
| Beautiful project.
|
| Imba website looks great and the code examples explain it well.
| The React-like server-side rendering with the .html imports is
| phenomenal!
| edu wrote:
| Wow, congrats. It looks great, need to try it. The video gave me
| the same feeling I had when I watched the original rails demo
| video [1].
|
| 1. https://www.youtube.com/watch?v=Gzj723LkRJY
| arodyginc wrote:
| Using two-way databinding, how do you control the updates when it
| triggers other updates and so on? Is there any kind of loop
| control like say in Angular?
| soheil wrote:
| This read like gibberish to me <header[fs:xl
| fw:700 ta:center c:gray8/40 p:2]> 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 understand, this
| seems to be the opposite.
|
| > It is very opinionated, so some of you might not like it
|
| As if that's the reason people won't like this. Give me a non-
| opinionated language and I'll show you as many people not liking
| it. Create a good language and people will flock.
| nsonha wrote:
| > 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.
| soheil wrote:
| No that's not what good is, I in fact love languages with
| concise syntax, Java is probably the worst in that
| department.
| geenat wrote:
| Thought this at first but it's just tailwind css aliases. They
| are interchangeable with the full name.
|
| fs = font-size
|
| fw = font-width
|
| ta = text-align
|
| c = color
| philmcp wrote:
| Very cool, good luck! I'm sure you'll do great
|
| p.s. if you would be open to listing your positions on a 4 day
| work week (even at 80% salary) I'd be more than happy to promote
| them on https://4dayweek.io + the newsletter for free
| somebee wrote:
| 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
| cies wrote:
| 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) Compared to JSX, Imba does a much better job in integrating
| adjacent technologies. Though I much prefer these to be
| integrated in an eDSL fashion. For example how Elm does HTML
| templating (in Elm) or Kotlinx.html[1].
|
| Just taste i guess. Good luck with yr project!
|
| [1]: https://github.com/Kotlin/kotlinx.html
| gdotdesign wrote:
| If you want something like that, check out Mint (www.mint-
| lang.com) :)
| MatekCopatek wrote:
| You call it "full-stack" and mention memoized DOM, which makes it
| sound like it's not only a language but also a framework.
|
| Is there a clear separation between those two parts? Could
| someone take just the language without the framework and use it
| for something that's not web related?
| somebee wrote:
| You can definitely use 'just the language' part. I'm using it
| daily for scripting, and we've written a lot of apis and
| libraries at Scrimba that does not utilize any of the
| framework-ish features of the language. But to make the tags
| and styling work really well it (imho) has to be thought of at
| the language-level.
| quickthrower2 wrote:
| It's a double take to see scrimba as a YC company because I used
| them a while back so feel like they are an established company
| not a startup. In any case the experience of learning React on
| that platform is wonderful and gave me the best long term recall
| performance of any course I have done.
| valyagolev wrote:
| is there any particular reason why there doesn't seem to be
| built-in type-checking system? i know it still seems to be a
| "personal preference" whether to check one's types, but i wonder
| if any thought was given to including it?
| k__ wrote:
| Interesting.
|
| I had the impression "tightly coupled with TS" would mean type
| checking.
|
| That's sad.
| somebee wrote:
| There is built-in type-checking, but currently only via the
| tooling. It integrates with TS as a language service plugin
| (https://github.com/Microsoft/TypeScript/wiki/Writing-a-
| Langu...) so you get great warnings/errors, type inference and
| much more. To define standalone types or interfaces you still
| need to use `.d.ts` files, but that may change in the future :)
| valyagolev wrote:
| that is to say, the types are not part of the syntax in any
| way?
| somebee wrote:
| You can typeset variables, parameters etc (ie. see the code
| in https://dev.to/somebee/global-type-augmentations-with-
| automa...). But declaring standalone types is still done in
| `.d.ts` files. Imho, the type inference in ts/js is getting
| so good that I very rarely need to declare any explicit
| types in my own projects.
| mleonhard wrote:
| Does Imba have good tools for testing? I didn't find 'test' in
| the Imba docs.
| akvadrako wrote:
| This looks pretty good, but it would be better if you compared
| the performance and rendering approach to Svelte instead of React
| and Vue. It's well known that virtual DOMs are not good for
| performance.
| jvalencia wrote:
| I came in thinking "ug" like this will go anywhere. Then I looked
| at imba.io and it totally made the case for it. Great job! Now I
| want to try it.
| turtlebits wrote:
| I wanted to like Imba, but there was no hash based router.
| (Required for static sites without having to redirect on the
| server). Quickly looking at the docs looks like that is still the
| same.
| errantspark wrote:
| Very cool stuff, as a baseline I have about zero interest in a
| compile to JS language but this seems like it might actually lift
| more than it weighs! Really appreciate the documentation,
| examples and terseness of the code.
|
| P.S. Nobody calls it San Fran :`D
| mleonhard wrote:
| How useful are the compiler error messages? I would like to see
| an example compiler error on the intro page.
| imvetri wrote:
| Not highjacking but learning that you have spent 7 years to solve
| a problem gets me. I started something 7 years back with an idea,
| been learning things for 3-4 years and started implementing 3
| years back. The timeline is coinciding.
|
| Here is what I have
|
| https://github.com/imvetri/ui-editor
| keithnz wrote:
| is there direct support for websockets? channels or something?
| pier25 wrote:
| You can use all browser APIs as if you were using JS.
| math0ne wrote:
| Some cool ideas here, I love that everything looks so small and
| cute!
| k4runa wrote:
| Would it be possible with this to just apply tailwind css classes
| instead of learning this built in style syntax?
| somebee wrote:
| Sure, you can apply tailwind classes like
| `<div.w-32.h-32.rounded-full>` etc, but I'd definitely
| recommend using the built in styling as it is much more
| powerful (value interpolation, flexible modifiers etc).
| k4runa wrote:
| Great! I am interested in trying out the language and
| learning more but there would be a lot less friction and
| mental confusion on my side if I can get started and apply
| tailwind classes and use something I'm familiar with.
| lowi wrote:
| 1. Do you have a recommanded way for i18n integration? 2. What's
| the performance of updating/adding/deleting a single entry in an
| array? Will imba just update the html element in O(1) or it will
| iterate the array to delect the changes?
| krmmalik wrote:
| Interesting. I haven't watched the video get but I'm interested
| to know how is Imba for low-coders like me? React has a huge
| ecosystem around it and while it is not low-code, component
| libraries make adoption a bit more of a no-brainer so I'm
| interested from that perspective.
|
| I've currently been working on a Blockchain app with a low-code
| back-end which is almost complete now and the front-end is
| supposed to be done in React but I'm open to alternatives.
| nsomaru wrote:
| Just wanted to say thank you for the purchasing power parity
| discount on scrimba.com
|
| Very very cool!
| habosa wrote:
| Congrats on the new launch! Scrimba, which could not exist
| without Imba, is one of those insane magical web things that is
| criminally under-appreciated. I hope Imba takes off!
| dt2m wrote:
| 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?
| ehnto wrote:
| As others have mentioned, it's being used when writing
| components. Why does it work so well for components though,
| since you could just as well still separate the CSS? I think
| it's because of code co-location. Everything that describes how
| a component looks and functions lives in one file only. That's
| also why inline styles and utility libraries are palatable now,
| it's easier to reason about if it's described directly on the
| element, and you don't need to remember to update all usages of
| the inline style since it's a re-used component. It's even one
| step less indirection than using class names in that context,
| which is handy.
|
| I also think most people are quite bad at organizing CSS, so
| I'm personally thankful for this change even though I love a
| well organized simple CSS/HTML site. It means less projects I
| inherit are rabbit warrens of legacy CSS to unravel.
| notJim wrote:
| Some of the early React talks from 2013 give great answers to
| this question IMO https://www.youtube.com/watch?v=x7cQ3mrcKaY
| namelosw wrote:
| A bad metaphor I just came up with: You're cutting a birthday
| cake. If you do the horizontal cuts you could at best have like
| 4 cuts and it's very hard. If you do the vertical cuts you
| could easily have like 16 cuts for everyone.
|
| Because the horizontal way separates the concern the wrong way,
| or more precisely, the non-scalable way.
|
| The idea is the same way that backend architectures are
| migrating from layered architectures to microservice or DDD
| alike architectures.
|
| HTML, CSS, JavaScript separation of concern: 3 layers. Layered
| architectures: presentation, application, domain,
| infrastructure etc. There's only O(1) number of layers, so it's
| not scalable enough for modern applications. You can came up
| with more layers, but it's still O(1) and would be more
| strechy, despite the business and codespace are growing fast.
| People will struggle because everytime they change one layer,
| they have to find the corresponding other layers of code - it
| starts to defeat the purpose of separation where it should help
| people not caring other layers when modifying code.
|
| A more critical separation of concern is to have O(n)
| separation: you can different domains like products, inventory,
| sellers, account managment, custommer support etc. If your
| business continue to grow, you could have more of them. And
| more importantly, it's much easier to separate teams into
| pizza-sized teams than layered separation.
|
| Don't get me wrong, layered architectures are still useful. In
| fact, most of the DDD implementations are layered. But there's
| mental overhead when you introduce separation. Communities like
| React and Vue decide that it makes sense to merge layers in
| Front-end for local reasoning over separation, and accoding to
| my experience it works well (because I find it's very common to
| modify HTML, JavaScript, and CSS at the same time before I even
| started to use React).
| dathinab wrote:
| (Disclaimer not a web but backend dev.)
|
| In my experience it's much more important to
| modularize/capsulate/segmentate by groupings of business logic
| then by groupings of implementation details.
|
| Applying this to web applications (not simple text focused
| websites) this would mean that its preferable to have
| everything (HTML+JS+CSS) related to a specific widget (e.g.
| counter) in one place, instead of splitting it into many parts
| sprinkled across many files potentially in different folders.
| Similarly you also would e.g. want the CSS to be encapsulated
| as to the component as far as possible.
|
| Its a bit of a different matter for classical html documents
| where the HTML made sense without JS or CSS and both where
| thinks you added "on top" to "just make it a bit nicer" but
| this isn't the think anymore for modern webapps (and many fancy
| websites).
|
| Also if you work in a situation where you have many huge teams
| working on the same UI at the same time touching the same
| logical component (but normally different aspects of it) then
| having a more clear segregation can also make sense, but >99%
| of all companies are not _ever_ in that situation.
|
| This is also for example a major critic I have with react, it
| splits one logical unit across different files making it much
| harder to reason about it for the benefit of adding a bit more
| decoupling which isn't needed by >99% of dev teams.
| hyldmo wrote:
| Another way too look at it: Do you prefer backend, frontend,
| and databases to be separate teams, or should each team have
| ownership over their own backend, frontend, and db?
| tenaciousDaniel wrote:
| Hard to describe, but it feels like it makes much, much more
| sense. I think it's because the divide between html/css/js is
| _supposed_ to be one of concerns, but in reality the concerns
| are interwoven in many ways, and leads to issues when using
| them at scale. None of the scaling issues I 've faced in the
| past re-occurred when I used a framework that combined the
| languages into single files.
| ollerac wrote:
| It's because of components.
|
| Web app dev has started focusing on single, separate, reusable
| components instead of trying to design everything on the page
| at once.
|
| Often, in these components, the HTML, CSS, and JS is still
| separated, but now (theoretically) you can plug that component
| in anywhere (even a different app) and, as long as you feed it
| the right data, it should just work.
| klibertp wrote:
| > It's because of components.
|
| Replying to you because this is the shortest expression of
| this sentiment, expressed in many different comments:
|
| No, it's not _because_ of components. It 's because of
| _emulation of components_ by means of precompilation or JS
| execution. First-class components are available already,
| there 's no reason to continue to emulate them, unless you
| need backward compatibility, or have another goal other than
| separating components.
|
| It's also not about "components" in the meaning of "widgets"
| - reusable bits of content+view+behavior - because these can
| be trivially made with standard HTML + CSS + jQuery plugin.
| It was done since before the DHTML was a thing (hello
| <iframe>!).
|
| Instead, it's all about _web apps_ , how they achieve
| responsiveness, and the fact that the more the framework
| knows about the content (including how it should look in all
| its states), the easier it is to optimize it consistently. I
| get that, it's ok for web apps, and it gets better the more
| nice syntax you throw at the problem (up to a point, as
| usual), because once you have enough of syntax extensions to
| replicate the important features of HTML and CSS, you can go
| absolutely nuts on the actually generated code and nobody
| would care.
|
| On the other hand, using web app frameworks to write _web
| pages_ is bad - do you really need to optimize for
| responsiveness if almost everything you see on the page has
| exactly one (or two, with hover) state? The same is probably
| true for languages designed for web apps: using them to write
| web pages can be tedious and more trouble than it 's worth.
|
| TLDR: it's because ~components~ web apps.
| bjourne wrote:
| It never made a lot of sense in practice. Designers couldn't
| maintain CSS files because the language was too complicated for
| most. And these days, most DOMs in dynamic web pages are
| generated by the JS so the HTML/JS separation doesn't make
| sense either. Separating content, presentation, and logic is a
| good idea in theory, in practice not so much.
| dmitriid wrote:
| Separation only works for so-called leaf components: buttons,
| links, tabs etc. that can actually be reused.
|
| And even then you will definitely run into issues such as "in
| this particular case this particular tab will look like this".
|
| While the web was mostly leaf components (text, articles,
| images, links) this separation kinda worked. The moment you
| move into app territory, there are not that many things that
| are reusable and benefit from separation, because your UI is
| directly dependent on business logic and vice versa. And
| because every screen in your app is a unique view into a unique
| part of your functionality.
| dtagames wrote:
| Very true. Even in "leaf" components (I'd never heard them
| called that. Cool.), the actual appearance is often dependent
| on some state that only the parent knows. Is the button
| highlighted or dimmed? Blue or red? Well, the _button_
| component doesn 't know. (It shouldn't). But the parent who
| spawned it must know and pass that information into the
| button by a param.
|
| This should, ideally, be as short and sweet as possible. In
| reality, like you say, the two ideas (visual + biz logic)
| will always be married in any non-trival application.
| dmitriid wrote:
| leaf components as a term appears in various discussions on
| web components. Many people don't see the value in full-
| blown web components(as they have lots and lots of unsolved
| issues), but agree that they may fill the niche/need for
| "dumb" reusable components at the end of the DOM tree
| (hence, leaf :) ): date pickers, buttons, links, all that
| kind of stuff.
| dtagames wrote:
| I've seen tons of libraries of these and every big
| company seems to make their own, then try to release it
| to "help others." It's a noble idea, but the reality is
| that most of the cruft in those component sets won't be
| useful to app developers who aren't making apps for that
| company.
|
| In other words, you are likely to need too many
| customizations even to leaf components to be able to use
| someone else's.
| Aeolun wrote:
| I think eventually everyone just realized that so much of the
| styling is dependent on the element hierarchy that makes up the
| page that it's pointless (and indeed painful) to separate your
| HTML from the component that uses it.
|
| If you are actually using components, that isn't much of an
| issue.
|
| In a time when you'd be returning a whole document every single
| time, it might make sense to say 'style this one document with
| this one stylesheet', and even more so in a time when HTMl was
| still more or less semantic (e.g. an actual document).
| presentation wrote:
| This! Usually CSS doesn't even make sense outside the context
| of the page/component it's styling.
|
| There's also some nice stuff with modern tooling, where CSS
| is global by nature but writing it with your JS allows for
| the platform to automatically namespace your CSS, making
| styling behavior much more consistent.
|
| Separately it also often makes sense to style things not just
| based on the HTML produced but also based on data stored in
| JS; writing your CSS with your components allows for a
| greater level of dynamic styles (which, to be fair, if you
| can achieve with pure static CSS is preferable, but it's not
| always the case).
| ourcat wrote:
| 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.)
| randomdata wrote:
| 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. The CSS and HTML (or
| their slightly modified equivalents) are still logically
| separated from the rest of the logic in the file.
| ourcat wrote:
| I build all the components and get them working with mostly
| 'vanilla' styling. Then he brands/styles any he needs to by
| simply editing the .html and .scss files.
|
| 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.
| randomdata wrote:
| Does he need to know how the Javascript files work,
| though? The HTML/CSS parts are still logically separated
| from the rest of the code. I am not sure someone who is
| capable of working on that type of content would struggle
| to recognize them. As long as the team is consistent, you
| can even reasonably predict exactly where such content
| would be found in the file.
|
| If the designer was handed an HTML page with <style> tags
| embedded, I cannot imagine he would fall down unable to
| figure out where the CSS is, and this is not much
| different.
| qorrect wrote:
| React is garbage I have no idea why it took off. Angular all
| day e'ry day.
| tannhaeuser wrote:
| > _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
| <div style="color: red">
|
| rather than <div color=red>
|
| in a document representation language? Let alone today's CSS
| atrocities. Mind, I'm not talking about CSS' out-of-control
| layout model complexity, but inventing a new syntax (or a
| thousand microsyntaxes really) _on top of_ already syntax-heavy
| markup.
|
| If you think about it, CSS appears to have gotten these ninja
| super-powers because HTML was locked in a decade-long
| stagnation while W3C was busy with XML, RDF, and whatnot. Then
| again, in the last decade using <div>s for nearly everything
| was frowned upon, so with the precedent set in the decade
| before, CSS just had to re-order, re-place, re-arrange ad
| absurdum without any discernible mental discipline. Or, maybe
| the CSS WG people just couldn't stop.
|
| 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.
|
| A false separation-of-concerns narrative has ruined many
| languages and approaches (such as enterprise OOP); for the web
| it was particularly idiotic given it's founded on composable
| documents.
|
| JS? Once it was out there, evolution of HTML and declarative
| UIs basically stalled because there wasn't anything you
| couldn't do using JS. Nevertheless, CSS had _also_ grown into
| outlandish complexity. Basically, the "web stack" of today is
| what any standardization effort should've avoided.
| dtagames wrote:
| > 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.
| q-rews wrote:
| 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?
| Dah00n wrote:
| 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 my
| opinion in that area we are moving backwards very quickly.
| nwienert wrote:
| Totally disagree as someone who grew up building websites
| as "cleanly" as possible, and now has spent many years
| doing all in one: the all in one is simply better in every
| way, it logically makes much more sense to group by
| component than by arbitrary style/structure/logic which
| just isn't the right separation for many reasons that are
| written more fully in many places.
|
| 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.
|
| https://github.com/snackui/snackui
| mdtusz wrote:
| I think we're well past the period of a new framework every
| week - at least in a "real world" sense. Nearly all
| companies will settle on react or vue these days with a
| long tail choosing others, but this is no different than
| any other part of software development - lots of different
| databases, web frameworks, auth libraries etc all exist as
| well and are used.
|
| Most of these "new" frameworks are more because someone
| wanted to scratch an itch or solve a specific problem they
| had, and frontend code simply lends itself well to being
| open sourced. If you don't like the new js tools that are
| made, just ignore them.
| cwizou wrote:
| The pragmatic answer is that, for the the large companies
| usually behind those frameworks, they can have many independent
| teams that are working on split components, without marching on
| each other's toes.
|
| But to me, there's a parallel to be made between both the newer
| trends of components and micro-services, and the old idea of
| Object Oriented Programming. In all cases, you get sold on the
| idea that everything should be cut down into tiny pieces.
|
| Theoretically the separation of concerns has tons of merits,
| but in practice there are a lot of rough edges when those
| separate pieces have to interact with each others.
|
| And the tradeoffs may not always be worth it when your project
| isn't on the scale of those large companies (it very rarely
| is).
| sam0x17 wrote:
| I agree. The real difficulty in software engineering is at
| the seams where systems or components have to interact with
| other systems/components. The more seams, the more
| difficulty.
|
| The key though is that componentization is useful when you
| find yourself writing the same code over and over again.
| That's where DRY steps in and says yeah this should be its
| own component.
|
| This is one reason monoliths are great as an app structure,
| because they let you be as DRY as possible and have as few
| seams as possible (making a component within a monolith
| doesn't create an external dependency, no seam).
| Additionally, there are options nowadays (ruby on jets for
| example) that let you have a monolith repo structure but each
| controller endpoint gets deployed as a separate lambda. So
| you get to have your cake and eat it too.
|
| The analogy really does work fairly well at every level of
| software engineering, from frontend components to backend
| services.
| cwizou wrote:
| Yep, the way I see it is, how much abstraction are you
| willing to accept.
|
| Intuitively you may not want too much, until you find out
| that maybe you could have needed a bit more because of the
| repetitiveness. So frameworks that give you the option to
| gradually increase it when you need are the best. And when
| the documentation follows those patterns it's really great
| (I'd put Vue in that category).
|
| Usually the thinking was, while it may not make sense, it
| will someday when my project grows, so let's adopt it right
| away. And for years I would have said that was a decent
| advice. Nowadays I think that with some of the more extreme
| scales behind some of those trends though, it's not always
| as clear cut.
| void_mint wrote:
| > The distinction between HTML, JS and CSS
|
| When all three of these things have to care very directly about
| eachother, separating them makes less sense.
| k__ wrote:
| A feature usually consists of all three HTML/CSS/JS.
|
| So, if you split by technology, you don't have the code
| belonging to one feature in one place.
| ssijak wrote:
| This is the most correct answer. It also felt wrong to me
| when I first started doing serious frontend development (I
| started it with AngularJS), but than it all made so much
| sense after a few projects and after I _experienced_ the
| benefites.
| politelemon wrote:
| But even then, a feature can end up spanning multiple files
| for reusability.
| q-rews wrote:
| The distinction makes sense on documents but it starts to break
| on apps. Javascript depends on HTML and HTML is generated by
| JS.
| dtagames wrote:
| 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_ or business logic or
| state or whatever word we want to use.
|
| And that's very true regardless of what framework or language
| we choose.
| q-rews wrote:
| 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.
| jshmrsn wrote:
| For web apps, you often want your content/HTML to dynamically
| render different elements depending on application state. Using
| a separate template file and having your logic plug into the
| template is often more complicated than just having your flow
| logic (if/else chains checking application state) return bits
| of relevant HTML/content inline.
| jt2190 wrote:
| > ... [W]hy [are] a lot of new web languages/frameworks are
| mixing logic and content in the same file again...?
|
| In olden days, the DOM was treated like something shared. This
| could lead to a single DOM elements receiving changes from all
| over the place: Multiple CSS selectors would include it and
| apply style rules, and multiple JavaScript scripts might select
| and manipulate it. Spitting the CSS/HTML/JavaScript into
| multiple files just makes it _harder_ to know what 's doing
| what.
|
| The new frameworks are built around the idea that when we need
| to manipulate or style a DOM element then it should be isolated
| from the rest of the DOM, and so should the CSS and JavaScript
| that do the manipulating. In other words, what we often call
| "components".
|
| For convenience, we often group these three things into the
| same file, or into small files sharing the same directory.
|
| Reasoning about them much simpler, because each one is like a
| tiny HTML document with just a few DOM elements. No need to
| review hundreds of CSS selectors or JavaScript event handlers,
| because everything is together in one small package.
| TekMol wrote:
| If you isolate the DOM elements from each other, then how do
| they share common styles? You certainly do not want to define
| the font type for each DOM element individually, do you?
| dalmo3 wrote:
| The development is isolated, but the components are still
| placed somewhere in the dom, so regular
| hierarchy/specificity rules apply.
|
| Granted, some UI frameworks do add a lot of redundant code
| to maximise component independence, then offer JS-based or
| class-based theming to keep development DRY.
| dtagames wrote:
| Lit (which evolved out of Google's Polymer project) has
| many of the same goals of the Imba project and tries to
| reduce the spaghetti of something like AngularJS.
|
| It handles CSS by letting you define it in within an
| individual component (file) but also _import_ a style from
| another file. That way, your shared styles are in one place
| and only the overrides or extra styles needed for a special
| component are in its file.
|
| I think it's wonderful!
|
| Not to denigrate this project in any way, but most or all
| of its goals are already met by Lit[0]. Instead of a new
| language, it uses regular TS and regular CSS.
|
| [0] http://lit.dev
| Shorel wrote:
| CSS "separation of concerns" never worked well anyway:
|
| https://adamwathan.me/css-utility-classes-and-separation-of-...
| resonious wrote:
| Personally I've always been kind of confused by the common best
| practice of separating everything. React and Vue single file
| components made so much sense to me.
|
| I guess if I were to rationalize my position, I'd say it's
| because I have a hard time finding related things when they're
| separate. If a button or "a" tag have a special click handler,
| I want to know when looking at it. If it just has classes, then
| I don't know if that are for style or if they're for behavior.
| I know there are some conventions out there where you prefix
| classes with "js-" etc, but if you just use "onclick" then it's
| obvious and you don't need a convention.
| tiborsaas wrote:
| 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.
| Mavvie wrote:
| With something like Svelte, I see no reason an editor
| couldn't let me choose if I want to see the JS/HTML/CSS in
| the single file (as it is on disk) or split it up into
| separate editor tabs for me.
| scns wrote:
| And have to switch between three files back and forth?
| tiborsaas wrote:
| I usually split my IDE to multiple planes. A 4k, large
| monitor helps though :)
| arodyginc wrote:
| For their demo https://imba.io/ they put styles in a
| separate file, how so?
| klibertp wrote:
| What? How is that a problem, why would it be something
| that's best avoided, and why simply displaying all three
| files at once in one of a million ways available is not a
| solution?
| kingdomcome50 wrote:
| 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.
| klibertp wrote:
| 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 when any one of them
| is opened and/or to make a command to cycle between
| files, similarly to how you can switch between .c and .h
| files in most environments.
|
| For files where the logic, structure, and styling fits on
| a single page - yeah, splitting it into separate files
| doesn't make much sense.
|
| > At worst you make working within the system a real
| pain.
|
| That's what I don't understand - what pain? That it's
| better not to work with it using nano or notepad? It
| simply looks like a pain I would never experience, and
| I'm wondering if I'm right.
| RussianCow wrote:
| > 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.
| klibertp wrote:
| 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 previously. Similarly,
| you mention "large number of files you have open in your
| editor" as if that was a problem of any kind. For me, it
| isn't - I have 60+ files open frequently, but I have
| quite a few ways of searching for/jumping to a specific
| file, buffer, or content that I want to see, and I never
| need to cycle through open files or tabs. Most of the
| time I don't have to care if the file is open - there's
| literaly no difference in the method(s) of getting to a
| file because of its state (open or not).
|
| The differences between my and your environments mean
| that our preferred workflows differ, too, because what
| can be problematic for you can be easy for me, and vice
| versa.
|
| That being said, I also don't advocate "splitting
| everything into super small files". Splitting a file that
| is less than a "page or two" (I see 61 lines of code on
| one page, so less than 120 loc) is a mistake and should
| be done only in special circumstances, while files that
| grew larger than 500 loc should be refactored if it makes
| sense. Files over 1k loc have to be split. That's the
| policy we use at work, and I think it results in a pretty
| nice and easy to navigate code bases.
|
| Back to the editors, though: as long as the codebase uses
| a convention - any convention - consistently, you can
| _make_ it nice to work with, by altering your environment
| to match the convention. This is where the more
| configurable and easier to script editors win big time -
| if there 's something in the codebase you don't like, and
| can't change, you can script it out of sight and out of
| mind easily. Coming from such an editor, I personally
| don't have a strong opinion on how the codebase should be
| structured (which includes the lenghts of files) - I do
| have some preferences, but I'm not very attached to them.
| That's just to signal that I'm not the one of people
| "fascinated" with splitting files for the sake of it :)
| RussianCow wrote:
| > 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
|
| 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.
| kingdomcome50 wrote:
| You are only imagining the case when you have already
| opened/identified all of the files you intend to work on.
|
| Actual workflows diverge significantly from the above.
| It's a matter of cohesion. Yes, co-locating each of the
| files (and _only_ these files) in a single "component"
| directory can help ease navigation and discovery, but
| most of the time it's just easier to keep everything as
| cohesive as possible.
| dec0dedab0de wrote:
| I think its much more of a pain to have more than one
| language in the same file, but I suppose that's a matter
| of preference.
|
| Some practical reasons for separate files, off the top of
| my head:
|
| In-lining JS, and CSS means enabling unsafe-eval, which
| can open up XSS vulnerabilities if you use any content
| from users or gathered from a source you don't control.
| You could also do the unsafe-hashes, but that's kind of a
| pain.
|
| If you're not making a SPA, it would not be fun to copy
| the CSS to all of your files.
|
| If you do not couple your CSS to your site, you can reuse
| it across many sites and have the same style. Say if you
| have separate site for your blog, but want it to look the
| same as your main site.
|
| If you're working on a team splitting things up into
| separate files will avoid some merge conflicts.
|
| Chances are they will not be updated all at the same
| time, so caching would speed up page load times, as the
| user would only have to download the changed files
| lhorie wrote:
| Personally I think it's not so much about separation of
| concerns/technologies per se, it's that this debate boils
| down to a different debate under the hood: the one about
| folder-by-type vs folder-by-feature[0].
|
| The gist is that folder-by-feature is generally preferrable
| because it requires less context switching (in the literal
| sense of jumping between multiple different far away folders
| and scanning each for the thing you're looking for)
|
| Single file components force you to organize code in a
| folder-by-feature structure, to a large extent. You _can_ use
| folder-by-feature structure alongside with separation of
| technologies, it 's just not that common to see it because
| the tooling to support it is not quite as optimized.
|
| [0] https://softwareengineering.stackexchange.com/questions/3
| 385...
| adam_ellsworth wrote:
| Absolutely stunning work. Love that it's able to work so well
| with TS. Also please tell Puppetmaster Pumpkin 'Hello' on my
| behalf and give some head scritches :3
| peey wrote:
| 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?
| nwienert wrote:
| I think the general idea is good, but then again I built a whole
| startup from the same principles ~6 years ago.
|
| 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!
|
| https://youtu.be/HHTYHm6qLFY
| k__ wrote:
| Reminds me of my LiveScript days.
|
| I'm impressed!
| brundolf wrote:
| I disagree with a couple of the choices made here, mainly the
| (apparent) lack of static typing
|
| 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
| prionassembly wrote:
| > Getting started > > The best way to get started with Imba is to
| use npx to get a brand-new project up and running.
|
| What is npx?
| rovr138 wrote:
| It's a command from node that allows executing commands from
| node_modules.
| politelemon wrote:
| It's a tool that comes with NodeJS.
|
| npx will run the node package from node_modules if it's
| present, else it will npm install the package and then run it.
| jl2718 wrote:
| 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
| confusing, outdated, and unnecessary for my performance needs,
| versus going raw with the latest features. It sounds like I might
| be missing something that could hurt me down the line. Thanks.
| moron4hire wrote:
| 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 to
| work.
|
| But if you already have the componentization mindset, I don't
| think React really adds anything. As you have said, managing
| raw DOM operations can be significantly faster. And because you
| have componentized your code, they are significantly easier to
| reason about.
|
| The only problem is that working with a medium-sized smash of
| code is not as painful in vanilla JS as it is in React. So if
| you've grown your application over time, adding bits and bobs
| to it piecemeal, you're likely to end up with an application
| structure that is inherently difficult to manage. Then folks
| rewrite in React, get forced to componentize, and lo-and-
| behold, everything is much easier to manage.
|
| At this point, whatever gets you there, gets you there, I
| guess. Personally, I make VR applications that run in the
| browser, so I coveteth performance.
| jl2718 wrote:
| 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.
| RussianCow wrote:
| > I do not like testing a DOM tree I didn't build.
|
| What does this mean?
| sebular wrote:
| You're going to struggle as a novice if you're quick to
| form opinions about things that you don't fully understand,
| especially if those opinions involve rejecting wildly
| popular tools used by people with far more expertise than
| you have.
|
| People who understand React/Vue/Angular are free to
| criticize them (and have many valid reasons for doing so),
| but when you do it after following a beginner tutorial or
| two, you're just being ignorant.
|
| How do I know this? Because you're criticizing React for
| forcing you to "do everything through a JSX template" and
| "debugging through a transpiler", which tells me that you
| aren't aware that React can be used without JSX and without
| any transpiling.
|
| Since that information is available to you on about the
| fourth paragraph of the "Getting Started" page on
| reactjs.org, you clearly haven't bothered to learn much
| about it at all.
| beebeepka wrote:
| "I know almost nothing about the subject at hand, so here's
| my expert opinion on it"
| moron4hire wrote:
| I've been a software developer for 20 years. I've been
| doing JavaScript since it was invented. I do actually know
| a lot about these things.
| danenania wrote:
| Modularity or componentization as you call it (I like that!
| :P) is definitely one of React's main advantages. But I'd say
| just as important is that it acts as a trojan horse,
| essentially, to get people using the "good parts" of
| functional programming without having to understand FP
| deeply.
|
| 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.
| 49531 wrote:
| Most frontend frameworks are not created to solve performance
| of vanilla web applications, but rather to make engineering
| larger and complex applications easier.
| sidlls wrote:
| 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.
| lyaa wrote:
| 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.
|
| It's so much simpler to build an app if all you needed to
| do is get the minimum features done.
| sidlls wrote:
| 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.
| lyaa wrote:
| I think we differ in what we consider "justification." It
| seems to me that you are using the moral judgement of the
| sacrifice of perfect-pretty-code while I am considering
| the business-operations evaluation.
|
| 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.
| lhorie wrote:
| (Disclaimer: I'm the author of Mithril.js)
|
| I looked at this a few years ago and IIRC, it refers to a very
| specific optimization for recycling DOM nodes in very specific
| cases. Recycling basically just means reusing pre-existing DOM
| subtrees instead of naively creating new ones. To my knowledge,
| Inferno.js and Mithril.js implemented a similar optimization
| but eventually dropped it because it was difficult to compute
| when the optimization could be applied and it wasn't worth the
| complexity (when using virtual dom anyways; my understanding is
| that imba doesn't do virtual dom)
|
| I recall Imba always had quite nice perf numbers. Recycling DOM
| nodes did indeed give huge performance increases in synthetic
| proofs of concepts I did for Mithril.js. A good real world
| example where it's supposed to shine is tabular data: typically
| you'd key your rows to get good array diff performance, but
| this means paginating recreates the entire table from scratch
| every time. Recycling means reusing the existing DOM instead of
| re-incurring document.createElement call overheads for the
| entire table. Of course, in practice it's quite a bit more
| difficult to deal with edge cases (e.g. DOM state such as
| element focus)
|
| The two things that I thought were problematic with Imba were
| a) lack of typing (which has since been addressed) and b)
| compiled output readability (i.e. it looks nothing like source
| code). It looks very nice otherwise, and it has come a long way
| since 7 years ago.
| SkyMarshal wrote:
| You had me at "indentation-based syntax". :)
| daveidol wrote:
| Lost me there tbh :)
| thomasfl wrote:
| Always impressed by what you are able to achieve Sindre.
| throw_m239339 wrote:
| Looks great! Congrats for being a YC alumni. One day myself
| perhaps...
| burlesona wrote:
| This looks awesome, thanks for sharing! I love "bringing the
| elegance and concision of Ruby into the browser." I happen to be
| about to spin up a new project, so I'll give this a shot and see
| how it works in practice. Cheers!
| abdellah123 wrote:
| Does Imba support SSR? is it in the roadmap?
| ArlenBales wrote:
| Really cool. This looks like an ideal language for super quickly
| developing small apps. I am probably going to use this to write a
| very minimalist hiking photo blog I've been putting off.
| whiddershins wrote:
| How would you compare this to svelte?
| c-smile wrote:
| > Imba's Memoized DOM approach is _an order of magnitude_ faster
| than Virtual DOMs (Vue, React). Learn more here:
| https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me...
|
| Just in case...
|
| Sciter's native built-in Reactor
| https://github.com/c-smile/sciter-js-sdk/tree/main/docs/md/r...
| is using that so called "Memoized DOM" approach, which, as far as
| I understand the wording, is "diffing with real DOM": you have
| real DOM tree on the left and virtual DOM tree on the right.
| Reconciliation in this case is just patching of the left tree by
| the right one.
|
| Essentially Sciter's Reactor is a unification of React with
| WebComponents ideas into single entity.
| jazzyjackson wrote:
| I am glad you persevered. I've been working on a language for 3
| years now and sometimes I lose faith. It's good to know that
| sometimes, projects can be finished (or at least shipped ;)
| derangedHorse wrote:
| I wonder if there are plans for an imba course on scrimba. I
| think it would be a fun concept and could be a used as a free
| introductory course (both familiarizing more of the world with
| the language and the scrimba platform)
| somebee wrote:
| Yes, there are plans for an imba course on scrimba! It is
| almost comical, but scrimba was originally created with the
| sole purpose of teaching people Imba. Here we are, 4 years
| later, finally preparing to make a course :D
| rtcoms wrote:
| So meta
|
| A course for learning Imba on scrimba, which was made using
| Imba to make people learn Imba.
| laserpistus wrote:
| Yep, we will be making both individual scrims to use as
| examples and tutorial about building something more
| comprehensive.
| thobond wrote:
| Are there any other commercial companies, or is there someone who
| has used imba to develop their web apps except for OP?
| adventured wrote:
| Meta Imba -
|
| https://i.imgur.com/k35ObtV.jpg
| arodyginc wrote:
| So, had gone through samples and my conclusion as a seasoned web
| dev with projects as big as having thousands of files with
| hundreds business scenarios, imba is not the setup for this
| scale.
|
| When people come and go, requirements change, new tools come
| along, trading flexibility to some initial development boost is
| not worth it, imo
| mleonhard wrote:
| Next time, please explain why.
| soheil wrote:
| How does one create a (for profit?) company around a programming
| language and starts posting jobs? There is nothing about
| monetization on their website.
| debarshri wrote:
| Hey there! I think it is really cool language. You can basically
| get started in minutes.
|
| Does imba also have native app framework too?
| somebee wrote:
| No, not right now. The current version of tags is relatively
| tightly coupled with the DOM for maximum performance. It should
| be possible to create a bridge like react-native but it hasn't
| been an area of focus thus far!
| ampdepolymerase wrote:
| Are there any companies using Imba in production aside from
| Scrimba?
| th3h4mm3r wrote:
| First of all really a great work! Incredible!
|
| Second, in my opinion, looking at the documentation, I don't
| understand all immediately or, better, I've got a little bit of
| confusion regarding a lot of things.
|
| I'm unable to find "connections" with other languages /
| frameworks that I use every day (for example Angular, Vue and so
| on). So my question is: is somewhere some big example in the
| style of "Angular Heroes" example?
|
| I really want to understand better every single part of Imba and
| I think that with an extensive example it could be more simple
| and fast.
|
| Thank you.
| davedx wrote:
| 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 of very well thought-out demos showing off
| different aspects of the language. (I almost laughed with
| pleasure at the "autorender=1fps" part).
|
| Great work.
| Griffinsauce wrote:
| Totally agree, this is obviously the work of someone who knows
| how to teach.
| pier25 wrote:
| The authors of Imba care a lot about education and are
| working on Scrimba.
| soheil wrote:
| > Amazing Performance
|
| With no benchmarks to back up that statement?
| pier25 wrote:
| Here are some results for v1:
|
| https://krausest.github.io/js-framework-benchmark/current.ht...
|
| (but the author claims v2 is much faster)
| nsonha wrote:
| I can't believe it, this even has a dsl on top of css, baked in,
| as if that alone isn't a controversial thing. The rest of the
| language is really just around "least amount of characters", a
| really lame motivation that has been done countless times in my
| lifetime.
|
| I'm all for new programming languages but you need to justify it
| with actual new ideas and new ways of thinking not some opinion
| about syntax. Guess what? everybody has one, they're all
| different.
| agd wrote:
| This looks great however I'm skeptical about dom memoization.
| VDOM + immutable data structures seems to be much simpler
| conceptually and may provide even better performance.
| divs1210 wrote:
| The product is really cool, and so is the language!
| Congratulations and all the best!
| shireboy wrote:
| Looks great! I'll definitely be checking this out for my web
| work. One thing I see- and only mention because the rest of the
| product seems like it has an eye for detail- the "we are hiring"
| link and paint component on imba.io have minor layout issues on
| iOS Safari on iPhone 12 Max Pro. I haven't tried other devices,
| but mobile responsiveness is one thing I look at when evaluating
| tools like this.
| codesternews wrote:
| Congrats
|
| How do you make money out of it?
|
| Are you working full time on this?
|
| Why YC funded this, could you tell me opportunity here?
| mstade wrote:
| As far as I understand it, the language came first and in order
| to teach it to others the founder created a screencasting tool
| of sorts, which became a company in its own right:
| https://scrimba.com
|
| Ironically, it seems the company focused on content to teach
| primarily other technologies while using Imba to build it all.
| It's a rather fascinating story actually, which I'm
| paraphrasing and probably mostly got wrong, but if you're
| interested you can read more on their hiring page:
| https://scrimba.recruitee.com
|
| N.B.: I'm not in any way affiliated with Imba or Scrimba. The
| first time I heard of the technology and the company was today,
| through HN, so I have no skin in this game. I'm probably also
| mostly wrong about everything above, so you know..
| Artistry121 wrote:
| Scrimba
| kvakkefly wrote:
| They funded https://scrimba.com, an interactive coding tutorial
| platform, that is written in Imba.
| dvt wrote:
| Congrats on the launch! Like everyone else, I wanted to say great
| splash page and the syntax looks quite beautiful. Will do more of
| a deep dive once I get some free time, but it's quite promising.
| savmat wrote:
| I'm sick of programming languages that use "fast typing" and
| "productiveness" as a selling point. There's no selling point in
| being productive doing a counter in a few seconds, production
| scenarios are far more complex and very often all those new
| programming languages fall short to their promise. Btw I don't
| want to be fast or productive, I want to write code that works
| decently and is great for other humans myself included
| turtlebits wrote:
| 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.
| cflewis wrote:
| I sure am tired of Javascript being the lingua franca of the
| web. Imagine if we decided C was good enough and now all
| programming languages from that point on should just be
| something that cross-compiles to it.
| mprovost wrote:
| Isn't that what WebAssembly is for? It's kind of the web
| version of C pretending that everything is a PDP-11.
| void_mint wrote:
| Support WASM then?
| arcanon wrote:
| We need a Coffeescript Renaissance!
| phil294 wrote:
| Nothing is holding you back from using it!
| nsonha wrote:
| lack of types and it used to be ignorant of perf in the
| generated code (creating IIFE unnecessarily)
| phil294 wrote:
| Regarding types, you're right, though JSDoc can get you
| very far
|
| 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)
| scotty79 wrote:
| World needs a version of coffeescript that compiles to
| typescript.
| Mikeb85 wrote:
| Then don't use it. Some of us do like productive (ie.
| expressive and batteries included) languages. PHP, Python,
| JavaScript and Ruby still power most websites. There's plenty
| of choices for enterprise languages and frameworks if you want.
|
| Productive, everything included languages/frameworks such as
| this are great for freelancers, designers, students, and anyone
| who wants to get up and running quickly. You can also still
| create maintainable projects with expressive languages (Google
| and Python, GitHub and Ruby are a couple examples).
|
| People are doing things that don't break with 'productive'
| languages.
| methyl wrote:
| It depends. If your work is to create a new counter app every
| day to support some specific, single usecase, in other words
| you write a lot of simple apps and not a single complex one,
| then it's definitely a win for productivity.
| RussianCow wrote:
| Who actually does this for a living? And where do I sign up?
| :D
|
| In all seriousness, I've never worked at a company that did
| anything like this. What is the use case for creating lots of
| small apps as opposed to maintaining a larger product?
| nsonha wrote:
| > create a new counter app every day to support some
| specific, single usecase
|
| sounds like the kind of thing that programming was invented
| to eliminate
| lhorie wrote:
| That's not really a complaint about languages so much as it a
| complaint about marketing though, is it?
|
| I don't go learning every language to mastery level, but I try
| to at least keep track of whereabouts they lie in the spectrum
| so I can cut through marketing-speak when I see it.
|
| The way I see it, if a thing is being dogfooded in production,
| it's production grade. People can debate go-vs-rust or whatever
| till they're blue but the reality is simply that you can ship
| something with either and there are always going to be
| proponents and detractors for each side.
|
| While I haven't followed Imba that closely, I've been aware of
| it for years, and I have to say it's one of few projects that
| actually has interesting technical takes on several fronts.
| k__ wrote:
| I don't see the value in being able to "type fast".
|
| I see it in less visual clutter.
| arcanon wrote:
| Yes. Which gives you more control over how you make the code
| look. DSLs.
| lowercased wrote:
| You could be doing stuff that works decently, is great for
| humans, and still be productive (maybe even fast). Or figure
| out how to do it faster next time.
|
| Someone else may want you to be fast and productive. Or...
| they'll find someone else who can provide what they want who is
| faster and more productive than you.
| laserpistus wrote:
| Fair enough - and so you skip the languages that doesn't fit
| that bill for you and pick one that you feel bring you those
| outcomes. No hurt feelings!
| cortexio wrote:
| i wouldnt call it a language, it basically asks u to install
| nodejs, which is the actual language itself. U do however have a
| custom syntax, but i find your project much more like a web
| framework. Personally i would add strict typing. But that's just
| me i guess :)
| xrd wrote:
| The thing I'm looking for, and didn't see it immediately on the
| example page, is how easily you can use JavaScript libraries. I'm
| sure you can, but is it like Svelte, where you can just use them
| almost as-is, or like React and Vue, where you need to wrap them
| inside special wrapper libraries that expose them as React hooks
| or whatever.
|
| Svelte is so great because you can use libraries as is. React is
| great (if you like it) in that it has a huge number of converted
| libraries and a huge community that is quick to convert new
| libraries.
|
| Anyone know what the story is for Imba in this light? It looks
| great at first glance.
| mg wrote:
| 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 :)
| somebee wrote:
| Tbh, var is actually deprecated since v1, so any mention of var
| in the docs is a mistake. Are there any other languages using
| 'con' for constants?
| veidr wrote:
| No, but there should be!!
| amalantony06 wrote:
| Why does const irk you? const sounds a lot clearer than con. Is
| that your primary criteria for picking a language? ;)
| mg wrote:
| I think it has three reasons:
|
| The more often a construct is used in a language, the shorter
| I like it to be.
|
| It groups variable definitions mentally by having them all
| the same length if they are "var", "let" and "con".
|
| It would often make the code look more uniform which is more
| beautiful in my eyes. Example:
|
| https://github.com/facebook/react/blob/cae635054e17a6f107a39.
| ..
|
| I would prefer the lines 226 and 227 to start with "con" and
| "let". It would make the code visually more appealing to me.
| jazzyjackson wrote:
| As far as code being visually appealing, for me those two
| lines are the least of that code's troubles.
|
| I'm sympathetic to wanting code to have good aesthetics. If
| I was writing those lines I probably would have daydreamed
| for 5 minutes thinking of new names for map and record so
| that the equal signs would line up.
| [deleted]
| scns wrote:
| Good idea IMO. That feature should be pretty easy to add
| (famous last words).
| OJFord wrote:
| I've never used a language with a 'cons' keyword, but
| nevertheless that's what I'd assume your 'con' was, if you
| didn't tell me otherwise.
|
| I'm no particular JS fan, but 'const' is much clearer, it's a
| complete syllable, just like 'var' or 'func'. Yes 'fun' is
| used, but I think that's awkward for the same reason.
| [deleted]
| lucideer wrote:
| Why do you think this?
|
| "const" seems clearer to me. "con" seems very open to
| misinterpretation: could mean many things.
|
| Are there any advantages to "con" over "const"?
| mstade wrote:
| My guess is the OP dislikes the difference in keyword length.
| cgag wrote:
| I just always use let because it looks better. Const
| provides pretty much no value in js anyway.
| jsf01 wrote:
| It is useful for code readability. When you're skimming
| and trying to understand a large chunk of code, if almost
| all the variables are declared with "const" and then you
| come across a "let", you immediately know to look for
| where it will be mutated elsewhere.
| Zababa wrote:
| Is the difference in length bothering you? In that case I find
| that let for immutable and var for mutable is pretty good,
| although for a language that's lose to JS that might not be a
| good idea. Maybe let for mutable like in JS, and val for
| immutable? (inspired by Scala).
| jazzyjackson wrote:
| Personally I don't use any languages with reserved words
| therufa wrote:
| that limits the number of languages to a handful. like
| brainfuck and similar ones. doesn't it?
| jhgb wrote:
| Lisps don't have reserved words, generally.
| jazzyjackson wrote:
| Not even cons and defun?
| jhgb wrote:
| Depends on what you mean by "reserved word". In Common
| Lisp, you can define your own cons and defun, provided
| that you're not attempting to mutate the respective
| symbols from the COMMON-LISP package. That can be
| achieved by either defining your own cons and defun and
| shadowing the cons and defun from the COMMON-LISP package
| (typically for function or macro bindings), or just
| straight up using cons and defun from the COMMON-LISP
| package in "legal" ways - for example (let ((cons 1)
| (defun 2)) (list cons defun)) is legal and evaluates as
| '(1 2) since using those two symbols as names for lexical
| variables doesn't break the running Lisp in any way. In
| the former case (of defining your own functions/macros
| accessed as "unqualified" cons or defun from your own
| code) it's up to you if you consider cons and defun to be
| "reserved words" based on their package or not (packages
| for reserved words being something that languages
| explicitly recognizing the concept of a reserved word
| don't seem to have, so it's not clear how this should
| qualify). In Scheme, a Lisp-1, it's kind of free-for-all,
| especially in R5RS where you don't even have to bother
| with hiding standard bindings.
| jazzyjackson wrote:
| APL cheats by making everything a symbol.
| nsonha wrote:
| 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.
| veidr wrote:
| You are obviously right.
|
| The 'const' nomenclature is an abomination before science and
| human progress. However, given the prior art, I don't think we
| can hold it against a new/emerging language.
|
| Anders, help us! Do the right thing. You are the only one who
| can.
|
| (Of course, 'const' could be grandfathered and still work
| forever. Right-minded people, please upvote this obviously-
| right person at least back to a neutral #000.)
| __ryan__ wrote:
| I've thought about this a lot. I considered "con" for
| constants. I don't hate it. It also works as a double
| entendre-- "con" in Spanish means "with". So the following code
| _could_ be read as "with _name_ equal to Brad ".
| con name = 'Brad'
|
| I can't help but feel that it's somewhat jarring though.
|
| If I had my druthers, I think I would choose "var" and "def" to
| declare mutable and immutable variables, respectively.
| def PI = 3.1 def degreesToRadians = degrees => degrees *
| (PI / 180) var degrees = 180 var radians =
| degreesToRadians(degrees)
|
| Edit: After thinking about it some more, I think I prefer
| "const" over "con", but "def" over both.
| Zababa wrote:
| > It also works as a double entendre-- "con" in Spanish means
| "with".
|
| Triple even! In French it's the equivalent of "cunt".
| archibaldJ wrote:
| That's a very tight integration with JS&TS! Are you compiling
| into TS and then to JS? Or is it more of a decoupled process that
| was set up for the type-checking (like how tsconfig and babel
| works together)? When I was trying out ReasonML a few years back
| (and being unfamiliar with OCaml) I ran into some problems with
| bridging across types.
|
| I checked out https://github.com/imba/typescript-imba-plugin for
| a bit and I'm still quite lost. Love to learn more!
|
| Also, what is the cross-file refactorings in the tooling? Thanks!
| somebee wrote:
| Yeah, the typescript-imba-plugin does quite a lot of magic and
| might be a little rough to get into.
|
| We essentially do the type-checking by compiling the files to
| js with jsdoc annotations, and for some features we also
| generate `.d.ts` files (see https://dev.to/somebee/global-type-
| augmentations-with-automa...). There is still a lot of work to
| be done on the integration. There are bugs and missing
| featyres, and the type-checking only happens in the tooling
| atm. The compiler could not care less about your types.
|
| Since it is developed as a ts language plugin, references to
| imba files (like goto definition etc) works from ts/js files
| (you can include imba files in js/ts), and renaming methods /
| files works across all ts/js/imba files in your project.
___________________________________________________________________
(page generated 2021-08-17 23:00 UTC)