Hacker News Reader

Comment by alansammarone | Hacker News Reader

I've focused on backend for the last 7 years or so, so I've been kind of out of contact with the frontend world. Recently I started working on a personal project, and I thought it would be a good time to learn some of the modern tools people have been using for frontend dev.

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?

View on HN

As a desktop developer, I rarely ever touched backends. Though they are not "modern js", it was close enough to that madness to stay away from it. Otoh, I can't remember a time when I couldn't easily grasp any of Qt, Gtk, whateverTk toolkits in few hours. A month ago we started a project with a custom backend (on me) and had to choose a frontend option for our frontend-employee to use. It feels like hell, really. 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. I don't know where it all goes about the web. Before, when I heard about new cool js framework, I thought "well, guys do The Technology". 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.

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 hate to be that guy but you are confusing simplicity and familiarity.

> 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.

> When I tried those things, I had a hard time making an hello world app in two hours because of dependency/build/tooling issues.

I'd be interested to know how you tried.

For instance, for GTK:

https://developer.gnome.org/gtk3/stable/gtk-getting-started....

For Qt, the IDE itself comes with examples that can be built and run in two clicks.

Or maybe you want to use python ?

  virtualenv --no-site-packages .
  source bin/activate
  pip3 install pyqt5 
  echo "import sys
  from PyQt5.QtWidgets import QApplication, QPushButton

  if __name__ == '__main__':    
    app = QApplication(sys.argv)

    w = QPushButton('Hello world')
    w.show()
    
    sys.exit(app.exec_())" > main.py
  python3 main.py

I fail to see how this is more complicated than using npm or bower to fetch the relevant libraries.

It's great that Qt works with virtualenv and pip, Wx does too.

This is a quite recent phenomenon and to be applauded.

Minus sides -

Neither of these work with pypy yet (ideally the bindings would be rewritten using cffi for best benefit).

The downloads on these are quite big, but maybe this isn't the end of the world.

Gtk still doesn't work with pip like that yet.

Pyimgui may be worth a look if you want a small download that works everywhere, though it does look like it's own thing.

Our node_modules are 100Mb too, not counting a browser itself. Gtk recently quit building for MSW at all and relies on MSYS2, and it works now via 'gi', like any gir-enabled libraries, no custom wrappers needed. I ran complex Gtk3 Windows widget galleries last month, for Lua and Python at least.

Fair points, generally, but LoC and deadline arguments still kicking my ass. I'm counting days, not hours, that we are spending on magic issues instead of programming our direct business. No rant, I have an example right before me.

Our CEO, also programmer in distant past, took his macbook, asked me "where do I get Xcode", and in his free time did anything we did in web, including animations, itunes-like header/progress area, etc. With my "intensive kickstart", obviously, but the shocking fact is that he never touched Objective-C, Cocoa, AppKit and HTTP. Never. In. His. Life. (Though he has very strong background of sockets, threads, C, widget frameworks, coreutils, evaluation models and general software engineering). It took about a week or two in between of management and negotiations to simply write that thing by all canons.

I don't think we'll hire another frontend master on the middle of the road anyway, but that has something to do with complexity, not competence.

(Fun thing, he started with Swift but quickly "downgraded" to Objective-C, because Swift was getting in his way too much with no clear benefit.)

> 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.

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.

> whateverTk

> 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.

Oh, I almost forgot-- if you were making a cross-platform application for MacOS, Windows, and X11, you would spend a lot of time on at least one of those platforms trying to figure out some crazy workaround for a bad UI decision.

For example, for a file dialog under Windows and MacOS a call to the native libraries is made to get a native dialog widget. But in Linux of the late 1990s/early 2000s there was no such thing as a native dialog. So some tk developer coded their own file dialog.

Let's say you started in a deeply nested directory and you wanted to climb out. You see a button that goes one level up the directory tree. Great. You click that button and on Linux now the window shrinks because its width is set to be as wide as the directory being shown. So you couldn't do multiple clicks in a row to climb up the tree without moving the mouse to the left for each click.

You might be able to dig into the internals and muck around to get that dialog to have a better UI. But then you notice that the window menus in Linux-- unlike the ones on MacOS or Windows 95-- don't toggle the menu display on click. They only display on click. Not sure about Gnome 1, but Gnome 2 window menus definitely toggled on click. If you want that standard behavior now you've got to dig into yet another implementation-specific codebase for your tcl/tk installation. And since you're mucking around inside the implementation there is no guarantee that what you change will still work when you upgrade to a newer version.

