Imba: A new programming language for web apps
imba.io
imba.io
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.
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...).
Surely the answer to that is obvious: because building webapps in js/html/css is a major pain in the arse.
People who specialize in webdev learn things by heart so perhaps they forget how bad they are.
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.
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?
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 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.
I avoid (to some extent) apps and websites that consume a lot of phone/laptop battery. Like Quora and many popular newspaper websites.
https://en.wikipedia.org/wiki/Domain-specific_language#Advan...
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.
Any tips from anyone?
- 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.
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?
Large systems are inherently problematic. The only way to "fix" them is to break them into smaller modules and subsystems.
Fancy abstractions and features will never solve large system issues. The large system issue is that it's large.
Any new language which purports to be an improvement upon Javascript should at least attempt to rectify these issues. That's my thesis.
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.
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.
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.
Abstractions absolutely can help solve the problem, by providing ways to modularize better.
Where are you getting this stuff?
Yes many classical oop languages have the class keyword and that's why javascript added it.
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.
But who knows, maybe it's just more noise.
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.
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.
Why?
People making programming languages are much better suited by targeting non-programmers: existing devs are often simply not their audience.
In this case I'd argue it would be better for non-programmers to learn JavaScript before a language which compiles to it.
Once these tools fix the DevTools situation they'll be a lot more useful.
Maybe it looks like I'm nitpicking... If it got across like that, sorry. Not my intention at all.
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
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.
But maybe I'm just bitter ;)
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.
Using proven techniques and tools makes experienced people more productive even if their raw mental abilities decline with age.
Learning and testing new technologies is expensive and most of the time leads nowhere.
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'm a Python guy so that's probably half the reason - but the syntax looks nice and clean to me.
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.
Here is some additional discussion about the benchmark: https://github.com/somebee/imba/issues/9
This is especially important as they are targeting server side too.
What is Imba?
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).
Imba has syntax support for `await` (based on Promises) which helps quite a lot on concurrency-heavy code.
ur/web might be hard to get into for someone who doesn't have ML or Haskell experience.
http://somebee.github.io/todomvc-render-benchmark/index.html
10 GOSUB CREATE_WEB_APP_THAT_I_WANT
20 DEPLOY TO_CLOUD
For god sakes, use js &co, clojure, or elm. Nothing else is worth it.