I was completely baffled by the myriad of options out there, how complex they look (note I've been working on very high performance, distributed backend applications, so complexity on itself is not an issue), and how it's very unclear when to use any one of them or what each one is good for. I tried Angular and React, and both feel like almost a different language. You have to learn their internals to work effectively with them, and it often looks like they create more complexity then the original complexity they were trying to reduce. I have no problem learning new things, in fact, I love it! It just feels like there are other things to learn that will stick around for longer - JS frameworks/libraries seem to be very hype-driven these days. What are your thoughts on this?
Not to blame or insult good frontend people here and everywhere, but it feels like en masse they don't understand the programming essence at all. Sorry, but UI development was never HARDER than today. My colleague feels the same, having more than 15 years of html/css/js experience.
My thoughts are we're throwing it out next week and generate all ui with decent server-side scripts, leaving /js/util.js of 1kloc as a broker and generic table sorter.
> I can't remember a time when I couldn't easily grasp any of Qt, Gtk, whateverTk toolkits in few hours
When I tried those things, I had a hard time making an hello world app in two hours because of dependency/build/tooling issues.
However I was able to grasp angular 2 in two hours probably because I am more familiar with the frontend ecosystem.
It would be like saying that because you knew english & german and was able to quickly learn swedish, you should be able to learn russian easily.
> Not to blame or insult good frontend people here and everywhere, but it feels like en masse they don't understand the programming essence at all. Sorry, but UI development was never HARDER than today. My colleague feels the same, having more than 15 years of html/css/js experience.
15 years ago the js applications were nowhere as complex as they are today. So obviously things are a bit more difficult IF you want a rich application. If you just want to make a simple document you don't need all those librairies.
> We picked Angular2 randomly after few probes and it seems that out project has more quirks, hacks and LoC than if we just coded it in pure js with heavy templating help from e.g. perl backend
This is your first project with a very unfamiliar tech. This was an expected outcome.
> My thoughts are we're throwing it out next week and generate all ui with decent server-side scripts, leaving /js/util.js of 1kloc as a broker and generic table sorter.
And that's a perfectly reasonable option, especially if you don't have someone with more experience in frontend tech to keep things sane.
Being a desktop and embedded developer myself, I share your sentiment. My personal explanation of the state of the art of web UI tech is, that there can only be wrong ways of doing it if the basic abstraction at the bottom of the stack is wrong. HTML was invented as a hyperlinked semantic document markup language with presentation largely left to the browser's interpretation. Presentation (CSS) and interaction (JS) aspects were only added (dare I say "glued") to it later, which seems like a design afterthought.
> Now that I'm forced to dive into it, I see that they just reinvent square wheels in a wrong ways that were polished a decades ago in regular desktop apps.
If you're talking about tcl/tk, decades ago it had a motif look to it (raised 3d borders, lots of grays). There was no theming engine. Font sizes were integer only (and that only recently changed). I'm not sure what the status of antialiasing was, but it probably wasn't good.
The event loop was (and is) slow. Unicode support was new.
Oh, and then there was the documentation. Seems like everyone who installed tcl/tk on a university machine made a public copy of the docs. So if there were bugs in a topic of the doc (and there were), and you searched for something related to that topic, you'd get back 100 links to copies of that same doc which all had the same error. What you wouldn't get were in-depth blog entries explaining that topic, complete with inline, cross-platform working demos which you can read, write, modify, and-- with a single shortcut-- inspect using one of at least 3 completely different implementations of the same standard from competing companies.
It's great to have so much innovation, but when each innovation is incompatible with the next it makes it very difficult to actually use the better things. You can't incrementally adopt them, you have to port an entire application.
This in turn makes it harder for new entrants to get adoption, even if they're better in some ways, because they need to reach a critical mass before many people are willing to put in the effort to, and accept the risk of, porting a whole app.
If we establish the base component layer and interop with the platform and other components - which Web Components does - then people can innovate on the internals of components, things like how and when DOM is updated. This is mostly what's being focused on anyway, the component models themselves are usually pretty comparable.
Not to mention that Shadow DOM is incredible and just fixes CSS.
If Firefox finishes up their Web Components implementation soon, we'll be at 3/4 major browsers with native Web Components support. I think more people will take them as a given for basing their UI libraries on.
Even within a community using the same framework or library, there is disagreement on how to solve certain problems. For example, the folks behind React Router removed parsing of querystrings, because people wanted the flexibilty of using alternative solutions [0].
It's hard to imagine something more trivial than parsing querystrings, yet no consensus exists among users of the same library (which itself is not officially-sanctioned by FB yet, and even React, while stronger than other libraries, is not loved and used by all client-side web devs) on how to do it best.
Yet people think someday in the near future, these differences will just disappear magically, and we will be able to author web components that snap--like Lego bricks--into whatever environment a developer wants?
[0] https://github.com/ReactTraining/react-router/issues/4410
I used to chalk this up to me not "getting it". Now I think it has more to do with the desire to incorporate newness into React apps. Stuff like ripping out routers to replace with another router but then the old router was rewritten so lets replace it with that one again. That kind of stuff happens, and even it is preferable to someone deciding to incorporate something like [shudder] styled-components half way through a project. This kind of stuff almost always incorporates new abstractions that will increase surface complexity. In the interest of avoiding a rant, I won't start with people monkeying with context or not understanding the effects of setState.
React should be judged by the quality of it's ecosystem and extant production code, and I would argue that if you survey these things often you will find plenty of unnecessary complexity.
Compared to Angular, it might as well be a micro-framework, but by objective measures it's not so simple.
Start with: https://nuxtjs.org/
And go from there, I wouldn't waste my time with Angular, and React is much more complicated than Vue.
Start with the Vuejs tutorial on their website. Vuejs docs are amazing and one the big reasons why people enjoy starting Vue.
Nuxt docs are so-so and can be quite confusing.
I tried moving to a newer version and start using with npm and webpack and I got a little lost.
Started using the php framework laravel it has a mix package build in that makes everything very simple.
My advice for backend developers is to use either the laravel framework or standalone npm laravel's mix package.
With a simple command preseyts for vue, react, bootstrap come out of the box to allow you to focus on writing code vs setting up webpack or gulp or grunt and managing that yourself
How do I do this ? Any templates to explore this pattern ? It is fairly straightforward to do this in rails, but in the world of react/vue, it seems that the whole community is geared towards rich client-side applications with low SEO.
If you want to learn a front end framework, pick one that's got a lot of community support (Angular, React, maybe Ember or Vue) and focus on it. Don't get distracted. Even when things change, it'll be good for a long while.
obviously this all means having to learn another language but i dont need to touch js ever again and i'll take that trade any day.
JS may seem hype driven because it is very active. I think you're right that it is hype driven as well simply due to human nature. We all fall for it on the rest of the internet. We fall for it when working with frameworks too. I mean, how many of us didn't really read the React license before building an app with it?
As a backend developer (and a new entrant to the JS world), the one thing I was looking for from a JS framework was that it should scale with my application. And somehow none of the frameworks do well on that metric, except VueJS.
Here's the post if you're interested -https://sgoel.org/posts/non-technical-reasons-why-i-like-vue...
I hear this sentiment a lot, but it always irks me. There seems to a general feeling amongst programmers new to front-end development that the current popular libraries have been over engineered and that the constant changes are driven by more by hype than actual need.
From my view, the complexity in these libraries is mostly a reflection of the complexity of the underlying platform. Browsers and their JS engines are now monstrously complex and implement a horrifying number of web standards. When compared with browsers, something like the C++ compiler or the JVM suddenly looks childishly simple (and I'm not saying those things are simple). For example, it may not be apparent at first why something like React is a good idea, because it takes some knowledge of the performance characteristics of browser rendering to understand that.
As for the churn, the libraries have been changing because the world has been changing. Back in the day, HTML was rendered server side and people used jQuery with little snippets of JS to modify small sections of the DOM. It only made sense to do that. But JS engines started to get really fast. Browsers finally started to use the DOM standards. People started working on solutions for all of JS's many warts, like not having any sort of module system and there being no good solution for package management. All these things came together in just a handful of years and suddenly it was possible to do actually cool stuff in browsers. Writing a browser based photoshop or itunes was no longer just the domain of tech giants like Google. When the world is literally turned upside down, that does shake things around a bit.
So, if you are coming to web development from the backend, I don't think there is an easy path. The platform is complex. And just the idea of writing single page applications is only about 7 years old. That the first handful of years were somewhat chaotic is not surprising.
But that aside, I would recommend to start with React and Redux.
Especially the toolset and addon ecosystem will suprise you, so easy and fast. You will love it.
It's not just frontend though; the entirety of all ecosystems springing around dynamic languages seem to suffer the same phenomenon.
Vue is the most similar to vanilla JS that I've used so far. It stays out of your way and works like you expect it to. I like that it only handles the render layer. It says to you "Give me a template and give me data. The data is up to you, I'll handle keeping the template up to date."
I'd love to use webcomponents but they're not going to totally replace these toolkits and right now the polyfill you need is atrociously slow.
The polyfills haven't been slow since Polymer 0.8/1.0 when we switched away from the "full" Shadow DOM polyfill and to the much lighter-weight ShadyDOM shim (which trades a little spec compliance that Polymer hides, for speed).
Polymer demos, like for HNPWA, are consistently among the fastest, even beating the speed-focused React clones.
import QtQuick 2.7
import QtQuick.Controls 1.1
Rectangle {
property real count: 0
Column {
Text {
text: count
color: "#09c"
font.pointSize: 24
}
Button {
text: "Click me!"
onClicked: count++
}
}
}
Have you tried it in a different browser, like Chrome or Midori?
signal clicked()
...
/* on some raw mouse event handler */
{
clicked();
}
Unlike JS objects, fields cannot be reassigned. Instead properties and signals are declared beforehand.
property real count
signal foo(arg1, arg2)
...I would not recommend it to anyone though. There is a world of difference between what they advertise on their website and the reality of using it as your framework.
Some key take-away for us so far:
Pros: - the idea and principles behind marko are brilliant. - it does render relatively fast
Cons: - it is bug ridden with inexplicable error messages. Not beta version bug ridden, not alpha version bug ridden but pre-alpha version bug ridden... - top level elements can't have a state, which made templates impossible to use (still need to make sure that's completely true, we haven't tried everything we could). - when doing back-end rendering, the browser still waits for the JS bundle before rendering. Almost completely defeating the purpose of an isomorphic app... - Marko does not come with a state manager. We had to build our own. - We haven't started using their router yet but having a quick look at it it seems to have an utterly bad API. They could have gone all the way and embed the path definition into the marko files but no, we get some awful JSON to work with...
My guess is that some very talented engineers at eBay rightly decided that the current state of UI frameworks is terrible and started remedying it. Then, deadline and other commitments made it hard for them to support the framework enough for it to be usable by third parties. It is still a great achievement and I find marko interesting but cannot possibly recommend it against React (haven't used enough of Vue.js to have a valuable opinion on it).
I appreciate your feeedback. To follow up on some of your concerns:
Top-level UI components can have state now:
class {
onCreate () {
this.state = {
count: 0
}
}
increment () {
this.state.count++;
}
}
<html>
<body>
<div onClick('increment')>Count: ${state.count}</div>
</body>
</html>
Marko does not have an "officially" supported router yet, but this is the one we've been pointing people to: https://github.com/charlieduong94/marko-path-router. If I understand your statement correctly, you mean that you would prefer to export the path directly from the component? I agree that this should be supported. Currently, Marko does not support exports, but it's actually on our issues board https://github.com/marko-js/marko/issues/538. We'd like to support the following:
export var route = '/about';
class {
...
}
<div>About!</div>
It's definitely true that we have a lot of features that we'd love to focus on and a very small team of engineers working on Marko/Lasso. I welcome you and anyone else to jump in and help if you'd like! Any contributions are extremely appreciated. Additionally, feel free to drop into the Marko Gitter chat with any concerns and we'll try to help https://gitter.im/marko-js/marko.
Could you elaborate?
I hope something will emerge from this quagmire.
- Explicit import is a much better idea than the Marko's folder structure based implicit import thing. Explicit import makes the code base more maintainable, reduces the side effects probability and "magic" stuff.
- "Counter" there is not a "word" as author says, but the component's file name. So it's not the word that you can misspell, but the file/module, that will not be imported in case of file name misspelling. Import by file name is not repeating, it's the explicit module importing by the file name, not by a some word - no DRY ideas violation here.
- Author says on 21:51 that "imports is kind of terrible" due to the relative path. There is no issue with the relative path - use Webpack's aliases. He says imports (explicit relative imports in that case) makes code more fragile...
- I like Vue's idea of separation computed/methods/data blocks more than mixing all together. It for example helps the green devs to better understand the framework's lifecycle/internals and separation of concern ideas.
I stopped watching the video after the 24 minute.
Webpack aliases are a Webpack-only feature that I would consider a bad practice since it relies on globally configured aliases. Implicit imports in Marko are resolved relative to the template file (not global). Marko can be used server-side under Node.js with no need for a JavaScript bundler.
> I like Vue's idea of separation computed/methods/data blocks more than mixing all together. It for example helps the green devs to better understand the framework's lifecycle/internals and separation of concern ideas.
I see separation of computed/methods/data as unnecessary boilerplate. Methods are just functions on the component definition. On a related note, In Marko there's no need for "computed" properties and there is no need for a "data" block.
You are contradicting yourself there. There is really no difference in clarity between an automatic path resolver and using aliases.
> I like Vue's idea of separation computed/methods/data blocks more than mixing all together
It's really a matter of taste.
Well, as soon as my browser renders that thing, the browser process reaches 122% cpu usage (according to htop). And i'm using a 4th gen core i7 processor. I can literally (literally in the literal sense of the word) hear my fan spin up. That hurts battery so much.
For reference, a 5000Kb (720p) twitch stream I had open was sitting at 3-4%.
For background to why I'm asking: I'm an IOS mobile dev and was a web dev before and I often use web dev structures and ideas as there is less structure, frameworks (unless you count RxSwift) and general philosophies I find in IOS mobile dev aside from best practices and tips like avoid Massive View controllers, etc.
class {
onCreate() {
this.state = {
count:0
};
}
increment() {
this.state.count++;
}
}
<div>The current count is ${state.count}</div>
<button on-click('increment')>Click me!</button>I've been using it for almost 10 years and some of the concepts they pioneered have only recently been discovered by the new kids.
I still use it, though some of the 'fixes' they had to put in place to support old browsers are often polluting the DOM unnecessarily in modern browsers (this is something I hope they fixed).
My favourite aspects of it are that I can declare components declaratively, it has a technique called autoChildren that allows managing a tree of components as a flat set (useful for complex components like tabsets), and the data binding layer. The documentation is top notch (which it needs to be given the depth of stuff in there).
Again, all of this was around in 2009 since when I started using it - and not sure how many years before I found it they'd been going.
Just kidding.
What's next, homotopic web frameworks and commutative app diagrams???