If Firefox rolled their own weirdo file dialog on Linux and required an extension to get something that looked better, you can bet every new release would be met with complaints and sneers about just that. Yet whenever people bring up whateverTk it's some kind of antediluvian paradise.

Tcl/Tk never clicked for me, because it had no decent business table view (or I just didn't find it). When Borland died, Gtk and Qt were the only viable alternatives, though I can remember some shallow experiments with early Wx, Fox, FLTK and pure GDK/Cairo :)

I hear you brother. Sometimes I think with emscripten, web assembly, and WebGL, I should just write the thing in C++ using a UI toolkit that is older than my coffee...

This is why Web Components are so important.

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.

I did look into web components and google polymer, great idea, still somehow not gaining much traction as they should.

I work on Polymer, and I think we're well on the way to fixing that. Our uptake with large enterprises is quite good already, we're just not very popular with the HN crowd... yet.

Our annual summit starts Tuesday, and the talks are live-streamed, check them out for some updates: https://summit.polymer-project.org/schedule

Thanks. Looking forward to the live stream.

I tried to push polymer at my work (I use it for personal projects).

The problem I came into is I am a backend guy trying to convince that polymer and web components are the only sane way that I have ever seen to do web dev.

To many people were set it their own ways had just flat out did not want to learn something new. They could not put down react and redux for two seconds. Admittedly I am not a front end developer, but when I did get some to have conversations many of them went like this -- How do you do xyz in polymer / web components -- Umm seems to be a concept your framework had to create at a work around, that is not something you will need to worry about any more.

So what did we end up with? Some use react, some use ZK!?!, some just stick with straight up html/css/js -- oh and we have some angular too, but that fell apart because the guy doing it tried to do some weird shit with making some sort of tight integration with zk...

Side rant, if I have somebody send me that video about how react just had to be created to fix unread notification count at facebook one more time...

Webdev is a mess in my opinion and coming from the backend / systems side of things polymer / web components is the only thing that looks sane to me. Beyond what the component looks like I think a push in this direction will hopefully remove the requirement for a "web developer" vs just another developer who can work on any part of the project.

I've been using Polymer for several years on my side projects - Based on pure technical merit, I've always liked it the most of all other front end frameworks (though I have to say that in the early days performance and cross-browser compatibility were issues; but it's no longer the case though; now it's just great).

Most companies these days are using React or Angular 2 (that's what I've been forced to use as part of my contract work). VueJS is getting traction but I don't feel that Polymer is getting the recognition it deserves just yet (it's very hard to find Polymer contract work).

I really like that I don't need a separate compile step to build an app (almost no setup). The way the components compose together is also really nice. The CSS style encapsulation of Polymer 2.0 is another great feature - It might upset a few people due to lack of automatic backwards compatibility with external stylesheets but I do think it's the right long term decision.

If someone is starting an app from scratch today, I think that Polymer 2 is the best choice.

Interesting that https://polymer-project.org/ does not load, but https://www.polymer-project.org/ works fine.

Wow, this couldn't be better place and timing for me. I can actually make it. I can't find anything about price. Is it free to attend? Would love to come.

Yeah polymer summit is free, I was going to attend this year but some thing collide for me :/

I'm going!

Also, take a look at SkateJS, a Web Components library that takes a more JavaScript-centric approach than Polymer: https://github.com/skatejs/skatejs

By default it uses Preact to render components, but you can switch it out for any renderer.

The author of SkateJS is speaking at the Polymer summit too.

If you run into Trey at the conference tell him we're all waiting for it! With excitement :-)

The [Aurelia](https://aurelia.io) framework is also aligned with Web Components and other web standards.

Aurelia extends beyond Web Components, and comes with a lot of features built-in, such as routing, validation, and internationalization. This saves time from having to assemble/build your own framework.

Can I pick your brain for a minute? I'm vaguely aware of what the shadow DOM does, how on earth does it have anything to do with, let alone "fix," CSS?

It "fixes" it by (sort-of) hiding the styling from the parent CSS. Shadow DOM is kind of like OOP in that regard: it encapsulates a bunch of data (styles, other objects) and makes it seem like one object.. er, sorry, I mean component :)

