I've been following Imba for the past several months since the initial announcement on HN.
I like the clean syntax, tags, and high performance, so I hope you guys attract interest despite all the library/framework fatigue we're experiencing in frontend JS land. It's rather refreshing to be able to write code and view all together, like <div.marker>.css(appropriate_styling)
It would be great if you had some walked-through example apps on webpages (like the old site used to have). That kind of thing helps people better understand the benefits of your approach.
Non-standard tags generally work in all browsers modern, but they aren't part of the spec. It's just like custom attributes which don't start with `data-`. They're recognized and work, but not strictly speaking legal. Your code fill fail HTML5 validation tests.
All these languages du jour should go out of their way to answer the question: "why bother?".
10x faster than react. OK cool. Except unless it has something like react native it's irrelevant if you might want to write an app in future with any sort of code reuse since you'll be tied to the web (unless you want the inevitable world-of-pain of trying to integrate this preprocessor into your xcode/android builds...).
These are devs who would rather build tools to build a web app than to build a web app. Different people have different itches. We don't have to consume what they produce. Just have to read about it on HN.
Well and fine, but those tools then need to be maintained forever, and they become yet another tool in the stack for developers who come on board to a company which has adopted them. It's easier and quicker to learn a new library like React, or even a new DSL like JSX, than a new language.
A few months ago I played with ImbaKit (https://github.com/judofyr/ImbaKit) which is essentially React Native iOS implemented on top of Imba. It's just an experiment for now, but there's only time and money which stops this from becoming a proper tool.
Building programming languages just for the heck of it is highly underrated, I think every programmer should at least try implementing a few languages of different paradigms.
Implementing a stack-based language made me write more readable point-free Haskell. Implementing a text-processing-oriented language taught me a ton about Unicode and Korean. Both are fun to work on.
This won't solve the problem of having to learn three different technologies, but whatever might mitigate the pain that we call JavaScript (quirks) is welcome.
People who specialize in webdev learn things by heart so perhaps they forget how bad they are.
The React core team themselves admit that React Native is not about code-reuse, but instead what they call "learn-once-read-everywhere" To require that all javaScript web frameworks compile down to native app code is ridiculous.
It might not be about code reuse, but there will be things that can be ported, just not the DOM stuff (e.g. redux/flux logic, other UI-independent business logic).
I get the whole "because it's fun" reason - just make it clear that that's the motivation, and don't give the impression it's a serious React competitor if it has major shortcomings.
I'm fatigued by the continual "x times faster than React" libraries, as if that really matters. As with all the language/framework debates it comes down to the ecosystem. Raw speed just doesn't cut it for me.
Yes, because everyone who uses React also uses React Native. 100% No one has separate repositories and no one keeps frameworks from crossing platforms in order to preserve some degree of software stability these days.
I hate it when people say, (and I'm paraphrasing) "well there's software for everyone's needs" but there really is. Everyone participates in different communities and ecosystems, and not everyone is riding the latest FluxTypeGoNativeAngular2 rollercoaster.
There are plenty of people who don't even use React because why bother?
And if I use react native, I'll still be tied to Javascript, which is one of the web technologies that people try to get away from when trying to get away from the web.
If I pick anything I'll be tied to something. If I (attempt to) write POSIX only code in straight C - I'll basically be tied to doing only things that can work in that kind of environment.
I have a backlog of personal projects of various kinds that I have been tinkering with for years now. But since I'm a back end guy, that's what I normally work on when I have free time.
Every time I decide that I'm going to take the plunge and get down and dirty with front end stuff, I get completely paralyzed by choice, and I end up deciding that the most sensible way for me to move forward is to learn the fundamentals and design front ends with html + CSS + vanilla JavaScript.
As you can imagine, my elegant back-end designs have interfaces the 90s would have deemed tacky.
I really like the syntax (Python guy checking in here), but I don't even know where to start integrating this into a Pyramid app or what to do with it.
I don't even know how to get started here. I have a market research app for building questionnaires. Like SurveyMonkey, but different. I want the front end to be trello-like so that you can move the questions around that way.
I "know" JavaScript pretty well at this point. But when I look at the front end code for an open source trello clone, I swear it's just effing magic. Doesn't even relate in my mind to the language I thought I've been learning all this time.
Since these kinds of threads tend to attract a lot of front end people, I thought I'd ask here: is this an appropriate language for a trello-like interface?
There was a certain point in my career when I was learning Python when I went from knowing how to write classes and functions to being able to know what classes and functions to write to achieve my goals.
I know how to do things in JS, but I have no idea what to do to accomplish my goals.
- Don't worry, there's only a few different paradigms in use by the different libraries and frameworks out there. Just look at the examples and see which one piques your interest.
- Do some analysis to break down your problem into manageable steps, until you reach steps small enough to action. For example, a task tracking board might have the following components: columns (representing "status"), drag and drop (which changes the position of some DOM elements, plus updates the task status), and a form (to capture the task status). So, look for ways to solve each of those problems. e.g. column might be made easier using a grid layout system, such as provided by Bootstrap. Drag and drop can be handled using HTML5 features. And form handling can be made easier (or fancier) using any number of libraries out there.
I wouldn't jump on a brand new language for the purpose of solving a problem, if you don't have a clear idea of the solution you would like to implement. Writing code is a means to an end, not a goal itself. It'd be easier to write a solution using methods you're familiar with, then rewriting it using different technologies.
For pet projects my advice would be a RESTful Angular Front-end and some styling framework like bootstrap or foundation. If it's a legit project I'd recommend hooking up with a Front-end developer and/or a designer/dev.
Doesn't solve any of the big problems with large scale javascript apps:
1) Lack of type checking leading to exploding runtime exceptions
2) Object inheritance/prototype is weird and counter intuitive to other OO languages
3) Lack of proper encapsulation leading to spaghetti code when combined with #1
I suspect we are in for a new era of languages targeting web assembly to be used as webapp frontends and backends but if they don't tackle the big issues above then what is the point?
This is too clever by half. Some tools/languages are more amenable than others to creating and maintaining large apps. Very large applications have been written and maintained in C/C++ for decades. My contention is that Javascript is particularly ill-suited to the creation and maintenance of large scale apps in the long run for the reasons explained.
Any new language which purports to be an improvement upon Javascript should at least attempt to rectify these issues. That's my thesis.
This is actually quite fascinating (and part of my upcoming book...)
Despite the obvious high/low-level language differentials, people have been managing multi-million-line C code-bases since the 80's. Then again, think of how little the build tooling has actually changed -- instead of fragmenting, you're left with llvm, gcc, make at the core of most compiled software.
JavaScript is the exact opposite with the lowest possible barrier to entry (built-in to every web browser...), and the proliferation of frameworks and libraries may be due to this in combination with the lack of fundamental understanding of design patterns that can scale. Lots of people trying to partially solve symptoms, missing the forest for the trees.
Theoretically there's nothing preventing good patterns in high-level UI development, but I'm not quite sure it's been done right, yet and have no idea when the dust will settle.
Javascript and other dynamic language like it are very good prototyping languages and for developing a quick mock-up to explore the pros/cons of a potential solution to a problem. But the lack of type checking and proper encapsulation turn into big headaches when scaled to a large app with even a few more junior developers.
Without a compiler/type checker to help spot obvious problems in code runtime exceptions explode. This happens even for senior developers. And the lack of proper encapsulation other than by convention can/does lead to an explosion of the surface area of source code that a dev needs to know and be familiar with in order to refactor and make changes to large codebases which makes for very brittle large apps.
Hence, I look forward to new languages targeting web assembly that will be more amenable to creating/maintaining large scale and long lived apps.
JavaScript is a toy language wherein I shake my head in disbelief every day that it is my primary language, but I have found it is possible to write typesafe code with vanilla JavaScript. With tooling and a rigid coding style observed by all developers, I'd say medium-to-large codebases (100K and up) can be maintained and extended just as well as other C-like languages.
Using ultrastrict tools like Google Closure Compiler in conjunction with JSDoc comments gives you type checking along with minification and closure elimination.
If you don't want the harsh taskmaster that Closure Compiler can be, IDE's like IntelliJ are able to navigate (with plugin helpers) your Node.JS codebase and build a useful type library. Again, JSDoc comments are critical here, and if you markup your JavaScript accurately and completely, you wind up with an editor that gives you very good type correctness warnings and inspections. Just keep your eyes peeled for yellow highlights and squiggly lines, and you can have confidence that your codebase is clean. JSDoc is very verbose, which is a shame, and you have to get good at forming types that are conducive to its tags. A good coding style document can go a long way to making that possible.
I've found boring JavaScript groks best for all tooling. I stay away from mixins and mostly stick to boring old JS prototype definitions where the mutable bits are @type'd and assigned in the constructor to 'this'. Chrome can JIT these types of prototypes the best.
Of course, there's no substitute when maintaining a large code base than to run with a comprehensive test suite.
Well put. I've been keeping an eye on elm (elm-lang.org) for a bit to see if it stands the test of enough time for me to decide to try it out. It, at least as far as I've seen, tries to address these concerns.
FWIW, having tried Elm, I was very impressed with:
1) Type checking... yay!
2) Awesome compiler error messages that help fix #1
3) Purely functional language with immutable data structures helping performance
4) Reasonably easy and well thought out encapsulation mechanism via modules
On the other hand I was put off by:
1) Very opinionated about design patterns with a react style gui framework
2) Signals are hard to explain and don't easily map to more familiar patterns
3) Not much (if any?) server side development
I think Elm would really benefit from something like built-in support for Qt-style signals/slots that are much easier for newcomers to grok and a much less opinionated focus on the one-true-react-style-design-pattern
But I could very well have missed something. Just my two cents.
Yes, it is and the first reason is related to #1. Prototypical inheritance doesn't make much sense outside of a dynamic language. The second reason is because Javascript is disguised to look like Java and hence people familiar with the C-family of languages are surprised and baffled because Javascript is using the C-family syntax and idioms for classical inheritance to mask the very different prototypical inheritance.
It was designed from the very beginning by Eich to look like Java and not because subsequent people tried to "fix" it. Where are you getting this stuff?
ES2015 just added the class keyword to make it look like java last year. IIRC the new keyword wasn't part of javascript in those first two weeks when javascript was released.
The point is that Eich made Javascript use syntax and idioms from Java from the very beginning and it wasn't just later evolution of the language to "fix" it that did this.
'class' wasn't added to make it look like Java. It was added as sugar for a common pattern that everyone was already using. Many languages other than Java have a class keyword.
Because it's a useful pattern, that people were using heavily. Not sure why you're trying to suggest some kind of ill-intent.
A nice thing about prototypal inhericance is that classical inheritance can be implemented in it. People were doing that commonly enough that it made sense to add sugar to do it more directly, and signal intent more clearly to the reader.
I have a lot of respect for Lisp/Scheme, but I wouldn't regard Emacs as the most maintainable of large scale apps. Besides, the ability level of the average Lisp/Scheme developer and the average Javascript developer is likely not commensurate.
It is funny that I downvoted on YCombinator site. :-)
See few hints how to write efficient lisp: http://www.paulgraham.com/carl.html . You can apply them to JS too.
The last story there has many interesting comments. I recommend reading through it (and looking for comments by "somebee" and "judofyr") if you want to understand more about the philosophy behind the Imba.
This submission is mainly because the website has been updated with more documentation and examples. If you were interested earlier and found it difficult to get started, it might be worth a second look now.
Learning yet another new language for the sake of just knowing another language? Not particularly.
There's an incredible amount of churn in the web languages/frameworks arena. A few years ago it seemed like every week another PHP "MVC" framework was released with exactly the same features as the last one, but with claims that it was faster, more robust, more extensible, and so on. At one point the "big players" were CakePHP and CodeIgniter. Now they seem to be Symfony and Laravel, but feature-wise there doesn't seem to be a huge amount of difference to how your application is structured in these particular frameworks.
Now the churn seems to have shifted away from PHP to JS and JS build systems, and lo and behold we have Imba, "a new programming language for the web".
Sometimes these tools offer clear advantages, other times not so. But often the lifespan on these seems to be less than a year. Everyone is excited about Backbone for six months, until Ember comes out and now no one talks about Backbone. But then Angular comes out and no-one talks about Ember. Investing time in learning any new tool can feel like a huge waste of time when there's a high chance that said tool will disappear a year or so down the line.
Moving this away from the land of web, a new language should at the very least offer a new perspective on something, for example Rust's approach to memory management is intriguing enough for it to potentially be worthwhile.
I like learning new skills and techniques. A language with a different syntax and some sugar-coating that is fundamentally the same as something I already know isn't that.
I do like learning new languages, but there's a certain amount of fatigue in this particular space, given the pace of announcements and limited time. There's a worry that one could spend all one's available time for learning new things and have learned nothing of value in two years.
For this to be of value, it has to provide at least one of four things:
1. Becoming a widely-adopted system (like node.js)
2. Strong influence on widely-adopted systems (like Elm)
3. Insights that influence one personally (like most any lisp)
4. More fun than alternative things one could be playing with
I like learning new languages that are of VALUE to learn: to quote Alan Perlis: " A language that doesn't affect the way you think about programming, is not worth knowing."
Imba doesn't seem to do anything new, just add some new syntax that seems similar to coffeescript.
If you want to make a new language, good on you, but don't trumpet it as the next big thing, that's a revolution, unless it's doing something new, or at least has a different idea about how to do it. Failing all that, at least have it be good for getting stuff done fast. This is the "perl approach."
I think existing programmers sometimes forget that there's more people who /will/ program than who /do/ program. They have existing biases: towards extra tokens, separation of concerns by separating technologies rather than components, and other newer concepts that they legitimately do find strange.
People making programming languages are much better suited by targeting non-programmers: existing devs are often simply not their audience.
I agree with that: these languages often don't have devtools, so they have to look at the compiled output to fix bugs. This makes for an unpleasant learning experinece.
Once these tools fix the DevTools situation they'll be a lot more useful.
Imba is still lacking when it comes to devtools, but it does have full support for source mapping, and the sublime text plugin includes inline error messages from the compiler.
I like to view transpiling as a specialization of compiling. Even if you try to make the distinction between high-level input -> low-level output, in the end it feels like the language matters much less than how the generated code is designed. Most "transpilers" end up using the bare minimum number of features for the target language and staying constrained to a pretty low-level part of that language. For example, languages that transpile to JavaScript tend to target asm.js, which really doesn't look anything like the JavaScript that real people write. Getting bogged down in naming differences when the overall process is pretty much identical is just ignoring the big picture in my mind.
I could not agree more! To me it seems that most of what is happening today is an exhausting chase by some developers to fill their CV / Resume with the latest buzz word technology, resulting in a shallow understanding of deep fundamental concepts and years of experience on a CV that means absolutely nothing.
As a college senior, this has been my problem—constant context switching to "keep updated". It really is a problem. My resolution for this year is to just focus and get good at at most two languages and their ecosystems.
I only learn something new if I have a reason to. I may learn PHP in the near future because my company is migrating to Magento from Rails.
I actively try to avoid learning when pursuing side projects. With side projects, the idea is to explore a domain rather than tools. My current side project, a productivity / accounting app, requires no new knowledge, and I want to keep it that way.
I am very skeptical that, after a certain level of proficiency, that significant time spent in other programming paradigms makes you better all around. I went through HtDP several years ago, and thought it was wonderful, but I don't program that way now. I do not TDD everything, or even most things, even though I know how to do it and why you would want to. You take the best parts of everything you come across, and throw away what you don't like.
The longer I code, the more I default to the tried-and-true. Everything else just seems counter-productive.
Because 98% is bullshit. Get very interested, have fun, learn, prototype, things look fine, then after start use seriously and depend on makes you so much pain and problem. Then have to fix, and patch and in the end: always remove. After you have this experience many times you will also very critical and have high expectation/requirement, then you will come to HN and reply negatively.
This, as well as the fact that recent years have brought on new language fatigue from having a completely new language with its own syntax and its own pros and cons being shown every 6 months. "Why bother" is important.
I like the syntax from the front end, but the details for back end seem a bit light on. I can't see much in the examples around persistence of data on the server side. Is this covered/planned?
React and Imba can both optimize using shouldComponenUpdate (in Imba you would add the same logic inside node#commit). Utilising shouldComponentUpdate (in React and Imba) requires additional logic by the developer, not the framework. This is not an optimisation at the framework level - but an endpoint where the developer can write their own custom optimisations. Adding your own manual checks all around your app to check for statechanges is inelegant, cumbersome, and bug prone. In my opinion it defeats much of the purpose of a virtual dom, if you are expected to do your own diffing before sending it through. Also, the relative performance difference is about the same when turning it on.
I fully stand behind the benchmark, and would even go as far as saying that it is more relevant for real world applications than benchmarks like dbmonster where everything in the view updates on every render. This effectively tries to calculate how quickly each contestant can reconcile the whole view (synchronously), but when only parts of the view has actually changed.
As this seems to be some kind of javascript derivate using node.js on the backend (?) I'm interested in how this deals with async operations, ie. can you create functions which take a long time to run without blocking other users?
This is especially important as they are targeting server side too.
Imba itself is "just" a language which compiles to JavaScript and can be used both at the client- and the server-side. At the server-side you use the same techniques as in Node.js (callbacks/promises for I/O-bound concurrency; process pools for computational concurrency).
Imba has syntax support for `await` (based on Promises) which helps quite a lot on concurrency-heavy code.
This whole website is written in Imba. It uses the same code for server and client. After the initial load, all navigation in the browser is happening with history push/popState, and rendered directly on the client, yet any hard refresh should land you at the same spot when rendered from the server, thanks to using the same logic for routing as well.
Imba is a new programming language for the web that compiles to performant JavaScript. It is heavily inspired by ruby and python, but developed explicitly for web programming (both server and client).
Well the rest of the language is indentation-based and lacks closing delimiters so it would be inconsistent for the embedded markup to have closing delimiters.
I built this simple module pattern framework that makes building apps pretty simple. the idea is that everything is a controller (module patter) so you break you app into controllers or modules. https://github.com/ThinkAcademy/MasterControl
check it out
its open sourced by http://thinkacademy.io/
yeah, but I feel they have a reason to exist. Clojure exists because it has interesting ideas about immutability, and is a lisp. Elm exists because FP. This exists because... Why? They thought we needed a new syntax for JSX? They thought we needed another language that was kind of like coffescript, but different in subtle ways? I don't know, and I can't see what this is bringing to the table.
Sorry, I didn't mean to bash on them for making. Let me clarify my opinion. What annoys me is that they made a thing, which is of debatable use, and talked it up as the next big thing, which everyone should use, because it's amazing. That bugs me.
I like the clean syntax, tags, and high performance, so I hope you guys attract interest despite all the library/framework fatigue we're experiencing in frontend JS land. It's rather refreshing to be able to write code and view all together, like <div.marker>.css(appropriate_styling)
It would be great if you had some walked-through example apps on webpages (like the old site used to have). That kind of thing helps people better understand the benefits of your approach.