Live data from Hacker News

How it feels to learn JavaScript in 2017

medium.com

131–140 of 167 posts

Re: How it feels to learn JavaScript in 2017

#131
post #117

Earlier quoted context omitted.

I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. That's simply not true for JS.

> I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. Most domains heavily constrain your language choice though...C/C++ for games, Java/Kotlin for native Android, Swift for native iOS, PHP/Node/Python/Java/Ruby for server-side. The libraries you need constrain the choice even more. I'd…

Most domains constrain your language choice into something that fits that domain.

It is just mobile and web that constrain your choice into some arbitrary stuff that may or may not work well, and it's your problem to deal with the consequences.

Re: How it feels to learn JavaScript in 2017

#132
post #66

Earlier quoted context omitted.

Does that work in several versions of different rendering engines that date back a decade, at resolutions from 800x600 to an iMac 5K screen? How about on tablet and mobile devices? What happens when the user's scroll position is half way down the page? Does it listen for events to update or close itself? A good modal library is going to weigh in at a few thousand lines of code across JS, CSS and HTML for a reason. If…

A good modal library is going to weigh in at a few thousand lines of code across JS, CSS and HTML for a reason. No. Sorry, but that's just nonsense. A modal is probably going to be rendered as an HTML div element, styled so it appears with a fixed centre-viewport position. You probably also want a second div as an overlay to de-emphasize the rest of the page while the modal dialog div is visible. You might want a sta…

You need more functionality for a non basic modal, first problem is if you have 20 modals you want not to copy paste over and over again. For non basic modals you also need events to know if user accepted or dismissed the modal, you want the Escape key to also work, you want the option to allow or not closing the modal when clicking outside of it, The project I work on uses bootstrap, this means in the main html file you have copy pasted same html boiler-plate with only the content change, somewhere there is a button that has a special attribute that magically opens this modal(bootstrap js does that in the background), this does not scale and we searched for a good library so we can put each modal in it's own file and we also needed full control to create the modal if and when we needed it and not have it loaded in the main html but hidden. The solution would be to have modals implemented as standard and not having to hunt for a library because the lib we used is for angular+bootstrap but it will not work for react+bootstrap or for no framework projects.

Re: How it feels to learn JavaScript in 2017

#133
post #47

Having used only re-frame and Clojurescript for two years now every time I look at where the Javascript guys are I roll my head. Is 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.

That OOP is only skin deep. Look at the way data flows, which pieces of code need to understand any given data structure. Look at the preferred way of extending classes - composition. I think what we have now is not old-school anything, but cherry-picked good parts together forming a New Thing.

Re: How it feels to learn JavaScript in 2017

#134

Earlier quoted context omitted.

How could the 27 file commit example comment not be a clear case of overengineering though? I frequently add similar functionality to Vue and Angular 1 projects in a way close to how you describe and it's simple. Even if the change involved adding a modal library (you should not be wasting time implementing that yourself) to your project first, it shouldn't be more than about 10 lines. Personally, I'd find it very ha…

Yep, I feel the same way, but then again I usually work with small startups. I had an experience with a bigger team, recently (about 20 devs) and went all the way "what you do is too complicated". I was quickly humbled when I realized that my "simple" designs were quickly growing out of control and breaking a lot after a few months so many devs were adding code in it, most of them knowing only a very small part of th…

> So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :)

Hmm, if each component is properly isolated though and you're not all working on the same area I still don't see why a simple modal could take so many code changes. Can you give an example?

I've worked on Java codebases before where there's hundreds of abstract interfaces, factories, design patterns galore etc. where you can't work out where the actual work is done because every file is just delegating to another file which I hate with a passion. JavaScript gets a lot of stick around here but I find it fun and productive to work with to be honest, as long as the same silly level of abstraction is avoided.

Re: How it feels to learn JavaScript in 2017

#135
post #126

Earlier quoted context omitted.

> I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. Most domains heavily constrain your language choice though...C/C++ for games, Java/Kotlin for native Android, Swift for native iOS, PHP/Node/Python/Java/Ruby for server-side. The libraries you need constrain the choice even more. I'd…

I love JS and especially the variety of tools available. It's a double edged sword. But once you have your tools is great. I love webpack, vscode, Typescript, npm, preact and mocha. All great tools to solve a specific problem. So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs.

> So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs.

Personally I'm surprised the null/undefined checking feature of TypeScript isn't raved about more which is missing from many typed languages.

Re: How it feels to learn JavaScript in 2017

#136

Earlier quoted context omitted.

Okay, but that's an upgrade issue, not a dead-end issue like a lot of people would assume from being told that there's no plans to add it to Internet Explorer. Features get added to new versions, not old versions. Organisations using old versions will need to upgrade to new versions to get the new features. That's true of anything. It just happens in this case that Microsoft decided to go from Internet Explorer 11 to…

It's not just an upgrade issue. Many organisations aren't running Windows 10 and so have no browser upgrade path to Edge at all. Many organisations still have an older version of IE, probably IE11 but sometimes earlier, as their standard desktop browser. Experience tells us that those organisations aren't in a hurry to upgrade their standard desktop deployment just to get a new browser so web developers can play with…

> It's not just an upgrade issue. Many organisations aren't running Windows 10 and so have no browser upgrade path to Edge at all. Many organisations still have an older version of IE, probably IE11 but sometimes earlier, as their standard desktop browser.

