How it feels to learn JavaScript in 2017
41–50 of 167 posts
Re: How it feels to learn JavaScript in 2017
#42 app.on("new_private_msg", updateMsgBadge);
app.on("new_chat_msg", updateMsgBadge);
function updateMsgBadge() {
this.badge.newMessages =
PRIVATE_MSG.reduce(msg => msg.unread)
+ CHAT_MSG.reduce(msg => msg.unread);
}
Parts of the app can be abstracted into micro-services. For example the signup can be it's own micro-service.
Or using the plugin pattern each widget can be independent/untangled.Re: How it feels to learn JavaScript in 2017
#43The process looks quite complicated where you have to figure out lots of "buts," "whys," and "gotchas," while keep telling yourself, "What the hell?" all the time.
Re: How it feels to learn JavaScript in 2017
#44It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.
But didn’t we say the same thing about JS almost every year in the past? Only for the status quo to be obsoleted in a few months? Is the breakneck change curve slowing down finally?
I still have no clue about frontend web frameworks yet.
Re: How it feels to learn JavaScript in 2017
#45It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.
I'd say they've made JS development bearable, but great is really stretching it. We still don't have a type system, static analysis, multi-threading, first-class IDE support, or any of a myriad of other features that are standard in any modern programming language in 2017. I'm hopeful that projects like Blazor[0] and other efforts being made toward bringing real languages to the web via native WASM will put JS to rest once and for all.
Re: How it feels to learn JavaScript in 2017
#46Want a library faster than mithril, no runtime download, & handlebars syntax? Try Sveltejs. Rollupjs also has "treeshaking", meaning your transpiled bundle only includes the functions that are referenced allowing you to organize your code into large modules or even use a monorepo.
But of course as JS spreads I am looking, reading and mostly just shaking my head. But man, Svelte makes sense. For the first time in about 15 years, a JS framework makes sense.
Re: How it feels to learn JavaScript in 2017
#47Is nobody even slightly wondering how OOP has infiltrated modern JS development?
Old school Java web development has fully seeped into Javascript with JSX replacing JSP, OOP everywhere.. It looks exactly like the bells and whistles of early 2000 web development.
Re: How it feels to learn JavaScript in 2017
#48Earlier quoted context omitted.
> This seems ludicrous to me. Why? UI is hard dude. UI on the web is especially hard because the technology has been growing progressively for over two decades.
UI is hard dude. It's been a solved (and re-solved) problem for decades.
- clients that range from tiny phone screens to full desktop screens
- incompatibility when it comes to what features clients support, and even how they support it
- a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers)
- serious limitations in payload file size for the entire UI codebase
- much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'.
- backend systems that are not optimized for these kinds of things
I am a relatively 'young' programmer, so maybe I'm utterly wrong about thinking that, considering the above, we're in kind of uncharted territory. By all means correct me!
All that said, I do get the feeling 'we' in the javascript world reinvent the wheel more than necessary. But perhaps that's because none of the historical solutions are 'complete' enough to get enough mindshare in the way that, say, Ruby On Rails was, or jQuery.
Also, personally I'm becoming more convinced that until all this stabilized, many of use (or at least I personally) might benefit from just not aiming that high when it comes to UI. If I'm honest with myself, an 'old-fashioned' backend that produces HTML with perhaps a few dynamically loaded components (as just HTML fragments, even) is perfectly fine and I truly doubt it would have a negative impact.
(hey carsongross, this is where you bring up intercooler.js!)
Re: How it feels to learn JavaScript in 2017
#49It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.
>It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript. I'd say they've made JS development bearable , but great is really stretching it. We still don't have a type system, static analysis, multi-threading, first-class IDE support, or any of a myriad of other features that are standard in any modern programming language in 2017…
Agree, but we have TypeScript, also static analysis is done for ES6 module dependency
> multi-threading
This is wrong. JS has service workers, and sharred array buffers.
Re: How it feels to learn JavaScript in 2017
#50Earlier quoted context omitted.
UI is hard dude. It's been a solved (and re-solved) problem for decades.
But has it been solved if you take into account the various constraints/issues: - clients that range from tiny phone screens to full desktop screens - incompatibility when it comes to what features clients support, and even how they support it - a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers) - serious limitations in payload file size for the entire UI codeb…
It does your checklist for 2 decades.