Shadow roots - where components put their internal DOM - create CSS scopes with both upper and lower bounds. This gives both encapsulation and perf benefits.

1) You don't have to worry about selectors for your component internals accidentally matching somewhere else in the document. As a result you can write simple selectors, often just tagname or id selectors, and have much smaller stylesheets. It's just a lot easier to read and reason about.

2) Perf is better, partially because of smaller style sheets and simpler selectors, but also because there's much, much less tree invalidation when DOM changes because you only invalidate inside the scope of the change. There's also huge parsing benefits because browsers deduplicate <style> tags that have identical text, so if you put the same style in many shadow roots, it's only parsed once, and one stylesheet object among all the roots.

I often hear that "DOM caching, DOM invalidation" talk, but being non-web guy can't figure out what's the issue is. Seems like Santa didn't deliver cell renderer conception into DOM? :) Afaik, you basically draw table rows and cells via distinct widgets, no doubt it's expensive as hell.

Universal web components are a pipe dream.

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

If you look at the component models themselves, they're incredibly similar to Custom Elements. Most of the lifecycle hooks are the same, and things like setProps() in React are replaceable by reactive setters.

So yes, I do think it'll work.

querySelector() and querySelectorAll() are similar to jQuery, but they are not what unseated jQuery. It took a new library with compelling new features (unidirectional data flow, no need to use a special, crippled language just for templates) to get people to abandon jQuery.

React is the dominant client-side web framework, but its preferred template syntax has a method for inserting components into the document which is totally different from the "standard" (and Ember) way of doing things. JSX uses CapitalizedComponentNames, while the standard uses dasherized-component-names. JSX has self-closing tags with slashes before the closing angle bracket, while the standard does not.

There are perhaps tens of thousands of devs using React, Preact, and Inferno. How can these differences be smoothed over in order to enable universal web components?

100% agree. Plus web components are underpowered, imperative turds.

Reusable = Reusable within ONE family of applications using a similar stack. That's already pretty nice.

UX guidelines keep evolving too and it will remain a business advantage to be able to provide a better experience (and quickly so) than your competitors. Who seriously like the crappy <select> or <input type="date"> desktop web browsers provide?

I do when they work. I really hate when someone reimplements select without supporting things like typing to skip select an option. And honestly, on mobile, the built ins are the best.

There are react components that provide a good experience that replicates the features of most built ins, but it's a constantly moving target considering native widgets vary between platforms.

In general I agree with you and gp though. I would love for web components to one day be the standard but I'll believe it when I see it.

Web Components would make me finally be happy again when doing web development, but sadly I don't get to code only for latest browser versions and polyfills many times hinder more than help.

I keep reiterating this point, but people keep calling React complex, it's not. React is raw simplicity. As far as I'm aware it's the most minimal API for creating sufficiently complex UIs. It's so minimal that it's hard to build full apps in because it says "not my problem" to questions such as routing, global state management, you name it. And that's fair. I still maintain that it's a tool for pros. But the responsibility that it does take on, I believe it does so in the most simple way possible. And you don't need to be aware of React internals to use it effectively. The details of the component lifecycle are not internals, but part of the public API.

It's easy to say React is simple if you are looking at, say, a barebones create-react-app. But most production React apps I have worked on (I work at an consultancy) seem to accrete complexity faster than functionality.

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.

I have to agree w/ lopatin overall: React is a tool for professionals. And I think it addresses your arguments very well. Being open source and powerful, its reached for by people left and right who do not (yet) understand how to architect well constructed applications. And the results are predictable: Needless complexity, bloated apps, bad ui. Personally, I don't read any more into it than that.

If you're rebuilding aspects of your production system for the sake of "incorporating newness" then the problem is poor engineering not react or any other tool. If things are working fine as they are, you only have yourself to blame when you introduce new technology that you find too complex to manage.

Its the overall ecosystem that makes it complex. You can use it as is but everyone is using webpack and babel, so you have to use it too. But once you are into those tools (and all the others that they come with) then it becomes too complex.

> You can use it as is but everyone is using webpack and babel, so you have to use it too.

No you don't. You can absolutely use your own build system, or no build system, and still make use of open source components and libraries from the React ecosystem.

So which is it: "not complex" or "hard to build full apps"?