That's an upgrade issue. They are using older software and a feature you'd like to use is being added to a newer version of that software. Yes, upgrades aren't always convenient or timely, but it's still just an upgrade issue, not a technology you have to give up on because two major browser vendors aren't interested in developing it.

> So it's all very well talking about newer JS features, but pragmatically, you can't just wish away the need for compatibility with browsers more than a year or two old if your target audience is businesses, governments, or other large organisations.

I'm not wishing away the need to support older versions. I'm just saying that this is something we'll be able to use eventually, not something we'll never be able to use because two major browser vendors refuse to implement it. It's an upgrade issue.

Re: How it feels to learn JavaScript in 2017

#137
post #116

Earlier quoted context omitted.

Aka "javascript is not a real language", I thought we were done with that since almost a decade :) Maybe you should consider that just because a language doesn't work like what you're used to, it doesn't mean it's a bad language. Because saying nowadays that javascript is not worth learning sounds pretty absurd. Sure, you can live without it. But that's probably the most useful language to know as a "second language"…

Abstracting from js, rates and popularity of the only available solution are not an argument. It is like asking 'but who else?' in a dictatorship country. Pretty absurd, right. You folks are so blind that don't even understand how this straightforward non-blocking code works in decent languages: sql = client.read() res = remote_db.query(sql) client.write(res), still writing tons of boilerplates and spaghetti instead.…

[deleted]

Re: How it feels to learn JavaScript in 2017

#138

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

>Why? Probably because it's one line in Vanilla.js: confirm("Message")

The vanilla solution doesn't offer as many features:

* With the vanilla solution, the user can check a box that says 'Prevent this page from creating additional dialogs' (which can break the site). With a non-vanilla solution, the user cannot check that box

* The vanilla solution can't be themed in tune with the rest of the site or webapp

* The only options you have are 'OK' and 'Cancel' - you may wish to have other buttons/labels for your modal. Never mind if you want three buttons, or a list or the like

Re: How it feels to learn JavaScript in 2017

#139

Earlier quoted context omitted.

A good modal library is going to weigh in at a few thousand lines of code across JS, CSS and HTML for a reason. No. Sorry, but that's just nonsense. A modal is probably going to be rendered as an HTML div element, styled so it appears with a fixed centre-viewport position. You probably also want a second div as an overlay to de-emphasize the rest of the page while the modal dialog div is visible. You might want a sta…

You need more functionality for a non basic modal, first problem is if you have 20 modals you want not to copy paste over and over again. For non basic modals you also need events to know if user accepted or dismissed the modal, you want the Escape key to also work, you want the option to allow or not closing the modal when clicking outside of it, The project I work on uses bootstrap, this means in the main html file…

first problem is if you have 20 modals you want not to copy paste over and over again.

Of course, but you can trivially generate the required divs in JS, and you can easily track the number of current modals displayed and set the z-index to ensure proper stacking if necessary.

Other than that, what you put in the modal in terms of HTML content or rendering a template presumably works the same way as any other part of your UI. There's nothing magic about the fact that this particular div happens to be styled as a modal dialog.

For non basic modals you also need events to know if user accepted or dismissed the modal, you want the Escape key to also work, you want the option to allow or not closing the modal when clicking outside of it

OK, so you need two callback functions, a couple of buttons to proceed or cancel, and possibly a couple of event handlers for keyboard and mouse/touch events.

Again, you surely have something to render buttons and handle their events for your UI more generally anyway. Other than that, the only thing special about the modal is that maybe you're connecting a couple of other events to the same handler logic as the explicit cancel button.

Really, none of this is difficult, nor does it need anything like thousands of lines of code just to handle modal dialogs. You could code everything we've been talking about here from scratch in a few minutes, and you could integrate it straightforwardly with any UI library I can think of if you're already using something else to render templates or handle input events. If you already have something available that will save you those few minutes, great, go right ahead and use it, but let's not pretend this is some tricky problem that requires a lot of thought and a lot of code written by experts. It's an elementary exercise in UI design, which I'd expect any junior dev to handle easily.

Re: How it feels to learn JavaScript in 2017

#140

Earlier quoted context omitted.

It's not just an upgrade issue. Many organisations aren't running Windows 10 and so have no browser upgrade path to Edge at all. Many organisations still have an older version of IE, probably IE11 but sometimes earlier, as their standard desktop browser. Experience tells us that those organisations aren't in a hurry to upgrade their standard desktop deployment just to get a new browser so web developers can play with…

> It's not just an upgrade issue. Many organisations aren't running Windows 10 and so have no browser upgrade path to Edge at all. Many organisations still have an older version of IE, probably IE11 but sometimes earlier, as their standard desktop browser. That's an upgrade issue. They are using older software and a feature you'd like to use is being added to a newer version of that software. Yes, upgrades aren't alw…

Well, OK, but by that argument almost anything is just an upgrade issue, so I'm not sure that really gets us anywhere.

In particular, it doesn't solve the practical problem that even with all the recent developments in the JS ecosystem, as things stand today a lot of front-end web developers don't have access to language features and programming techniques that are widely available in other environments.

Unfortunately, this is just an inherent problem in the way that web tools have been repurposed for more general software development: the developers don't control a significant part of the infrastructure, so they will always have to code to the least common denominator among their target market.

Post reply on HN