I'm unclear about what this is, other than a new flavor of syntax for JavaScript.
The tagline of "Create complex web apps..." also turns me off. If there is one perspective that needs to change in modern app development it is to stop making "complex apps." Simple is good. KISS, and all that. I'd respond far better to "Simplify your app."
In defence of the person you're replying to, can we not assume that web apps are inherently complex to the degree that complexity is table stakes? I feel like you're being reductive because the actual comment is that "complex web apps" should not be the aspiration. Telling someone that they shouldn't simplify something that is by definition hard is totally missing the point. Removing pain from a difficult process is legit; complex is not a status badge.
I think people tend to talk past each other on this issue. The real problem with deciding upfront that something must be complex, is that it switches off that part of your brain which searches for simple, but hard-to-find, solutions. It encourages "greedy development" where you dive in before scoping out the best architecture, because who cares about the difference between complex and slightly more complex?
Actively searching for simple solutions to hard problems encourages high quality design and architecture. Moreover there is no one way to do simple things; simplicity requires a wider toolset than complexity. If your marketing explains how your tool helps people to make a complex thing, it's either incorrect or it's a bad solution.
So, let's say you take the simple solution. Then, the application keeps getting more and more complex due to the functionality requirements. Gradually, you've poorly and inconsistently implemented versions of the complex patterns in the first place, and the end result suffers for it.
I've dreamed of creating a multi-phase approach to software where simple and complex can co-exist and methodically transition along the way, but I've yet to be able to crack the problem.
You might have misread the thing I was proposing. If your application "keeps getting more and more complex due to the functionality requirements" then by definition there's no off-the-shelf library or service that can help. If your complexities are known in advance, you can choose a pattern which builds good, simple, composable code.
Honestly even if you're complexities aren't known in advance, it's still easier to build composable solutions out of off-the-shelf parts.
While I have nothing but empathy for our very-much shared pain, I have to insist that adding multiple layers of abstraction between a template and what the user sees in the browser + a maze of client/server sync flows + hyperactive ecosystem churn + webpack/babel + 750k npm packages because there's no stdlib = not a good start to finding a simpler A->B.
It was more a critique of their marketing than their product.
It is an interesting perspective that adding routing and components makes it more than a new flavor. It still compiles to JS, and doesn't add new capabilities to the language, just simplifies how you get those functionalities to run.
Which again takes us back to my point... "Simplify your apps" sounds like a better marketing strategy than "Build complex apps."
I feel that if business logic and specs are complex, it is our job to call that out, and help find simpler solutions to the core business problems that our work is supposed to solve.
From a quick glance, it mentions using a "memoized DOM" instead of a virtual DOM, which I think I've seen another new framework use recently. My understanding is it caches out major DOM states at compile time instead of computing them all at runtime, making things faster.
The tagline though doesn't really have anything to do with this
My only issue about creating web apps is in the UI/UX side so I don't get why nobody is succesful in this front. This will be really revolutionary. With successful I mean a UI builder hiding the details (think Windows Forms or XCode) and with a good set of sample apps.
The main difficulty is that networked apps have a network to deal with and generating those bindings coupled with today's demands for interactivity etc. makes things tricky. RPC frameworks like gRPC tend to be quite rigid in this aspect too (requires setting up exact specifications), despite making things easier for the client. Also, the threat vectors are completely different. If all browser apps run on a iOS device (i.e. locked down tightly with secure elements, can be used as Point of Sale machines, very difficult to temper) with data piped over TLS then it might be another story. But we don't live in that world. Browser apps have to deal with the fact that they can be tempered with easily. That a lot of things requires securing on both the client side and the server side (just think about how many times you have had to write two validations for form input). Servers have to be designed not to be easily compronised. It forces data and state to be clearly specified and mapped out. You can't just hold everything in-memory when you have to pipe things down the wire.
Potentially soon we will be seeing more of such things. MSFT WebForms didn't work out for all sort of reasons, but with stuff like front end Flutter, WebAssembly, the whole server-control GUI over WebSockets thing with Phoenix LiveView, Plotly Dash, .NET server side Blazor we are seeing a resurgence of this idea. Building rich UI and having to manage state both ends is a pain in the butt and makes stuff like authentication/authorization tremendously difficult to implement properly and correctly. We have come a full circle.
What's almost ridiculous is all the manpower and engineering effort that was put in over the years just so we can have a better UI and UX. You can build a shiny GUI in React and use the same COBOL accounting software code running in a DOS simulator that once powered a TUI software and the end user would not know the difference and would be more than happy to hand over money.
Is there a way to do this with just plain ol' javascript? Or do I have to use the "language?"
Things like this scare me because it's like a more tightly coupled coffeescript that's gonna be hell to maintain in 10 years, will become awkward with new (JavaScript) language features, or will just omit those features until its untimely demise...
I experimented with Imba for a bit a few years ago. Ultimately there was way too little documentation at the time for me to get past some of my initial confusion.
Scrimba.com is extremely impressive, however. It’s written in Imba, and also has a couple of Imba courses [1]. Looks like a good place to start!
Yet another JS framework. This time around... Ruby-flavored Vue.
On one hand, people should absolutely go where their passion projects take them. Building languages and compilers is often a critical step on the path of deeper understanding.
However, there's no way to get past the fact that there are too many front-end frameworks that offer same-but-different syntaxes. Most of these have no chance of achieving a large enough ecosystem, but every framework demands reinvention of everything all over again.
It pains me to consider how much smart person energy is currently channeled into creating flavor of the day JS instead of building stuff with whatever tech they are already proficient with.
Case in point: I am MUCH more excited by the Scrimba screencasting platform than I am by the prospect of spending an open-ended amount of time learning another, not-obviously-better framework.
> It pains me to consider how much smart person energy is currently channeled into creating flavor of the day JS instead of building stuff with whatever tech they are already proficient with.
I always thought `diversity is good`, but maybe in certain instances it's not. Perhaps a certain saturation level is reached and diversity just adds noise to the system and causes enormous overlap and your "smart person energy" is mostly spent re-inventing the wheel
Are we allowed to make thinly veiled gestures towards the 2020 Democratic candidate lineup? I don't want to get hell-banned.
Honestly, after React, Vue, Angular, Ember, Stimulus, Meteor and Backbone, how does anyone truly have time to learn learn about Svelte, Marko, Knockout, Aurelia, Riot, Omi, Foundation, Catberry, Composer, Yo-Yo, Vomit, Mithril, Polymer, Sencha... I'm not making a single one of these up. I know that I'm forgetting at least a half-dozen.
Note: try Stimulus!
Seriously though, if you're following every development on more than two JS frameworks, you are procrastinating, lying to yourself and not achieving your full human potential.
The very situation you are describing explains why many of us have avoided working in the web ecosystem entirely for the last 20+ years or so, and don't miss it at all.
Many people thrive in these kind of frenetic, fast changing environments. Others (myself included) don't.
Punchline: my top-level comment was downvoted with an angry passion. My interpretation is that there is a silent mob of people here that are so threatened by the idea that the only thing they know might not be God's Ultimate Solution that anyone who suggests that things were a lot better a decade ago is to be punished.
All I know is that after I help my friend with her React stuff, I go back to Rails and thank my lucky stars.
At first glance Imba reminds me of Coffescript, in a good way. A language that replaces JS' unfortunate Java-like syntax and helps reveal its simple and elegant semantics.
JS semantics are neither simple nor elegant. There's a reason there are whole books dedicated to avoiding certain parts of the language, and it's not the syntax.
For example, the syntax of the == operator is trivial. Its semantics however is complex and inelegant (it looks like an equality operator, but it doesn't express an equality relationship).
I'm familiar with JS' warts, which can be avoided. At the same time JS has e.g. functions as first class objects, few and simple types, object and array literals, and a prototype based OO.
This makes its semantic more elegant and simple than some other mainstream languages, like e.g. C++, Java or C#, IMHO.
2015: https://news.ycombinator.com/item?id=10091454