It's like LEGO's. The blocks are sturdy and the rules of how blocks fit together are simple. But building a mini Taj Mahal is still not easy. You do have to know basic physics & structural engineering, but if you do, the task is very do-able. Even fun.

Unlike if you were building a mini Taj Mahal out of match sticks, Elmer's glue, rope, and playing cards. Even a professional structural engineer would have a hard time with that. The rules of gluing a match stick and a playing card together are already complex (not to mention uncertainty about where to rope fits in), and it that makes it that much harder to make a final product.

This video goes into "simple" vs. "easy" https://www.infoq.com/presentations/Simple-Made-Easy

Consider facts: React is over 40k lines of code, there are 30+ classes/methods to be aware of though maybe 10 of them are commonly used. Would you call it "minimal"? There is still a lot more that could be done with a smaller API surface and much less code.

Compared to Angular, it might as well be a micro-framework, but by objective measures it's not so simple.

Just learn vue.js, and use the associated vue libraries, vue-router, vuex, etc.

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.

This is very subjective. I feel React is conceptually simpler (no custom templating language) and less opinionated (no official state management system like Vuex for example).

Your response is a bit disingenuous.

> no custom templating language

JSX may not be a templating language but you still need to consider it when comparing with other framework's languages

> less opinionated

The community is though, if you don't do things with redux, react-router, etc then you're considered odd. Any job you pick up with react is sure to use those.

> The community is though, if you don't do things with redux, react-router, etc then you're considered odd

A bit disingenuous there. In general people find Redux quite complicated and it everyone acknowledges it requires quite a bit of boilerplate when used in the default way. Quite a few like MobX, or using their own state management.

I've found the community to be very open to alternatives and helpful.

I've used neither of those libraries in any of the production React apps I've made.

Me neither, thank god.

You've mentioned one of the exact reasons why I found Vue.js so much simpler. It's highly opinionated, which for 95% of the time, in my experience, is exactly what I want.

I found myself much much more open to JS library fatigue with React; the ecosystem is so vast that it's hard to figure out which particular store I need, or which routing library I want or what form library I need and so on. I've seen a number of people complain about this, especially new comers.

I find the opinionated nature of Vue.js so refreshing, especially for newcomers, which the OP is, hence why Vue.js is a much better option to begin with. And continue with, but that's a decision I guess the OP can make further down the road.

You don't need a route library. You don't need a form library.

What do you need a routing library for? Have a single controller component (usually the most outer shell app component) and sprinkle in further functionality (e.g. history pushState) as necessary. Don't build it out until you actually need it.

I've never needed a "form library" because forms are almost always interactive in some specific way. Using a form library is almost always guaranteed to just get in the way.

You don't need to have a global state management library either if you have a good grasp of your apps data structures and how they need to be passed into components.

I find with React I get the opposite of javascript fatigue: it's so easy to build anything you need once you understand react that you won't need to search for all those libraries and code snippets.

I guess we have completely different approaches to software development.

I really hate reinventing the wheel, especially when good quality production tested solutions are out there. React libraries, quality wise, I've found hit or miss.

I find Vuex a very nice global store and the tooling (chrome plugin etc..) is top-notch.

You won't be reinventing the wheel for things like global state management and javascript routers. I promise. These libraries are huge solutions to problems that may or may not be huge - and in most of the cases I've seen, YAGNI.

The concept of maintaining application state is nothing specific to SPA's. What is new is the idea that every application must have a global data store where all state is saved. This is a trend and not always necessarily a best practice.

This isn't a matter of reinventing the wheel, it's a matter of using an oversized solution for an undersized problem.

Did I miss something or there's no explanation of what nuxtjs is on their website?

https://nuxtjs.org/guide

Don't start with nuxt.

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.

Agree with this.

I tend not to use "quick starts" especially when using something new since you a) don't learn the internal gubbins b) are more fucked when something breaks.

When I started with WebPack and TypeScript I deliberately started from an empty webpack.config.js and an empty tsconfig.js and added in stuff as I went at the end I had a decent understanding of what everything in both files actually did and they only did what I wanted.

I've never found a quick start that helped me (in terms of total time) since the time spent fixing it when it breaks always exceeds the time taken from just doing it manually the first time, after I understand what I'm doing then I'll consider the quick starts.

Poi is a good webpack wrapper for vue. Is a webpack with zero config

I guess I should have been more specific here, my bad.

Reading the Vue.js docs online is of course the first port of call; the documentation is very good, so much better than Reacts. One of the few occasions I've been able to learn a good majority of the project without resorting to googling for tutorials and other community contributed resources.

I recommended Nuxt as a good "this is how you put a enterprise ready Vue.js project together" so the OP would learn some good habits in project layout early on.

I tried to like VueJs but just couldn't. Seems just like another Angular 1.x like framework. I am done with HTML template API's. So many failed attempts using this concept. Anyone remember Polymer? That's what I thought.

Nuxt is the Vue version of Next, which I highly recommend for quickly bootstrapping a production-ready React app with server-side rendering and so on.

For me I picked up React pretty quickly but I was using old school includes in the browser with the babel compiler.

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

There is nwb and create-react-app that takes care of initial configuration now. Unless you're gonna write everything from scratch you're gonna need to learn npm though.

hi, im helping build a fairly vanilla ecommerce site in either reactjs/vue. I want it to be entirely server-side rendered with high SEO visibility. However.. (and this is the big point), have the same APIs exposed for mobile apps as well.

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.

There are many examles, like next.js. Or search for isomorphic or universal js.

Yeah, there is a lot of (developer driven) hype around new tools. I see it as both negative (hard to keep up, confuses those new to JS) and positive (lots of innovation and people trying many ways to solve things).

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.

i feel like i would've had similar feelings had i not learned (and pretty much fell in love with) clojure some years ago. now whether it's backend or frontend or even seamless code sharing between both - i am totally covered. react wrappers in clojure get unreal synergies with language design choices (immutable by default, convenient nested data structure manipulation, etc), things like this one - http://maksm.net/crypto-calculator/ is 100 lines of code including html templates.

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.

Where can I find the source code for the above?

didn't have it published anywhere yet but there you go: https://github.com/keymone/cryptick/blob/master/src/cryptick...

it's a hacky little thing i threw together in couple hours so don't expect any best practices or idiomatic clojure[script]

The only thing that really sticks are the fundamentals like algorithms and design patterns. The tools always change. If you want to be a stronger developer down the road focus on the fundamentals.

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?

I actually blogged about exactly this topic last year.

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...

React can do it, and any other virtual-dom framework. Your problem is that you're looking for a framework, but these are just libraries.

Actually I'm just looking to get things done. I'm pretty sure React can do all those things and much more. But speaking as a backend dev, getting to a state where I can write useful code was faster with Vue than with React.

I feel the same way about backend development. I stick to express.js because I know it, but I'm aware of at least a dozen other Node frameworks, and hundreds for other languages. Frontend is far from unique in growing in complexity as the web has changed.

> 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?

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.

If you are looking for a matured and easy to use solution, which follows convention over configuration pattern, so it helps to be the job done, I would highly recommend Ember.js Especially useful for us who come from backend world, so many concept will be familiar. You can learn the whole framework in a few days from www.yoember.com or from www.emberjs.com

Especially the toolset and addon ecosystem will suprise you, so easy and fast. You will love it.

http://ember.js.com http://yoember.com

Web components do not have a great story about passing complex data. If you want to pass typed data (not just strings) then declarative HTML suffers since HTML parses all attribute values as strings. You can use JavaScript properties to provide typed data to Web component custom elements, but properties cannot be provided declaratively in HTML and now you have two ways of providing data. With that said, I think there is value in building UI components in Marko and offering web component custom elements as one option for embedding your Marko-based UI component into a page (using a small UI bridge layer... something that we plan on open sourcing). --Marko author

Take a look at IntercoolerJS. It's just a simple library, not a framework. I found it as the easiest way to deal with modern frontend programming.

http://intercoolerjs.org/

I've been doing frontend for several years and largely agree with what you're saying.

It's not just frontend though; the entirety of all ecosystems springing around dynamic languages seem to suffer the same phenomenon.

They are super hype driven, now let me hype you for my personal fav.

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.

> 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.

> Polymer demos, like for HNPWA

HNPWA?

https://github.com/nuxt/hackernews

https://hnpwa.com/ - check out how fast polymer version is.

Try RE:DOM: https://redom.js.org ;)

Reply on news.ycombinator.com