Javascript Frameworks Are Amazing and Nobody Is Happy(wekeroad.com)
wekeroad.com
Javascript Frameworks Are Amazing and Nobody Is Happy
http://wekeroad.com/2013/08/22/js-frameworks-are-amazing-and-no-one-is-happy
201 comments
Yes yes, everything that's happening now has happened before with other technologies. Except this time:
1. it's in a runtime that is in more machines than any other in history.
2. can be loaded instantaneously with no installation procedures.
3. and no plugins
4. On almost any platform, linux, mac, windows, ios, android, windows phone, blackberry, palm, chrome OS, even game consoles. Including the nintendo DS!
5. is broadly accessible to people with various kinds of disabilities
6. doesn't require a team of 20 engineers taking 4 years to build. (which other tech has achieved, and arguably much better, but not combined with the other things above)
7. Works on miniature computer machines small enough to fit in your pocket, and can download your app wirelessly. From the air. in your pocket. FROM FUCKING OUTER SPACE
(incidentally, did HN skip out on the whole ordered list notation of markdown?)
edit; To add a couple more points:
* SEARCH ENGINES can automatically index your shit.
* We have these things called hyperlinks which allow automatic, ubiquitous and pervasive interoperation everywhere.
I see a common pattern on HN where whenever the topic of javascript comes up, all you see is pages and pages of wretching about how AWFUL it is, and how you could do X in Y language Z years ago already. That's not the hacker spirit. A hacker looks at what's out there, and what's possible, shuts up, and builds something awesome with it. (and then wretches about how awful it was)
In fact, the WORSE the underlying technology used to build something awesome, the more proud the hacker is that they achieved it. Where's that spirit?
Sure it's not as nice to program in as your favourite language or environment, but it's come a long damn way. would you give it a minute?
1. it's in a runtime that is in more machines than any other in history.
2. can be loaded instantaneously with no installation procedures.
3. and no plugins
4. On almost any platform, linux, mac, windows, ios, android, windows phone, blackberry, palm, chrome OS, even game consoles. Including the nintendo DS!
5. is broadly accessible to people with various kinds of disabilities
6. doesn't require a team of 20 engineers taking 4 years to build. (which other tech has achieved, and arguably much better, but not combined with the other things above)
7. Works on miniature computer machines small enough to fit in your pocket, and can download your app wirelessly. From the air. in your pocket. FROM FUCKING OUTER SPACE
(incidentally, did HN skip out on the whole ordered list notation of markdown?)
edit; To add a couple more points:
* SEARCH ENGINES can automatically index your shit.
* We have these things called hyperlinks which allow automatic, ubiquitous and pervasive interoperation everywhere.
I see a common pattern on HN where whenever the topic of javascript comes up, all you see is pages and pages of wretching about how AWFUL it is, and how you could do X in Y language Z years ago already. That's not the hacker spirit. A hacker looks at what's out there, and what's possible, shuts up, and builds something awesome with it. (and then wretches about how awful it was)
In fact, the WORSE the underlying technology used to build something awesome, the more proud the hacker is that they achieved it. Where's that spirit?
Sure it's not as nice to program in as your favourite language or environment, but it's come a long damn way. would you give it a minute?
I fink u freeky and I like you a lot.
There's the stuff we wish we could have done 50 years ago but couldn't. There's the stuff we could have done 50 years ago but only one person could do it by making a $1m multi-user computer not so multi-user. Then there's the stuff we didn't even know about. They're all awesome.
Yes, Javascript has genital warts, but I don't have to care. I can write sorta-lisp, which means I can layer my own stuff on top, and it magically works. I mean, emscripten!
The things that I miss, like automatic image-based persistence, are coming back anyway, and they'll be fast, probably open source, and can be integrated in a hazy, drunken, weekend.
There's the stuff we wish we could have done 50 years ago but couldn't. There's the stuff we could have done 50 years ago but only one person could do it by making a $1m multi-user computer not so multi-user. Then there's the stuff we didn't even know about. They're all awesome.
Yes, Javascript has genital warts, but I don't have to care. I can write sorta-lisp, which means I can layer my own stuff on top, and it magically works. I mean, emscripten!
The things that I miss, like automatic image-based persistence, are coming back anyway, and they'll be fast, probably open source, and can be integrated in a hazy, drunken, weekend.
Absolutely not. These statements are boring because everyone knows there are javascript everywhere on the internet. But so what? We should pay more attention to GOOD languages rather than popular languages. It's not javascript a great language but the people made the products great people. They could do even better if javascript is not so popular.
What about javascript's popularity, exactly, is stopping you from making something great? Use whatever hipster language you want, I say. The only question is how are you going to get people to look at what you make if you can't put it on the internet?
This post is great. The argument that followed was an unfortunate case of miscommunication on both side, oops!
JavaScript has many similarities to BASIC!
At one point, yes, points 1-5 were definitely true. Thank you for reminding me! Don't forget about BASIC!
Here's just a few of really big differences:
1.) BASIC didn't have a DOM. 2.) BASIC didn't have network abilities. 3.) BASIC didn't have advanced language features. 4.) BASIC wasn't didn't load and execute from a simple network request.
BASIC was SUPER important to the command line PC-era, just as JavaScript is really important to the cloud-era.
Microsoft and BASIC... Google and JavaScript...
Because JavaScript is attached to the DOM, and the DOM, aka, web pages, are SO crazy successful at delivering, presenting, archiving and navigating media, it really adds a level of longevity to the language that BASIC could only have dreamed of.
JavaScript has many similarities to BASIC!
At one point, yes, points 1-5 were definitely true. Thank you for reminding me! Don't forget about BASIC!
Here's just a few of really big differences:
1.) BASIC didn't have a DOM. 2.) BASIC didn't have network abilities. 3.) BASIC didn't have advanced language features. 4.) BASIC wasn't didn't load and execute from a simple network request.
BASIC was SUPER important to the command line PC-era, just as JavaScript is really important to the cloud-era.
Microsoft and BASIC... Google and JavaScript...
Because JavaScript is attached to the DOM, and the DOM, aka, web pages, are SO crazy successful at delivering, presenting, archiving and navigating media, it really adds a level of longevity to the language that BASIC could only have dreamed of.
> 2.) BASIC didn't have network abilities.
Are you sure about that? My C64 w/300 baud modem was able to hit BBS's...
Are you sure about that? My C64 w/300 baud modem was able to hit BBS's...
The c64 did, but could you download a basic program from the bbs and run it in place without stopping the modem software? Could that BASIC program then proceed to, in place download more content to view, from same, or any other BBS? We're talking about BASIC here :)
Now, if you wanted to move forward a few years then the Amiga could do those things using some proprietary graphical modem software and a bespoke graphics/interaction language whose name totally escapes me at the moment. It wasn't BASIC.
But, you know, you needed an Amiga to use it, and almost nobody had one.
..( a google search later and )..
oh hey, here it is
http://en.wikipedia.org/wiki/Skypix
Now, if you wanted to move forward a few years then the Amiga could do those things using some proprietary graphical modem software and a bespoke graphics/interaction language whose name totally escapes me at the moment. It wasn't BASIC.
But, you know, you needed an Amiga to use it, and almost nobody had one.
..( a google search later and )..
oh hey, here it is
http://en.wikipedia.org/wiki/Skypix
> But, you know, you needed an Amiga to use it, and almost nobody had one.
At least in Europe, I can assure most people that could buy computers mostly had an Amiga or Atari ST at home during the 16bit days.
At least in Europe, I can assure most people that could buy computers mostly had an Amiga or Atari ST at home during the 16bit days.
Did you ever use skypix?
No, in my circle of friends no one had modems.
Our main interests were games and demoscene related (assembly programming and pro-tracker).
Our main interests were games and demoscene related (assembly programming and pro-tracker).
You're really jumping the shark with your arguments.
I'm only pointing out that the c64 had networking capabilities -- because he said it didn't.
You're being exceedingly defensive and argumentative in this thread.
I'm only pointing out that the c64 had networking capabilities -- because he said it didn't.
You're being exceedingly defensive and argumentative in this thread.
He said BASIC didn't have networking capabilities. And well, that's true. c64 is a computer. BASIC is a language. they are two vastly different things.
and no, YOU'RE being extra argumentative in this thread.
and no, YOU'RE being extra argumentative in this thread.
Surely 1-5 applied to Basic. Why not VB6?
no they didn't. (what alternate universe did you arrive from?) And /not VB6/ because microsoft lost that battle. And not java, because sun lost that battle. And not flash, because adobe lost that battle, and not unity, because they haven't, and won't win that battle, for the same reasons all the others lost.
Well, first of all you edited your list, so it's 1, 2, 3, 5, 6. Which of those don't apply to Basic, and why not?
1. it's in a runtime that is in more machines than any other in history.
No. Never has, never will be. It's just a plainly obvious fact, no explanation needed.
2. can be loaded instantaneously with no installation procedures.
No. see above.
3. and no plugins
No. see above.
5. is broadly accessible to people with various kinds of disabilities
No. What makes you even barely think this even slightly applies?
6. doesn't require a team of 20 engineers taking 4 years to build. (which other tech has achieved, and arguably much better, but not combined with the other things above)
I'll give you that one, but not without a windows machine, and a multi-thousand dollar piece of proprietary software.
I'll admit I am not sure whether you mean BASIC or VISUAL BASIC. But none of these points apply to either, 6 even less.
No. Never has, never will be. It's just a plainly obvious fact, no explanation needed.
2. can be loaded instantaneously with no installation procedures.
No. see above.
3. and no plugins
No. see above.
5. is broadly accessible to people with various kinds of disabilities
No. What makes you even barely think this even slightly applies?
6. doesn't require a team of 20 engineers taking 4 years to build. (which other tech has achieved, and arguably much better, but not combined with the other things above)
I'll give you that one, but not without a windows machine, and a multi-thousand dollar piece of proprietary software.
I'll admit I am not sure whether you mean BASIC or VISUAL BASIC. But none of these points apply to either, 6 even less.
Are you familiar with early Apple and Microsoft products? I mean Basic. 5 we can strike, the interface was text-only. 1 was true at the time Basic was released, and that's why "it's different this time" is not relevant there.
So it was text only. That makes it accessible how, exactly? Can you cite specific examples of supporting technology for this?
1. was true at the time Basic was released, but so what? it has none of the "features" that we're actually talking about, and is less powerful than even javascript version 1. By the time visual basic had our beloved features, 1. was no longer true.
1. was true at the time Basic was released, but so what? it has none of the "features" that we're actually talking about, and is less powerful than even javascript version 1. By the time visual basic had our beloved features, 1. was no longer true.
I said we can strike 5. That means I agree with you about 5.
Your argument is "it's different this time" because of reasons 1-7. I'm claiming 1,2,3,6 are not different when compared to Basic, at the time Basic was released.
Your argument is "it's different this time" because of reasons 1-7. I'm claiming 1,2,3,6 are not different when compared to Basic, at the time Basic was released.
My argument is incredulity that you'd make such assertions that are baldly false, and don't apply to the actual reality that we live in. "Visual Basic" and "Basic" are not the same technology, and you can't simply merge them to get more points.
1. was true of BASIC for a brief time in the 80's, but was never true of VB
2. Not applicable to Basic (you had to type basic programs in by hand from a book, not exactly instant), not true of VB
3. Not applicable to Basic. What does "plugin" even mean there? You still have to type it in by hand. Not true of VB
5 was true of neither as you've conceded.
6 was true of visual basic, but never true of basic- to the degree that we're talking about sophisticated GUI apps, not simplistic text based adventures or weather quizzes.
1. was true of BASIC for a brief time in the 80's, but was never true of VB
2. Not applicable to Basic (you had to type basic programs in by hand from a book, not exactly instant), not true of VB
3. Not applicable to Basic. What does "plugin" even mean there? You still have to type it in by hand. Not true of VB
5 was true of neither as you've conceded.
6 was true of visual basic, but never true of basic- to the degree that we're talking about sophisticated GUI apps, not simplistic text based adventures or weather quizzes.
Well, I said "Why not VB6?" because I don't know much about it. But I'm pretty sure about Basic. You presented a list of reasons why JS is superior, and many of those were true of Basic at the time it was popular.
2. You can load Basic programs instantaneously. They're interpreted, and the interpreter came with the operating system or even the computer's hardware. How is JS any more instantaneous? You didn't have to type in a whole Basic program every time you wanted to run one - I'm guessing this is the confusion here.
3. There were no plugins. That's all that claim 3 ever was. I don't know how typing in a program by hand is relevant at any rate. Surely every program has to be typed in by hand, unless you're doing visual programming.
6. I thought this was about Basic itself, which did not take a team of 20 engineers four years to develop. As for applications, at the time it was really simple to program in compared to something like C.
So it comes down to 4, 5, 7. These aren't true of Basic, but they don't necessarily make JS a winner:
4. Basic programs were portable to machines that had interpreters, and there were lots of them. But sure, it probably wasn't as portable as JS, as I don't know if you could run it on a mainframe. C is a very portable language though, and always has been, so why does this mean JS wins?
5. Improvements in accessibility compared to the 80's applies to all technology. How is the disability support in JS better than other languages?
7. Home computers were IN YOUR FUCKING HOUSE! at the time Basic was popular. But non-Basic programs ran on those computers too, just like non-JS programs run on your phone. Miniaturization benefits all languages.
2. You can load Basic programs instantaneously. They're interpreted, and the interpreter came with the operating system or even the computer's hardware. How is JS any more instantaneous? You didn't have to type in a whole Basic program every time you wanted to run one - I'm guessing this is the confusion here.
3. There were no plugins. That's all that claim 3 ever was. I don't know how typing in a program by hand is relevant at any rate. Surely every program has to be typed in by hand, unless you're doing visual programming.
6. I thought this was about Basic itself, which did not take a team of 20 engineers four years to develop. As for applications, at the time it was really simple to program in compared to something like C.
So it comes down to 4, 5, 7. These aren't true of Basic, but they don't necessarily make JS a winner:
4. Basic programs were portable to machines that had interpreters, and there were lots of them. But sure, it probably wasn't as portable as JS, as I don't know if you could run it on a mainframe. C is a very portable language though, and always has been, so why does this mean JS wins?
5. Improvements in accessibility compared to the 80's applies to all technology. How is the disability support in JS better than other languages?
7. Home computers were IN YOUR FUCKING HOUSE! at the time Basic was popular. But non-Basic programs ran on those computers too, just like non-JS programs run on your phone. Miniaturization benefits all languages.
This argument is absurd. I can't help but feel that I've been majorly trolled here, so I give up. Have fun writing your next big app in BASIC. I'd love to see how far you get. It sounds like you could go far, since you have one of those fancy new computers with a DISK drive on it.
3, dude, Beagle Bros.
And BASIC is just FORTRAN for people who couldn't program and didn't have a real computer or pubes.
And BASIC is just FORTRAN for people who couldn't program and didn't have a real computer or pubes.
You make a post like that and then accuse foobarbazqux of being a troll. Nice.
well then give me a link to your marvelous BASIC program that I can run without installing anything. (I use a macintosh computer)
Maybe you haven't been to Radio Shack in a long time, but the new hotness is the Apple IIe.
WELL? I'm waiting! what cool thing did you make in BASIC?
> A hacker looks at what's out there, and what's possible, shuts up, and builds something awesome with it.
Yeah, but a hacker also doesn't waste his precious life time with subpar and awful technologies (unless he's forced/paid to do so).
That's why in my free time I rather fire up emacs and hack away in Lisp instead of building JavaScript webapps.
Yeah, but a hacker also doesn't waste his precious life time with subpar and awful technologies (unless he's forced/paid to do so).
That's why in my free time I rather fire up emacs and hack away in Lisp instead of building JavaScript webapps.
a hacker wastes her precious life-time on whatever she damn well likes.
Yeap, the only way of dealing with a subpar language full-time is doing something in a cool language on side.
Using IE vs Chrome vs FireFox is similar to using plug-ins in a way, e.g. not all of them are using all the HTML5 features same way.
> Congrats Javascript--on almost being as good at data-binding and layout as VB6!
That's total garbage. The browser does awesome presentation and layout with the markup you give it and you can control what happens via declarative CSS. VB6 couldn't even make a dialog look nice when you changed the system to Large Fonts.
Silent failure? You must have forgotten `on error goto 0`.
That's total garbage. The browser does awesome presentation and layout with the markup you give it and you can control what happens via declarative CSS. VB6 couldn't even make a dialog look nice when you changed the system to Large Fonts.
Silent failure? You must have forgotten `on error goto 0`.
I wouldn't characterize web layout as "awesome." Look at the contortions required for basic tasks like equal height columns.
I wouldn't characterize web layout as "awesome."
I would. I've been doing web development for a long time, along with many other types of development, and although there are quirks (as there are with anything), you can do nearly anything via web layouts. The flexibility of the system, and things people have accomplished with it, is really amazing when you stand back and look at it as a whole.
I would. I've been doing web development for a long time, along with many other types of development, and although there are quirks (as there are with anything), you can do nearly anything via web layouts. The flexibility of the system, and things people have accomplished with it, is really amazing when you stand back and look at it as a whole.
I don't mean to offend, but it sounds to me like you've just internalized the limitations of web layout.
For example, look at email clients. The native mail apps on my Mac and iPad can show me all of my inbox in one big list. I can scroll through tens of thousands of messages naturally, easily jump to the bottom or top of the list, etc.
Web pages cannot support this. Yahoo mail attempts to present the messages in one big list, but the experience is pretty bad. The scroll bar looks fake and feels wrong, find doesn't work like you'd expect, the scroll thumb changes size and jumps around as you scroll, scrolling to the bottom is Sisyphean, etc. And Yahoo mail is one of the better webmail clients.
Gmail didn't even try. Instead it refuses to show more than 100 messages at a time, with buttons to paginate.
When I work on web pages, I don't get a feeling of freedom or flexibility. Instead I find myself forced to compromise on the user experience over and over again, just like Google and Yahoo did with their webmail clients.
For example, look at email clients. The native mail apps on my Mac and iPad can show me all of my inbox in one big list. I can scroll through tens of thousands of messages naturally, easily jump to the bottom or top of the list, etc.
Web pages cannot support this. Yahoo mail attempts to present the messages in one big list, but the experience is pretty bad. The scroll bar looks fake and feels wrong, find doesn't work like you'd expect, the scroll thumb changes size and jumps around as you scroll, scrolling to the bottom is Sisyphean, etc. And Yahoo mail is one of the better webmail clients.
Gmail didn't even try. Instead it refuses to show more than 100 messages at a time, with buttons to paginate.
When I work on web pages, I don't get a feeling of freedom or flexibility. Instead I find myself forced to compromise on the user experience over and over again, just like Google and Yahoo did with their webmail clients.
Your examples don't strike me as limitations of the tools for designing a UI in the web...the limitations you mention are just due to the nature of it being on the web.
Frankly, a list of tens of thousands of messages sounds completely worthless to me. The first email application I've ever really liked and use all the time is Gmail. I think Google helped to redefine what the email interface should be, so much so that other desktop apps sought to imitate many of their features.
I believe that some of the limitations on performance actually force developers to build better interfaces than what you'd get if a desktop application was built in its place. I have to focus on what is most important and determine the best way to deliver that functionality to you. I suppose that's why I find myself anymore using web applications far more than desktop apps. The only native desktop apps I use anymore are things that I have to have the performance for (IDE's, Photoshop, etc...)
Frankly, a list of tens of thousands of messages sounds completely worthless to me. The first email application I've ever really liked and use all the time is Gmail. I think Google helped to redefine what the email interface should be, so much so that other desktop apps sought to imitate many of their features.
I believe that some of the limitations on performance actually force developers to build better interfaces than what you'd get if a desktop application was built in its place. I have to focus on what is most important and determine the best way to deliver that functionality to you. I suppose that's why I find myself anymore using web applications far more than desktop apps. The only native desktop apps I use anymore are things that I have to have the performance for (IDE's, Photoshop, etc...)
Good examples.
In WPF you have a grid layout out of the box. It just works. It takes minutes to setup. In HTML you are forbidden from using table and divs require all sort of third-party crap that doesn't really work with scaling windows and such. Tried using Twitter BootStrap fluid. Had to tweak the thing for days. Still not happy.
Why is it important that it's "in the box". You can have a html page started with a link to foundation and be doing a progressive grid layout in less than a minute. If you don't like their grid implementation use one of a dozen others. I'm guessing you used pre 3.0 twitter bootstrap. The latest bootstrap (I don't know how good it is, I have mainly used Zurb Foundation) is supposed to be much better at supporting progressive grids.
Grid layouts should be built using some sort of <grid> - not a bunch of hacky nested <div>s. HTML is a mess.
When making Web UIs, I miss the ability to think of screen space in the simplest terms possible: as (a portion of) a Cartesian plane, with the Y axis rotated 180 degrees so that the Y coordinate increases downwards. None of those contrived CSS constructs seems to offer the same degree of simplicity.
Absolute positioning is exactly what you describe: http://css-tricks.com/absolute-positioning-inside-relative-p...
And I'm really glad that we don't have to use it, except for special cases!
You might like <canvas> or SVG then.
on error resume next
People get excited about things happening to Javascript because, if you want to run your code in a browser, there's no alternative. So it's not so much "Javascript", some crappy language, getting that feature; it's all-web-programming getting that feature.
Some people (myself included) prefer a more radical approach: Rather than fixing the inteface JavaScript presents ot the programmer, we replace JavaScript (or, actually, all three of HTML, CSS and JavaScript) with a different language that is actually designed not to be crap. For example: http://elm-lang.org/
Once you get Microsoft, Apple, Google, Mozilla and Linux to all agree to and implement your new language please let us know so we can have you go fix congress.
It is not really my language, I am just a user. And Elm is already implemented using a compiler that translates Elm source code to HTML, CSS and JavaScript.
What does Linux have to do with this?
Figured node.js would become node.elm too right?
Does Elm have a progressive enhancement story at all? http://elm-lang.org/ is blank, and at a glance it entombs all content in javascript string literals, making linking and repurposing and any kind of semantic work just about impossible. The attitude that my content has only one useful rendering and I am fully responsible for it, and the client should only be able to execute that precisely, is destroying the web.
This kind of stuff is better handled on the server side by analyzing the user agent string, do you not agree?
I can't speak for prodigal_erik, but I strongly disagree. User agent strings are, to put it mildly, a clusterfuck.
First off, they identify browsers, not features. If a user disables JS, you can't detect that.
Worse, you would need know every UA string out there. This is, of course, impossible when a new browser shows up. And even if it weren't, it's not an elegant way to handle the situation of different browsers having different features. You're either going to have to do a separate code path for every version of every browser you support, or you're going to have to create a dictionary on your server to tell you what features are supported for each UA string, and then essentially do progressive enhancement on the server side. At that point, you're going through an awful lot of effort to do the work on the server instead of the client, with no clear net gain.
But the problem of new browsers is worse still. When existing browser vendors release a new version, they don't want all of the new features they added to be ignored by sites that rely on the UA string. And when someone makes a new browser, they don't want it to have everything disabled on every site it renders. So they go to elaborate lengths to load down the string with as much crazy as possible to trick sites into misidentifying them as existing modern browsers.
First off, they identify browsers, not features. If a user disables JS, you can't detect that.
Worse, you would need know every UA string out there. This is, of course, impossible when a new browser shows up. And even if it weren't, it's not an elegant way to handle the situation of different browsers having different features. You're either going to have to do a separate code path for every version of every browser you support, or you're going to have to create a dictionary on your server to tell you what features are supported for each UA string, and then essentially do progressive enhancement on the server side. At that point, you're going through an awful lot of effort to do the work on the server instead of the client, with no clear net gain.
But the problem of new browsers is worse still. When existing browser vendors release a new version, they don't want all of the new features they added to be ignored by sites that rely on the UA string. And when someone makes a new browser, they don't want it to have everything disabled on every site it renders. So they go to elaborate lengths to load down the string with as much crazy as possible to trick sites into misidentifying them as existing modern browsers.
The big reason to do server-side browser detection is latency. Each feature you support takes code, and if you ship the code to the client-side, that code takes bytes and slows down the page load. If you do your browser detection on the server side, you can avoid shipping code to the client that won't work on it anyway.
It's usually a poor business trade-off to slow down the several hundred million Chrome, Firefox, and IE users for the sake of a few thousand users on a new browser. Numerous studies (first publicized by Google but replicated several times since) show a direct link between latency and conversions: the slower your webpage is, the fewer people buy from it.
It's usually a poor business trade-off to slow down the several hundred million Chrome, Firefox, and IE users for the sake of a few thousand users on a new browser. Numerous studies (first publicized by Google but replicated several times since) show a direct link between latency and conversions: the slower your webpage is, the fewer people buy from it.
The vast majority of the code you'll be "shipping to the client that won't work on it anyway" will be to old browsers. In almost all cases with modern browsers, the amount of code we're talking about is small enough that it will almost certainly not have a perceptible impact on latency. So you aren't slowing down those hundred million users. You're slowing down the rapidly shrinking minority users with ancient browsers.
If you're not doing server-side browser detection, how do you avoid shipping the code to support old browsers to new browsers?
Pre-IE9, most browser-specific hacks weren't of the form "Old browser X doesn't support new feature Y". They were of the form "IE does things differently." That required shipping a version for IE, and shipping a version for everyone else. If you gate these with feature detection on the client, you need to ship the IE code and the conditionals to gate it to the client.
Post-IE9, most browser-specific hacks are of the form "Emerging web standard X would be very handy but isn't supported in browser Y, so I'm going to emulate it with Javascript." That involves shipping JS to old browsers, not to new browsers.
Pre-IE9, most browser-specific hacks weren't of the form "Old browser X doesn't support new feature Y". They were of the form "IE does things differently." That required shipping a version for IE, and shipping a version for everyone else. If you gate these with feature detection on the client, you need to ship the IE code and the conditionals to gate it to the client.
Post-IE9, most browser-specific hacks are of the form "Emerging web standard X would be very handy but isn't supported in browser Y, so I'm going to emulate it with Javascript." That involves shipping JS to old browsers, not to new browsers.
You could use UA strings to serve the shims and workarounds, I suppose, but you could also use client-side feature detection to do the same thing more reliably. If certain features are missing, you load in the extra code. If not, you don't, and page load time is unaffected, except for the tiny amount of code required to do the feature detection. In either case, what you're doing is more graceful degradation than progressive enhancement.
But the idea of progressive enhancement is not just about supporting everybody's browser so that you will get more conversions in the short term. It's about the long term. Targeting the majority and saying "screw the fringe demographics" is what led to Microsoft having control over web technology years ago, and it's important to our livelihood to prevent that from happening again.
But the idea of progressive enhancement is not just about supporting everybody's browser so that you will get more conversions in the short term. It's about the long term. Targeting the majority and saying "screw the fringe demographics" is what led to Microsoft having control over web technology years ago, and it's important to our livelihood to prevent that from happening again.
Then we all get stuck supporting both until its universally adopted (you know how some people still use XP?)
It is a noble desire though.
It is a noble desire though.
But html, css and javascript serve different purposes. Why would you want to force them all into one syntax?
Markdown is an embedded language for content inside Elm, so it is strictly speaking not a single syntax. And Elm provides a better way to specify dynamically evolving content that eliminates the need for a separate language for specifying static styles.
ooooohhh where have you been all my programming life...
edit: explanation: I really dig it!
edit: explanation: I really dig it!
I am not sure how to interpret this comment. :-|
edit: Heh! Go thank Elm's author, not me. :-P
edit: Heh! Go thank Elm's author, not me. :-P
> if you want to run your code in a browser, there's no alternative.
^^^^ YES. Although:
1. there was Java in the browser until recently when the Government said not to use it. Eh, it was dead anyway (in the browser at least- very few new projects using it).
2. there are those things called Flash/Flex/Air/etc. that Jobs killed when Apple wouldn't support them- they still live too all over the place though.
3. HTML 5- it's not just for breakfast anymore.
4. Javascript isn't just there because it is the only thing- morons at Google, etc. helped make faster JS compilers/interpreters. How is another scripting language going to erupt if they keep making the bad one faster. It's like PhP all over. Bastards.
Now back to the post to comment on just one thing:
> Just take 10 minutes and read the documentation! 10 minutes!
I was with it and then I read that and thought, "That's bullshit. Total bullshit." So #1 magic JS MVC framework? AngularJS. AngularJS documentation? Yes it has it... but even though I understand it, when something goes wrong, it is not RTFM, it's TFM: Too Fucking Magic. Batarang doesn't help when things aren't wired correctly, and when it does, it is not written for the beginner. EmberJS? EmberJS has only a community of hardcore Rails devs and Sproutcore people that didn't care it got renamed twice (sproutcore->amber.js->EmberJS) and DHH won't embrace it, so it's is F.U.C.K'd- even one of its big time proponents admitted it would be years before it is ready:
http://hawkins.io/2013/05/ember-data-is-pre-alpha-software/
http://hawkins.io/2013/07/we-are-pioneers/
^^^^ YES. Although:
1. there was Java in the browser until recently when the Government said not to use it. Eh, it was dead anyway (in the browser at least- very few new projects using it).
2. there are those things called Flash/Flex/Air/etc. that Jobs killed when Apple wouldn't support them- they still live too all over the place though.
3. HTML 5- it's not just for breakfast anymore.
4. Javascript isn't just there because it is the only thing- morons at Google, etc. helped make faster JS compilers/interpreters. How is another scripting language going to erupt if they keep making the bad one faster. It's like PhP all over. Bastards.
Now back to the post to comment on just one thing:
> Just take 10 minutes and read the documentation! 10 minutes!
I was with it and then I read that and thought, "That's bullshit. Total bullshit." So #1 magic JS MVC framework? AngularJS. AngularJS documentation? Yes it has it... but even though I understand it, when something goes wrong, it is not RTFM, it's TFM: Too Fucking Magic. Batarang doesn't help when things aren't wired correctly, and when it does, it is not written for the beginner. EmberJS? EmberJS has only a community of hardcore Rails devs and Sproutcore people that didn't care it got renamed twice (sproutcore->amber.js->EmberJS) and DHH won't embrace it, so it's is F.U.C.K'd- even one of its big time proponents admitted it would be years before it is ready:
http://hawkins.io/2013/05/ember-data-is-pre-alpha-software/
http://hawkins.io/2013/07/we-are-pioneers/
Are you saying that VB6 as a platform is superior to the web in its current state, all things considered? The comparison is silly, there is no competition in terms of distribution, portability, flexibility. Can you not see how it is remarkable that web development tools can rival desktop GUI environments, given that by design, everything on the web is running in a very limited sandbox, one based largely on the work of slow-moving standards bodies?
Yeah, you're right, that is cool and that is remarkable. But Javascript still really sucks sometimes.
To use an analogy: I'm not saying the plane doesn't fly, but I am saying the plane seats are uncomfortable.
Also, this is a total aside: what if there actually was a way to stuff like C++ on a computer in sandboxed environment that could be loaded automatically by a user in a seamless way? If that happened, if you took away Javascripts monopoly of the highly portable and convenient environment, it'd be dropped so fast you could blink and miss it.
To use an analogy: I'm not saying the plane doesn't fly, but I am saying the plane seats are uncomfortable.
Also, this is a total aside: what if there actually was a way to stuff like C++ on a computer in sandboxed environment that could be loaded automatically by a user in a seamless way? If that happened, if you took away Javascripts monopoly of the highly portable and convenient environment, it'd be dropped so fast you could blink and miss it.
> Also, this is a total aside: what if there actually was a way to stuff like C++ on a computer in sandboxed environment that could be loaded automatically by a user in a seamless way? If that happened, if you took away Javascripts monopoly of the highly portable and convenient environment, it'd be dropped so fast you could blink and miss it.
This is what asm.js enables for non-garbage-collected languages, and what Binary Data enables for garbage-collected languages.
But I think you're overestimating how much people want to move away from JavaScript. The overwhelming majority of Web pages never leave the JavaScript interpreter in Firefox, because they just aren't bound on JS execution speed. What is far more important than raw JS speed on most Web pages is ease of development and DOM/CSS performance. I think it'd be hard for C++ to gain much mindshare on the long tail of Web sites, even in a world where asm.js was universal, easy to use, and 100% of native speed.
JS has plenty of faults, but one thing it's never lacked is convenience. Conversely, C++ has many virtues, but one thing it's never had is ease of use. Given that calculus, I expect JS to continue to dominate for a long time.
This is what asm.js enables for non-garbage-collected languages, and what Binary Data enables for garbage-collected languages.
But I think you're overestimating how much people want to move away from JavaScript. The overwhelming majority of Web pages never leave the JavaScript interpreter in Firefox, because they just aren't bound on JS execution speed. What is far more important than raw JS speed on most Web pages is ease of development and DOM/CSS performance. I think it'd be hard for C++ to gain much mindshare on the long tail of Web sites, even in a world where asm.js was universal, easy to use, and 100% of native speed.
JS has plenty of faults, but one thing it's never lacked is convenience. Conversely, C++ has many virtues, but one thing it's never had is ease of use. Given that calculus, I expect JS to continue to dominate for a long time.
> JS has plenty of faults, but one thing it's never lacked is convenience. Conversely, C++ has many virtues, but one thing it's never had is ease of use.
That is a weird thing to say. Maybe it is just me, but when I use JavaScript, I cannot stop worrying about the possibility that there is yet another corner case I have not contemplated. Admittely, C++ is full of corner cases too; but, in my experience, it can be coerced into being a more or less civilized language by making a list of strictly verboten constructs, including, but not limited to, void pointers, manual resource ownership management and casts other than static_cast. When you leave these out, you actually have a smaller language that is easier to reason about. With JavaScript, no list of bad constructs can do - you need to actively rely on the semantically crazy stuff to do anything useful.
That is a weird thing to say. Maybe it is just me, but when I use JavaScript, I cannot stop worrying about the possibility that there is yet another corner case I have not contemplated. Admittely, C++ is full of corner cases too; but, in my experience, it can be coerced into being a more or less civilized language by making a list of strictly verboten constructs, including, but not limited to, void pointers, manual resource ownership management and casts other than static_cast. When you leave these out, you actually have a smaller language that is easier to reason about. With JavaScript, no list of bad constructs can do - you need to actively rely on the semantically crazy stuff to do anything useful.
What semantically crazy stuff do you have to rely on? I don't advocate mindlessly buying into the cult of Crockford, but he outlines a pretty reasonable subset of the language in "JavaScript: The Good Parts"
The only thing I can think of that you might mean is function scoping, which I would agree with.
The only thing I can think of that you might mean is function scoping, which I would agree with.
PNaCl
Which is awesome to actually use, but it doesn't have the interoperability that Javascript does. Maybe one day it will, and that'll be awesome. But till then, we'll never know.
I wonder if it would be possible to shim PNaCl with emscripten as a fallback.
Even today, web apps do not rival the desktop apps of a decade or two ago. Yes, there has been some advancement, but web apps are still inferior in every respect.
The performance of web apps is much worse than that of desktop apps, for example. Complex desktop apps written in C, VB, and PowerBuilder ran just fine on 486 or early Pentium systems that have a very small fraction of the processing power and resources of a modern system. Yet it's still common to see web apps in general perform quite poorly on these modern systems, while doing less than the mid-1990s apps did.
Developers at least have some choices when it comes to desktop apps. They can use a multitude of different languages, along with a variety of different libraries and frameworks. This is a much richer ecosystem than what we get with web development today, where you're basically stuck with JavaScript, or a language that's nothing more than a slight veneer over JavaScript (CoffeeScript, TypeScript, and even Dart). Don't even bother mentioning asm.js or Emscripten. Asm.js is merely a rancid subset of JavaScript, and Emscripten is experimental at best.
The portability argument isn't even valid. Languages like C, C++ and Python offer superb portability today, especially if used with one of the extremely cross-platform GUI toolkits available for making desktop apps. Given that almost every major JavaScript implementation today is written in C and/or C++, the portability of JavaScript is inherently no better than than of C and C++.
The ability to communicate over a network isn't anything special, either. All sorts of desktop apps have been doing this for several decades now.
The distribution argument also isn't valid. The package management systems offered by most Linux distributions, for example, are far nicer to work with. They make it trivial to find and install native apps, and unlike web apps, you get to choose if and when you upgrade, rather than having changes forced upon you time and time again.
The sandbox argument is also irrelevant. Various mainframe and UNIX-like OSes have offered several different ways of jailing or otherwise isolating processes for many, many years now. It's nothing new. But unlike the browser, they give real control over how much access is allowed, and without imposing horrid performance loss.
All of these limitations of web apps come together to make for a user experience that isn't enjoyable.
At best, web apps can imitate desktop apps, usually at a quality and user experience level 10 to 15 years behind desktop apps. It's objectively incorrect to claim that web apps "rival" desktop apps, when all of the evidence shows that they clearly do not.
The performance of web apps is much worse than that of desktop apps, for example. Complex desktop apps written in C, VB, and PowerBuilder ran just fine on 486 or early Pentium systems that have a very small fraction of the processing power and resources of a modern system. Yet it's still common to see web apps in general perform quite poorly on these modern systems, while doing less than the mid-1990s apps did.
Developers at least have some choices when it comes to desktop apps. They can use a multitude of different languages, along with a variety of different libraries and frameworks. This is a much richer ecosystem than what we get with web development today, where you're basically stuck with JavaScript, or a language that's nothing more than a slight veneer over JavaScript (CoffeeScript, TypeScript, and even Dart). Don't even bother mentioning asm.js or Emscripten. Asm.js is merely a rancid subset of JavaScript, and Emscripten is experimental at best.
The portability argument isn't even valid. Languages like C, C++ and Python offer superb portability today, especially if used with one of the extremely cross-platform GUI toolkits available for making desktop apps. Given that almost every major JavaScript implementation today is written in C and/or C++, the portability of JavaScript is inherently no better than than of C and C++.
The ability to communicate over a network isn't anything special, either. All sorts of desktop apps have been doing this for several decades now.
The distribution argument also isn't valid. The package management systems offered by most Linux distributions, for example, are far nicer to work with. They make it trivial to find and install native apps, and unlike web apps, you get to choose if and when you upgrade, rather than having changes forced upon you time and time again.
The sandbox argument is also irrelevant. Various mainframe and UNIX-like OSes have offered several different ways of jailing or otherwise isolating processes for many, many years now. It's nothing new. But unlike the browser, they give real control over how much access is allowed, and without imposing horrid performance loss.
All of these limitations of web apps come together to make for a user experience that isn't enjoyable.
At best, web apps can imitate desktop apps, usually at a quality and user experience level 10 to 15 years behind desktop apps. It's objectively incorrect to claim that web apps "rival" desktop apps, when all of the evidence shows that they clearly do not.
Parent specifically stated that modern frontend development tools pale in comparison to VB6. You couldn't write a VB6 program and run it on Mac, Linux, a random smartphone, tablet, eReader, hell, even video game systems like the Sony PSP have had web browsers and been able to load web apps for a while now.
You throw out "the distribution argument also isn't valid" as though firing up a Linux package manager or going to download some binary program on Windows/Mac is at all comparable to simply clicking a URL in an email. Not to mention the security implications of desktop distribution.
No, the mediums are not comparable. Your rebuttals consist of "your argument isn't valid" but offer no counterpoints, rather, they simply describe the way desktop development is done these days. It's fine and dandy that you think desktop programming is the state of the art, but there are vast differences between web and desktop environments, and it's why things like the Chromebook can exist.
There are many people these days for whom the internet is the computer.
You throw out "the distribution argument also isn't valid" as though firing up a Linux package manager or going to download some binary program on Windows/Mac is at all comparable to simply clicking a URL in an email. Not to mention the security implications of desktop distribution.
No, the mediums are not comparable. Your rebuttals consist of "your argument isn't valid" but offer no counterpoints, rather, they simply describe the way desktop development is done these days. It's fine and dandy that you think desktop programming is the state of the art, but there are vast differences between web and desktop environments, and it's why things like the Chromebook can exist.
There are many people these days for whom the internet is the computer.
Lets say we've reached this plateau where we can run these moderately limited apps almost everywhere, in a browser. Great! We've been here for some time now though, since HTTP/HTML has always run anywhere a browser could be found... All you're saying is that we have browsers in more places now. That is pretty fantastic, no kidding. There's still nothing wrong with saying that the foundation it all runs on mostly sucks for building application front ends.
What's wrong with wanting better? How awesome would it be to have a safe, well engineered browser that wasn't limited to just HTTP, HTML, CSS and Javascript?
Give me a full duplex network stack, native graphics and broader input controls. Give me file access and a multi-language runtime! Sandbox it all, I don't care!! Microsoft has done all of this (exceedingly well, in a very short time) with Silverlight which can run dynamically downloaded C#, F#, VB and Python modules on Windows, OS X and (limitedly) on Linux. It could definitely be done better by a more open group.
What's wrong with wanting better? How awesome would it be to have a safe, well engineered browser that wasn't limited to just HTTP, HTML, CSS and Javascript?
Give me a full duplex network stack, native graphics and broader input controls. Give me file access and a multi-language runtime! Sandbox it all, I don't care!! Microsoft has done all of this (exceedingly well, in a very short time) with Silverlight which can run dynamically downloaded C#, F#, VB and Python modules on Windows, OS X and (limitedly) on Linux. It could definitely be done better by a more open group.
Now Silverlight was _actually_ innovative and modern. As opposed to 20-ish year old broken script and mark-up languages that have to be backwards-compatible.
If "web apps are still inferior in every respect," why do we find ourselves using web apps more and more and desktop apps less and less? Should I expect to download the next gen of great applications from a cool shareware site like in the good old days of a decade or two ago?
Web apps have won the desktop, at least for now. It's what people want, and it's what people are getting, mostly for the reasons cited above. Mobile, now that's a more interesting story.
> why do we find ourselves using web apps more and more and desktop apps less and less?
Do we?
> Web apps have won the desktop
Tell that to my text editor, photoshop or audio editor. Or my email client - or even the native Evernote application. For all of these there's no serious web version.
This comment might sound snarky but I'm honestly trying to think of what web apps I regularly use. And I can't come up with one.
Do we?
> Web apps have won the desktop
Tell that to my text editor, photoshop or audio editor. Or my email client - or even the native Evernote application. For all of these there's no serious web version.
This comment might sound snarky but I'm honestly trying to think of what web apps I regularly use. And I can't come up with one.
I don't want them, even though I also consult for web development.
At home the only web applications I use, are the ones I am forced to, like hotel booking systems and forums, because USENET is moribund.
At home the only web applications I use, are the ones I am forced to, like hotel booking systems and forums, because USENET is moribund.
I have yet to see any widely used Web development tool that facilitates local reasoning: looking at a piece of code and knowing what it can or cannot do, without having to look at the rest of the program/page/stylesheet/whatever.
Web components/shadow DOM may help sooner or later.
http://www.w3.org/TR/2013/WD-components-intro-20130606/
http://www.w3.org/TR/2013/WD-components-intro-20130606/
And Angular directives are pretty self contained, with their own scope, template, functions, etc. You need angular.js obviously, but that's just the generic library.
Surely it remains easier to develop with VB6 than with Javascript. I am talking mainly from the IDE perspective.
One of the core technologies behind VB6 (COM) remains widely used in Microsoft Windows today.
One of the core technologies behind VB6 (COM) remains widely used in Microsoft Windows today.
> don't embrace silent failure modes as a feature.
I love Angular and perhaps in some places, and at certain times silent failures make sense (but would a console.log kill you?) but yeah... A-men!
I love Angular and perhaps in some places, and at certain times silent failures make sense (but would a console.log kill you?) but yeah... A-men!
The problem with silent failures is that they are a bad default. Sometimes, the best default is providing no default at all: just throw an exception that must be handled by the programmer. If you want to recover the silently failing behavior, you can always provide a wrapper function that catches the exception and handles it by doing nothing at all. (Admittedly, this is not so easy in nonfunctional languages like JavaScript that make it painful to program with combinators.)
The reason Angular has silent failure by default is because failure is designed to happen all the time - this means angular expressions can deal with data that hasn't arrived/hasn't been created yet.
This might sound like a bad thing, but it actually makes the page work without confusing the expression syntax with endless or statements.
That said, I do see your point - it's frustrating to find something not working due to a typo in an expression, with no errors to point it out. A halfway solution could be some kind of debug directive/tag that logs when an expression doesn't evaluate? Or perhaps something integrated into Angular Batarang? (https://chrome.google.com/webstore/detail/angularjs-batarang...)
This might sound like a bad thing, but it actually makes the page work without confusing the expression syntax with endless or statements.
That said, I do see your point - it's frustrating to find something not working due to a typo in an expression, with no errors to point it out. A halfway solution could be some kind of debug directive/tag that logs when an expression doesn't evaluate? Or perhaps something integrated into Angular Batarang? (https://chrome.google.com/webstore/detail/angularjs-batarang...)
VB6 didn't have structured types, and its binding was garbage.
VB6 had structs - they were called user-defined types. VB6 does not autodeclare global variables when you forget to type "var". And, if you use Option Explicit and avoid Variants and Objects, you can have some limited degree of type safety.
VB6 is by no means a good language, but JavaScript is much, much, much worse.
VB6 is by no means a good language, but JavaScript is much, much, much worse.
> VB6 does not autodeclare global variables when you forget to type "var".
Nor does JavaScript... "use strict";
Being what it is, JavaScript has come on a long way. Saying "avoid this specific feature" does make a language better. The same can be said about specific features of JavaScript (with, eval) but I'm sure you wouldn't make the same argument.
The fact seems to be that people are stuck in their ways and hate on JavaScript because they don't know the language as well they could and they haven't kept up to date with the evolving standards.
Nor does JavaScript... "use strict";
Being what it is, JavaScript has come on a long way. Saying "avoid this specific feature" does make a language better. The same can be said about specific features of JavaScript (with, eval) but I'm sure you wouldn't make the same argument.
The fact seems to be that people are stuck in their ways and hate on JavaScript because they don't know the language as well they could and they haven't kept up to date with the evolving standards.
People who "hate on JavaScript" tend to know the language very well. They also know at least several other languages very well. This knowledge makes JavaScript's many flaws much more obvious, and much less justifiable.
The basic fact is that prototype-based OO, for example, is much less practical than class-based OO. Experienced developers comprehend JavaScript's attempt at it just fine. This understanding doesn't change its inferiority, however. This is exactly why so many developers need to compensate for JavaScript's lack of desired functionality in this area by trying to fake class-based OO using the limited functionality that JavaScript does offer.
The same goes for many other aspects of JavaScript. Bad tools are still bad, even in the hands of experts.
I'm not really sure what you're talking about when you mention "evolving standards". If anything, JavaScript's standards haven't evolved well at all. Harmony is only now proposing the addition of core functionality that has been present in other languages for decades now, and should have been in JavaScript from the very beginning, too. JavaScript is merely "evolving" to where it should have been many years ago.
The basic fact is that prototype-based OO, for example, is much less practical than class-based OO. Experienced developers comprehend JavaScript's attempt at it just fine. This understanding doesn't change its inferiority, however. This is exactly why so many developers need to compensate for JavaScript's lack of desired functionality in this area by trying to fake class-based OO using the limited functionality that JavaScript does offer.
The same goes for many other aspects of JavaScript. Bad tools are still bad, even in the hands of experts.
I'm not really sure what you're talking about when you mention "evolving standards". If anything, JavaScript's standards haven't evolved well at all. Harmony is only now proposing the addition of core functionality that has been present in other languages for decades now, and should have been in JavaScript from the very beginning, too. JavaScript is merely "evolving" to where it should have been many years ago.
To be honest, I am not so convinced about classes as units of program organization either. Classes conflate in a single mechanism several concepts:
1. Types (classes)
2. Encapsulation (private, protected)
3. Polymorphism (virtuals)
4. Code reuse (inheritance)
While it is much better than prototypal inheritance, it is still less than ideal. On the other hand, there are languages like Haskell and ML which compartmentalize better these concepts:
1. Types: algebraic data types and type synonyms
2. Encapsulation: modules
3. Polymorphism: type constructors (parametric), type classes (ad-hoc, Haskell only)
4. Code reuse: derived type classes (Haskell only), functors (ML only)
The result of providing these features independently from one another is a net increase in flexibility. You can have, say, a module that exports two or more types, and a single function inside that module that can manipulate the internals of both types.
===
Edit: And Rust gets this right as well, of course!
1. Types: structs and enums
2. Encapsulation: modules and crates
3. Polymorphism: generics (parametric) and traits (ad-hoc)
4. Code reuse: trait inheritance and trait instances for generic types
1. Types (classes)
2. Encapsulation (private, protected)
3. Polymorphism (virtuals)
4. Code reuse (inheritance)
While it is much better than prototypal inheritance, it is still less than ideal. On the other hand, there are languages like Haskell and ML which compartmentalize better these concepts:
1. Types: algebraic data types and type synonyms
2. Encapsulation: modules
3. Polymorphism: type constructors (parametric), type classes (ad-hoc, Haskell only)
4. Code reuse: derived type classes (Haskell only), functors (ML only)
The result of providing these features independently from one another is a net increase in flexibility. You can have, say, a module that exports two or more types, and a single function inside that module that can manipulate the internals of both types.
===
Edit: And Rust gets this right as well, of course!
1. Types: structs and enums
2. Encapsulation: modules and crates
3. Polymorphism: generics (parametric) and traits (ad-hoc)
4. Code reuse: trait inheritance and trait instances for generic types
I'm extremely confused by this post. You claim to know JavaScript very well, which is fine, but then you go on to say that developers "fake class-based OO using the limited functionality that JavaScript does offer." That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse.
A lot of people who know JavaScript and several other languages very well don't hate on JavaScript. JavaScript has more than it's share of warts, obviously. We all know the story: it was written in a week, etc. It also has more than it's share of good parts, though, and if used correctly it is a very expressive language. In my experience, the haters are more frequently people who don't know the language as well. Clearly our experiences differ. I find it hard to believe, though, that anyone experienced in both languages would claim that JavaScript was worse than PHP, and PHP is still the most common back-end web language.
A lot of people who know JavaScript and several other languages very well don't hate on JavaScript. JavaScript has more than it's share of warts, obviously. We all know the story: it was written in a week, etc. It also has more than it's share of good parts, though, and if used correctly it is a very expressive language. In my experience, the haters are more frequently people who don't know the language as well. Clearly our experiences differ. I find it hard to believe, though, that anyone experienced in both languages would claim that JavaScript was worse than PHP, and PHP is still the most common back-end web language.
> That doesn't square with the fact that prototypal OO is strictly more expressive than class-based OO. You can implement class-based OO in a prototypal OO language. You cannot do the converse.
Actually, you can implement prototypal OO in a class-based language. First of all, you need a single class with two members variables and a member function. The member variables are a pointer or reference to a base object, and a hashmap from strings (member names) to objects (member values). In C++, this would be a std::unordered_map<std::string, boost::any>. The member function is an overload of the subscript operator (operator []) that takes a string argument and checks whether the hashmap contains the string as a key. If string is indeed a key, then its associated value is returned. Otherwise, the same subscript operator is evaluated for the base object and the same string. If there is no base object, then either an exception is thrown or a special undefined value is returned.
The feasibility of doing this is no big surprise. After all, dynamically typed languages are a very, very restricted subset of statically typed languages: http://existentialtype.wordpress.com/2011/03/19/dynamic-lang... . The main reason why users of class-based languages do not do this is that this breaks type safety for very little gain.
Actually, the supposed encoding of class-based OO in a prototypal language is not correct from an operational semantics point of view. In a statically typed OO language, methods and member variables must be known to exist, so they are directly used. The prototypal "encoding" fundamentally relies on testing at runtime whether methods or member variables exist, because it uses the mechanism described two paragraphs above. So it actually does something different than what statically typed class-based OO languages do.
> It also has more than it's share of good parts, though, and if used correctly it is a very expressive language.
For me, an expressive language is not a language that lets me encode hacks (after all, even C can do that), but a language that lets me encode mechanically checkable assurances that my code will work in specific ways. This allows other programmers to reuse my code with full confidence that it will work in the way they expect it to.
Actually, you can implement prototypal OO in a class-based language. First of all, you need a single class with two members variables and a member function. The member variables are a pointer or reference to a base object, and a hashmap from strings (member names) to objects (member values). In C++, this would be a std::unordered_map<std::string, boost::any>. The member function is an overload of the subscript operator (operator []) that takes a string argument and checks whether the hashmap contains the string as a key. If string is indeed a key, then its associated value is returned. Otherwise, the same subscript operator is evaluated for the base object and the same string. If there is no base object, then either an exception is thrown or a special undefined value is returned.
The feasibility of doing this is no big surprise. After all, dynamically typed languages are a very, very restricted subset of statically typed languages: http://existentialtype.wordpress.com/2011/03/19/dynamic-lang... . The main reason why users of class-based languages do not do this is that this breaks type safety for very little gain.
Actually, the supposed encoding of class-based OO in a prototypal language is not correct from an operational semantics point of view. In a statically typed OO language, methods and member variables must be known to exist, so they are directly used. The prototypal "encoding" fundamentally relies on testing at runtime whether methods or member variables exist, because it uses the mechanism described two paragraphs above. So it actually does something different than what statically typed class-based OO languages do.
> It also has more than it's share of good parts, though, and if used correctly it is a very expressive language.
For me, an expressive language is not a language that lets me encode hacks (after all, even C can do that), but a language that lets me encode mechanically checkable assurances that my code will work in specific ways. This allows other programmers to reuse my code with full confidence that it will work in the way they expect it to.
That's a pretty good try, but that does not implement the full flexibility of prototypal OO. Also, note that I wasn't talking about statically-typed class-based OO specifically. Classical OO exists in plenty of dynamic languages too, so your comments about type systems are kind of out of place. I prefer static typing too (as long as it comes with inference and polymorphism), but that's orthogonal to the discussion at hand.
> That's a pretty good try, but that does not implement the full flexibility of prototypal OO.
Are you talking about JavaScript's "this" keyword? I did not mention it in my preceding comment, because that is an implementation detail of JavaScript functions. I think my point still stands that (static) class-based OO languages are sufficiently powerful to encode the semantics of prototypal inheritance.
> Also, note that I wasn't talking about statically-typed class-based OO specifically. Classical OO exists in plenty of dynamic languages too, so your comments about type systems are kind of out of place.
You have a point there. When they say "classes", I usually think C++ classes or Eiffel classes, but you are right that there are dynamic languages that uses classes, too.
Are you talking about JavaScript's "this" keyword? I did not mention it in my preceding comment, because that is an implementation detail of JavaScript functions. I think my point still stands that (static) class-based OO languages are sufficiently powerful to encode the semantics of prototypal inheritance.
> Also, note that I wasn't talking about statically-typed class-based OO specifically. Classical OO exists in plenty of dynamic languages too, so your comments about type systems are kind of out of place.
You have a point there. When they say "classes", I usually think C++ classes or Eiffel classes, but you are right that there are dynamic languages that uses classes, too.
> that is an implementation detail of JavaScript functions.
Oh? So in an example where B has a method m, and A inherits from B, how is it that `this` refers to something different when calling B.m() than when calling A.m()? They're the exact same function.
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
Oh? So in an example where B has a method m, and A inherits from B, how is it that `this` refers to something different when calling B.m() than when calling A.m()? They're the exact same function.
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
> Oh? So in an example where B has a method m, and A inherits from B, how is it that `this` refers to something different when calling B.m() than when calling A.m()? They're the exact same function.
Just like in regular class-based OO languages, "this" is an implicit argument of every method that refers to the object on which the method was invoked.
You can even avoid manually doing all the "this" juggling yourself: Make a delegate class, which holds a reference to a method (including its captured variables) and a reference to the "this" object. When a method is retrieved from a an object, actually construct a delegate referencing both the method and the object. (If the method is retrieved after traversing the inheritance chain "upwards", fix the "this" reference along the way "downwards".) Finally, when a delegate is assigned to a variable or as a member of another object, get rid of the "this" reference and assign the method only instead. Client code never gets to see the "this" juggling.
Just like in regular class-based OO languages, "this" is an implicit argument of every method that refers to the object on which the method was invoked.
You can even avoid manually doing all the "this" juggling yourself: Make a delegate class, which holds a reference to a method (including its captured variables) and a reference to the "this" object. When a method is retrieved from a an object, actually construct a delegate referencing both the method and the object. (If the method is retrieved after traversing the inheritance chain "upwards", fix the "this" reference along the way "downwards".) Finally, when a delegate is assigned to a variable or as a member of another object, get rid of the "this" reference and assign the method only instead. Client code never gets to see the "this" juggling.
Oh I know how to implement it, I was just responding to your claim that it was "an implementation detail of JavaScript functions." It's an implementation detail of method calls, the function itself is completely this-agnostic. I guess I was just being pedantic ;)
Could you tell us which parts of "looking up missing keys in another map" are impossible to implement in Python or C?
Obviously not. I do, of course, disagree with your reduction of prototypal OO to "looking up missing keys in another map".
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
Well, it would help my understanding if you could elaborate on your disagreement rather than just saying that you disagree.
The additional constraint of not creating a new object system prevents me from making OO of any kind at all in C, but leaves most scripting languages that implement "classical inheritance" very open to implementing "prototypal inheritance". This is partly because they actually use "prototypal inheritance" and expose a "classical interface" as the primary one, so fiddling with __mro__ feels a little like cheating. If I want to avoid fiddling with the existing __mro__ and build my own, I can override __getattribute__. This certainly doesn't feel like making a new object system to me, but it also doesn't feel substantially different from overriding [] in C++.
The additional constraint of not creating a new object system prevents me from making OO of any kind at all in C, but leaves most scripting languages that implement "classical inheritance" very open to implementing "prototypal inheritance". This is partly because they actually use "prototypal inheritance" and expose a "classical interface" as the primary one, so fiddling with __mro__ feels a little like cheating. If I want to avoid fiddling with the existing __mro__ and build my own, I can override __getattribute__. This certainly doesn't feel like making a new object system to me, but it also doesn't feel substantially different from overriding [] in C++.
To be honest, I have no idea how to implement the exact operational semantics of prototypal inheritance in a dynamic language with classes. (Perhaps it is possible, but I would not bet on it.) In JavaScript, objects are statically known to be internally a pair of a base reference and a hashmap. In Python, you can define a tuple or class that has a base reference and a hashmap as members, but internally your program will test for the existence of these members all the time. So, different semantics.
But a static OO language can faithfully reproduce the operational semantics of prototypal inheritance.
But a static OO language can faithfully reproduce the operational semantics of prototypal inheritance.
The difference between "checking for the existence of the proto key in a hash map" and "checking whether the proto pointer that I am certain to have points to NULL" is due entirely to the differences in the semantics of Python and C++. Is it important just to implement prototypes, or to ensure that the guts of the prototype system are the same as the guts of a particular JS implementation? I'm not sure precisely where the goalposts have gone, so here are some prototypes in Python. http://pastie.org/8263966
Edit: Now with method binding that works instead of not working!
Edit: Now with method binding that works instead of not working!
To me, the issue isn't that modern JavaScript frameworks are sub-optimal, but rather that proficiency in the high number of competing frameworks is a sizeable time sink that shouldn't need to exist. These frameworks are essentially band-aids over the true issues in the core web development tools, and until that core matures to the point where the frameworks are unnecessary then you'll still see people reluctant in investing much time in absorbing knowledge that is likely to rapidly become obsolete.
Fully agree.
I love JavaScript, but I hate having to switch between BackBone, Angular, Dojo, etc. between projects. Learning each one, as well intentioned as they are, winds up being a productivity hit at some point, if not semi-regularly.
In a way I feel as if I've spent more time learning how to get things done w/JavaScript frameworks, than actually getting them done.
I love JavaScript, but I hate having to switch between BackBone, Angular, Dojo, etc. between projects. Learning each one, as well intentioned as they are, winds up being a productivity hit at some point, if not semi-regularly.
In a way I feel as if I've spent more time learning how to get things done w/JavaScript frameworks, than actually getting them done.
Even more frustrating than what you said (which is very frustrating) - Having already learned ember or backbone or whatever last year, I need to revisit it, or want to use it in my current project because it fits nicely. Or rather it used to. Turns out that in making it better (for whatever the "it" is) they changed fundamental bits on you, in such a way that you basically have to learn another new framework.
Heaven forbid you go back and maintain the stuff written with the old version of the framework...
Heaven forbid you go back and maintain the stuff written with the old version of the framework...
Yes, and that's why I'm now gun-shy to adopt any framework, JavaScript or otherwise.
For example, in LAMP context, I hit the problem you mention w/the Zend Framework 1 -> Zend Framework 2 upgrade path, as well as with Kohana 2 -> Kohana 3. ZF 2, in particular, pushed a lot of loyal ZF devs away, and after trying to upgrade existing projects, and use it for new projects, I'd say rightfully so. Now I'm stuck maintaining a large handful of projects built on top of unsupported frameworks.
For example, in LAMP context, I hit the problem you mention w/the Zend Framework 1 -> Zend Framework 2 upgrade path, as well as with Kohana 2 -> Kohana 3. ZF 2, in particular, pushed a lot of loyal ZF devs away, and after trying to upgrade existing projects, and use it for new projects, I'd say rightfully so. Now I'm stuck maintaining a large handful of projects built on top of unsupported frameworks.
Agreed. This also creates the problem of avoiding fundamentals. Is javascript really so bad we need to work exclusively in frameworks? Does CSS really need pre-processing?
I think the answer is 'sometimes', but these days people treat these new layers of complexity as non-negotiable.
I think the answer is 'sometimes', but these days people treat these new layers of complexity as non-negotiable.
I think that what the "problem" really is, is that programming has become so accessible. Of course, I don't mean that this is an actual problem, but just that with more people writing code, the community has more people being generally shitty.
Furthermore, the general shittiness of post-y2k developers has seeped into the corporate veins of tech companies everywhere. So this is why you see Go "gunning" for Ruby or Rust "gunning" for Go, or whatever. And I speak from experience. When I was in my late teens (I'm 27 now), I totally thought Javascript sucked; and, in many senses, it's not an ideal language. But I mean, I was really out there with my shitty (and uninformed) opinion that JS sucks.
Fast-forward a couple of years after I forced myself to do a lot of development with many (many) languages -- as opposed to being force-fed X or Y language by Z company -- and I have a different outlook. There are very few languages (or frameworks, for that matter) that suck -- furthermore, saying X sucks is simply insulting the (probably much smarter than you) author of X. This doesn't happen much on HN (people usually have well-thought out opinions) but it's very apparent on SO or the myriad of other forums/newsgroups.
I now love JS. I don't think it's amazing or anything, but I've been having as much fun writing JS as I've had writing C (which is saying a lot -- C is very fun). If I could get a freebie, though, I'd have to say that C++ sucks :P
So I agree with the sentiment of the OP and I think this is more prevalent now rather than 10 or 20 years ago because we have a much larger community of developers. Which, in some ways, is good but in others can be bad.
Furthermore, the general shittiness of post-y2k developers has seeped into the corporate veins of tech companies everywhere. So this is why you see Go "gunning" for Ruby or Rust "gunning" for Go, or whatever. And I speak from experience. When I was in my late teens (I'm 27 now), I totally thought Javascript sucked; and, in many senses, it's not an ideal language. But I mean, I was really out there with my shitty (and uninformed) opinion that JS sucks.
Fast-forward a couple of years after I forced myself to do a lot of development with many (many) languages -- as opposed to being force-fed X or Y language by Z company -- and I have a different outlook. There are very few languages (or frameworks, for that matter) that suck -- furthermore, saying X sucks is simply insulting the (probably much smarter than you) author of X. This doesn't happen much on HN (people usually have well-thought out opinions) but it's very apparent on SO or the myriad of other forums/newsgroups.
I now love JS. I don't think it's amazing or anything, but I've been having as much fun writing JS as I've had writing C (which is saying a lot -- C is very fun). If I could get a freebie, though, I'd have to say that C++ sucks :P
So I agree with the sentiment of the OP and I think this is more prevalent now rather than 10 or 20 years ago because we have a much larger community of developers. Which, in some ways, is good but in others can be bad.
Along these same lines, I can't even imagine what it must have been like to be a programmer (or any other kind of knowledge worker) before the web. You mean I have this problem and I need to wait 6 months for somebody to write a book about it, and then read the whole thing cover to cover in hopes that he/she wrote about something pertaining to my problem? phfft this is bullshit
It was frequently worse than that. I was a Microsoft developer back then, and the thing to do in that world was to join MSDN (http://en.wikipedia.org/wiki/Microsoft_Developer_Network). That meant agreeing to pay Microsoft several thousand dollars every year, in return for which they would periodically ship you a plastic crate containing a metric buttload of CDs. On those CDs were copies of every product Microsoft had ever made, along with all the documentation for all those products.
Buying one book every six months would have been a lot cheaper.
They'll still sell you that subscription, of course (http://msdn.microsoft.com/en-us/subscriptions/buy.aspx). Nowadays though the documentation portion is all available free on the Web (http://msdn.microsoft.com/library), at least. Progress!
Buying one book every six months would have been a lot cheaper.
They'll still sell you that subscription, of course (http://msdn.microsoft.com/en-us/subscriptions/buy.aspx). Nowadays though the documentation portion is all available free on the Web (http://msdn.microsoft.com/library), at least. Progress!
But then again, by reading a book (and products/libraries often came with them, no waiting required), you might learn about the whole thing, instead of begging and praying that someone at stackoverflow ran into the same undocumented quasi-feature and hobbled together a jerry-rigged fix.
Compared to CGIs/PHP? Yeah, sure, finally it almost behaves like a normal GUI library. And the way things going, we're probably going to get our Taligent/MFC library soon...
I know, the OP (and Louis CK before him) were mostly arguing against the Nirvana fallacy, where people complain about the status quo as opposed to some mythical idea of perfection. Problem is, I don't see the whole browser stack as superior to previous art (i.e. definitely not mythical). Things like NeWs or Smalltalk.
Compared to CGIs/PHP? Yeah, sure, finally it almost behaves like a normal GUI library. And the way things going, we're probably going to get our Taligent/MFC library soon...
I know, the OP (and Louis CK before him) were mostly arguing against the Nirvana fallacy, where people complain about the status quo as opposed to some mythical idea of perfection. Problem is, I don't see the whole browser stack as superior to previous art (i.e. definitely not mythical). Things like NeWs or Smalltalk.
I always thought NeWS was way ahead of its time. The modern web application stack looks a lot like what Gosling did in the 90s, but with PostScript replaced by JavaScript+HTML.
https://en.wikipedia.org/wiki/NeWS
https://en.wikipedia.org/wiki/NeWS
The good thing about that was that you could basically do everything in PostScript, in what way does that compare to the modern JavaScript/HTML/CSS+client/server mess? Never mind all the apparently necessary auxiliary languages (templates for HTML, preprocessors for CSS, transpilers for JavaScript).
The closest thing would be something that does almost everything in JavaScript and would abstract the HTML/CSS underpinnings away, but that's certainly not the current approach to "proper" web design (ExtJS would come to mind).
Honestly, I'd be hard-pressed to find any prior system with that many layers (VBScript?)...
The closest thing would be something that does almost everything in JavaScript and would abstract the HTML/CSS underpinnings away, but that's certainly not the current approach to "proper" web design (ExtJS would come to mind).
Honestly, I'd be hard-pressed to find any prior system with that many layers (VBScript?)...
I liked the part about "To support user interface widgets, NeWS expanded the original PostScript stack-based language into a complete object oriented (OO) programming style with inheritance."
It wasn't as bad as it sounds; there were mailing lists and usenet groups. Before that, software development was much simpler and much closer to the metal. If I didn't understand how some system call worked I'd just drop into the low-level debugger and step through it to see what it did. You can reasonably expect to understand how your whole OS works when the whole thing is only a few megabytes of machine code.
You're right, though, I used to buy volumes of Inside Macintosh and read them, cover to cover, over a cup of tea. I learned C++ from a book, too. I actually miss that style of learning; I like to understand my tools comprehensively, and not to just skim whatever I need from the reference and leave the rest as a mystery. I know that there are lots of programmers who spend their whole careers glomming together bits of other people's libraries, but that just doesn't appeal to me.
It was basically impossible to get any information about CS fundamentals before I got access to the WWW. I guess people in universities must have had access to textbooks, but as a working professional I didn't know enough about what I didn't know to even know there was something to look for, much less have anywhere I could try to find it.
You're right, though, I used to buy volumes of Inside Macintosh and read them, cover to cover, over a cup of tea. I learned C++ from a book, too. I actually miss that style of learning; I like to understand my tools comprehensively, and not to just skim whatever I need from the reference and leave the rest as a mystery. I know that there are lots of programmers who spend their whole careers glomming together bits of other people's libraries, but that just doesn't appeal to me.
It was basically impossible to get any information about CS fundamentals before I got access to the WWW. I guess people in universities must have had access to textbooks, but as a working professional I didn't know enough about what I didn't know to even know there was something to look for, much less have anywhere I could try to find it.
> I actually miss that style of learning; I like to understand my tools comprehensively, and not to just skim whatever I need from the reference and leave the rest as a mystery. I know that there are lots of programmers who spend their whole careers glomming together bits of other people's libraries, but that just doesn't appeal to me.
I think you're presenting a false dichotomy, and expressing inappropriate disdain for people with different learning styles from your own. For one thing, you can gain a deep understanding by using a library, language etc. in a nonlinear fashion. For my part, reading a book about programming from front to back 5 times and working the examples will leave me with long-term retention of somewhere in the neighborhood of 0%. Actually using the language and libraries and digging deeper as I need to gives me a far stronger grasp. I don't know everything there is to know about every feature of Core Graphics under OS X, for example, but three years since I last touched it, I could easily ramble for hours about all manner of crufty real world knowledge that I gleaned from using it.
I think you're presenting a false dichotomy, and expressing inappropriate disdain for people with different learning styles from your own. For one thing, you can gain a deep understanding by using a library, language etc. in a nonlinear fashion. For my part, reading a book about programming from front to back 5 times and working the examples will leave me with long-term retention of somewhere in the neighborhood of 0%. Actually using the language and libraries and digging deeper as I need to gives me a far stronger grasp. I don't know everything there is to know about every feature of Core Graphics under OS X, for example, but three years since I last touched it, I could easily ramble for hours about all manner of crufty real world knowledge that I gleaned from using it.
Sorry about that; I was aiming for wistfulness, not judgement. I really enjoyed that era.
It was nothing like that.
BBSes were linked and people transferred files and knowledge everywhere, much like they do today. FidoNet existed, which had a good sized community. I bought one of my first PCs on there. This was many years before eBay and Craigslist existed. ASCII text files existed, which contained a wealth of information. One of the few free sources of information on how compilers work is an ASCII text file. People still refer to this source, despite being nearly 2 decades old now (http://compilers.iecc.com/crenshaw/)
BBSes were linked and people transferred files and knowledge everywhere, much like they do today. FidoNet existed, which had a good sized community. I bought one of my first PCs on there. This was many years before eBay and Craigslist existed. ASCII text files existed, which contained a wealth of information. One of the few free sources of information on how compilers work is an ASCII text file. People still refer to this source, despite being nearly 2 decades old now (http://compilers.iecc.com/crenshaw/)
In a lot of ways it was easier. Your programming environment didn't really change rapidly. You could really learn your tools. Today I feel like by the time I barely get my head around something it's deprecated, or worse doesn't work at all anymore. The tools today are extraordinary, but there's very little incentive to learn them deeply, and high motivation to toss them aside when the next one comes along.
What? You mean, "I have this problem that I can actually apply reasoning skills to come up with a solution to. Later, I can compare notes with others who attacked the same problem in other ways to see what the pros/cons were." As opposed to today where "I have a solution that works, but according to the blogosphere it is no longer in fashion, and so must therefore be terrible and replaced as soon as possible."
Granted, I do not really think it is that bad, but still, the "dark ages" were hardly dark in this sense. I've been reading some of Knuth's "selected papers" series lately. Just reading about how he and others approached problems is amazing.
Granted, I do not really think it is that bad, but still, the "dark ages" were hardly dark in this sense. I've been reading some of Knuth's "selected papers" series lately. Just reading about how he and others approached problems is amazing.
I lived it. Operating systems and tools were simpler. There were reference manuals and tutorial books. Indeed, you better know your language and libraries from cover to cover. And sometimes debug in machine language. It's true that it could take months or years for you to learn about new things. I read about the first C++ compiler (with C as a target language) in a magazine. And I lived in a country that imposed a lot of barriers for importing software...
Well, before the Web there was Gopher and Archie and BBS's.
It wasn't the Dark Ages.
Maybe more like the Early Dawn Ages.
It wasn't the Dark Ages.
Maybe more like the Early Dawn Ages.
There was also an option of sitting down with paper and pencil and actually solving the problem, reinventing the wheel for the thousandth time. Or you could reach out to specific people you knew were likely to know something about the problem and socialize a bit by the way.
Both approaches had some good sides to them and it's a shame that they're not even considered as options now, which GP seems to demonstrate.
Both approaches had some good sides to them and it's a shame that they're not even considered as options now, which GP seems to demonstrate.
Yeah, it occurred to me that way back when, as I was learning C on a C=64 (though later I was able to buy a super powerful 386 machine) that as I was trying to code up alife and neural net programs my problems were rarely of the "What's the workaround for a bug in alife.js or alife.rb" sort.
I wrote out a lot of pseudo-code and drew diagrams and when stuff didn't work I could often figure it out by poking through the K&R book or the manual for my compiler.
As it became easier to spread code and ideas it also became easier to spread more sophisticated but sometimes opaque libraries and tools, and perhaps ironically it is those new libraries and tools that most require the increased communication because while they offer more power they also introduce more complex bugs and quirks.
I wrote out a lot of pseudo-code and drew diagrams and when stuff didn't work I could often figure it out by poking through the K&R book or the manual for my compiler.
As it became easier to spread code and ideas it also became easier to spread more sophisticated but sometimes opaque libraries and tools, and perhaps ironically it is those new libraries and tools that most require the increased communication because while they offer more power they also introduce more complex bugs and quirks.
Plot twist: the so-called "Dark Ages" were not the Dark Ages either.
I had no problems with pressing F1.
It's a cliche by now that oldsters always think that youngsters are spoiled by having it too easy. "In my day, we had to walk to school uphill two miles in the snow" etc. And, like so many other cliches, it's true!
Things used to really suck, and now they're a lot better. That happens every generation--mankind's physical culture does keep on improving in a lot of ways. Older people are proud of all the progress they've made. And young people take the new and improved stuff for granted and complain.
But that complaining is a good thing! Expectations keep increasing with every generation. If we didn't always have new people coming on scene and getting frustrated with the status quo, then we'd stagnate as a culture.
The kids are all right. It would be nice if they appreciated what they have more. On the other hand, they'll get old and have the same experience too.
Things used to really suck, and now they're a lot better. That happens every generation--mankind's physical culture does keep on improving in a lot of ways. Older people are proud of all the progress they've made. And young people take the new and improved stuff for granted and complain.
But that complaining is a good thing! Expectations keep increasing with every generation. If we didn't always have new people coming on scene and getting frustrated with the status quo, then we'd stagnate as a culture.
The kids are all right. It would be nice if they appreciated what they have more. On the other hand, they'll get old and have the same experience too.
I'm not sure that's true at all. A lot of us older developers look at the tools we used in the 1970s, 1980s and 1990s, and we can't help but notice how much better they are, even today, than many of the most-hyped tools these days.
I feel sorry for many of the younger developers today who only know of JavaScript, PHP, NoSQL and web development. They don't know what they're missing out on, nor do they truly know how inferior their tools are.
And when it comes to getting serious work done, we still use C, C++ and Fortran today. Yes, they've advanced in many ways over time, but I think they just go to show how much better many technologies were in years past. Even modern tools just can't compete with them.
I feel sorry for many of the younger developers today who only know of JavaScript, PHP, NoSQL and web development. They don't know what they're missing out on, nor do they truly know how inferior their tools are.
And when it comes to getting serious work done, we still use C, C++ and Fortran today. Yes, they've advanced in many ways over time, but I think they just go to show how much better many technologies were in years past. Even modern tools just can't compete with them.
I still think foxpro/visual foxpro and more recently delphi was the most accesible dev environment.
I still have not found the easy and power of fox to do data task and the RAD way of delphi in any tool I have tried...
I still have not found the easy and power of fox to do data task and the RAD way of delphi in any tool I have tried...
I miss the compile times, native compilers and RAD abilities for strong type languages like Turbo Pascal and Delphi that were already available in 16 bit environments.
Funny to see younger developers rediscovering this type of tooling that was killed by C and VM environments.
Funny to see younger developers rediscovering this type of tooling that was killed by C and VM environments.
>NoSQL
I don't feel sorry for anyone who hasn't had to work with relational databases.
I don't feel sorry for anyone who hasn't had to work with relational databases.
I feel kind of sorry for anyone using a database with no schema enforcement, who has yet to learn why hope is not a strategy for maintaining its integrity over time. I've seen Notes documents decay to nonsensical states the app can't handle at all within five years.
I haven't actually used NoSQL in a project, so I can't speak to whether those disadvantages are worth the trade off or not in practice. What I can say is that it is a trade off to use a relational database.
The problem with relational databases is that constructing queries for anything but the simplest operations is incredibly counterintuitive, and easy to screw up in subtle ways. Then, the data you get out is usually nothing like the actual structure you need, so you have to process it and squish it into the shape you want. The common results I've seen of this are 1) programmers writing loops to execute simple queries that they can understand, and 2) programmers writing insanely inefficient or totally broken complex queries. And that's assuming that the database was designed correctly (or even sanely) in the first place.
And yes, you can use an ORM, but then it becomes even more questionable whether you're getting any sort of benefit over NoSQL.
The crux of the problem is that the standard-issue persistence mechanism for web development is something that superficially appears to be accessible via ordinary programming knowledge, but actually turns out to have been developed by a long lost Martian colony whose technological evolution followed a radically different path from our own. MySQL is not something you should jump into without having at least read a book on relational database design, and that's a step that many programmers clearly do not take.
Current NoSQL solutions clearly have their problems too, but from what I can tell, they don't seem to be insurmountable ones. And at least it's a step in a new direction, even if it's not quite the right one. Bad database design and use is a plague, and it's pretty clear by now that education alone isn't a practical solution.
The problem with relational databases is that constructing queries for anything but the simplest operations is incredibly counterintuitive, and easy to screw up in subtle ways. Then, the data you get out is usually nothing like the actual structure you need, so you have to process it and squish it into the shape you want. The common results I've seen of this are 1) programmers writing loops to execute simple queries that they can understand, and 2) programmers writing insanely inefficient or totally broken complex queries. And that's assuming that the database was designed correctly (or even sanely) in the first place.
And yes, you can use an ORM, but then it becomes even more questionable whether you're getting any sort of benefit over NoSQL.
The crux of the problem is that the standard-issue persistence mechanism for web development is something that superficially appears to be accessible via ordinary programming knowledge, but actually turns out to have been developed by a long lost Martian colony whose technological evolution followed a radically different path from our own. MySQL is not something you should jump into without having at least read a book on relational database design, and that's a step that many programmers clearly do not take.
Current NoSQL solutions clearly have their problems too, but from what I can tell, they don't seem to be insurmountable ones. And at least it's a step in a new direction, even if it's not quite the right one. Bad database design and use is a plague, and it's pretty clear by now that education alone isn't a practical solution.
You have it precisely backwards.
The old-timers are looking at the youngsters getting excited about only having to walk 1.5 miles uphill in the snow.
And scratching their heads, because they remember the days when they had hovercraft to get around.
The old-timers are looking at the youngsters getting excited about only having to walk 1.5 miles uphill in the snow.
And scratching their heads, because they remember the days when they had hovercraft to get around.
One highly desirable outcome of kids having it too easy is instead of saying "this sucks", they might say "I could improve this", and then you end up with things that we already consider to be 'too easy' even more accessible.
As a 35 year old developer who was using CSS and Javascript in the pre-jQuery days, this really strikes a chord with me. Things like Meteor and Angular and Bootstrap BLOW MY MIND. I understand this is the way of technology but truly we live in a gilded age of app development. Sometimes it's nice to take a retrospective and think about how awesome things really are.
I'm gonna pretend you're just bad with word choice and were sincere with your post...
While it's good to maintain a positive attitude and congratulate ourselves on the progress we've made, it's unwise to call ourselves "awesome." We're anything but.
Web development is still way harder than it should be. Javascript is still much worse than it could be. Node.js is still a bad plan. Software is very much in its infancy. We're still 10-25 years behind the state of the art in the industry, and many people get defensive if you point it out because their egos are tightly coupled with their work work methodology.
It's not hopeless, but it's nowhere near done. And hyper-nested callbacks are a primitive that we should grow beyond, and numerous methods to do so are not only possible, but already researched and proven before you and I were born.
While it's good to maintain a positive attitude and congratulate ourselves on the progress we've made, it's unwise to call ourselves "awesome." We're anything but.
Web development is still way harder than it should be. Javascript is still much worse than it could be. Node.js is still a bad plan. Software is very much in its infancy. We're still 10-25 years behind the state of the art in the industry, and many people get defensive if you point it out because their egos are tightly coupled with their work work methodology.
It's not hopeless, but it's nowhere near done. And hyper-nested callbacks are a primitive that we should grow beyond, and numerous methods to do so are not only possible, but already researched and proven before you and I were born.
This "we're anything but" mindset is self-perpetuating. 10-25 years from now the next generation of programmers will be saying the same thing. Before 1995 the concept of spending a weekend, making a reasonably functional web app and having the entire planet access it at a moment's notice simply was not feasible to even entertain mentally to anyone except those in academic and military circles who already had access to the Internet, and even then the "reasonably functional in a weekend" was not part of that equation.
If we stop focusing on what's "wrong" and take a moment to see how incredible people's reach and speed-to-market is compared to even 10-15 years ago, we might actually take a moment to stop talking about how terrible everything is and marvel at just how far we've come.
Glass half-full is what I'm trying to accomplish here.
If we stop focusing on what's "wrong" and take a moment to see how incredible people's reach and speed-to-market is compared to even 10-15 years ago, we might actually take a moment to stop talking about how terrible everything is and marvel at just how far we've come.
Glass half-full is what I'm trying to accomplish here.
> This "we're anything but" mindset is self-perpetuating. 10-25 years from now the next generation of programmers will be saying the same thing.
Depends. If they're still 20 years behind academia, they deserve to be saying it. If they still have this weird culture that abhors modern advances in favor of "getting shit done" and wastes time arguing what kind of text editor matters, they deserve to say that.
> Glass half-full is what I'm trying to accomplish here.
I like to say that the glass has 118.29 cubic centimeters of water in it.
Depends. If they're still 20 years behind academia, they deserve to be saying it. If they still have this weird culture that abhors modern advances in favor of "getting shit done" and wastes time arguing what kind of text editor matters, they deserve to say that.
> Glass half-full is what I'm trying to accomplish here.
I like to say that the glass has 118.29 cubic centimeters of water in it.
> truly we live in a gilded age of app development
Are you intentionally referring to a superficial positive veneer hiding serious, fundamental, and widespread problems [1] or are you meaning to refer to a "golden age" [2] instead of a "gilded" one?
[1] http://en.wikipedia.org/wiki/Gilded_age
[2] http://en.wikipedia.org/wiki/Golden_age
Are you intentionally referring to a superficial positive veneer hiding serious, fundamental, and widespread problems [1] or are you meaning to refer to a "golden age" [2] instead of a "gilded" one?
[1] http://en.wikipedia.org/wiki/Gilded_age
[2] http://en.wikipedia.org/wiki/Golden_age
I believe "gilded" is spot on here, because that's what the state of the art Web essentially is: sleek designs rendered by stacks of software/technologies "hiding serious, fundamental, and widespread problems" (browsers).
I think you're probably about 5 years too young (maybe that's where OP is coming from). You started in the Dark Ages but didn't experience the Classical times before them of desktop and client/server apps.
There are a lot of advantages to web development, but in terms of tools really helping you to whip up something that meets the standards of the day, we still haven't caught up to those times. Meteor is the only framework I've used that I'd say is as painless as Delphi and its like were at the time.
There are a lot of advantages to web development, but in terms of tools really helping you to whip up something that meets the standards of the day, we still haven't caught up to those times. Meteor is the only framework I've used that I'd say is as painless as Delphi and its like were at the time.
Actually I taught myself how to program in my early teens using C++ on DOS and Windows 3.x in the early 90's, so I do in fact remember those days.
Sometimes it's nice to take a retrospective and think about how awesome things really are
But are you sure it isn't nicer to just complain? It's certainly easier! ;)
But are you sure it isn't nicer to just complain? It's certainly easier! ;)
Yes, people definitely thrive more on complaining.
If you cover it with sugar glazing it looks just like a cake, right?
I believe the problem with _every_ framework out there is that they focus too much on how they solve trivial problems and not enough on how you can use them in complex scenario.
I think people are pissed when they start with a new framework is the lack of ERROR messages.
I wished errors were more verbose. I don't care if the error message takes 5 lines. When I'm used to a framework, i'll know from the second word what is the error.
On the other hand, when I don't know the framework, I have no ideas what is assumed and what isn't. Print all the remotely possible culprit. That will give me an idea how it works.
Errors will help me learn and progress.
I think people are pissed when they start with a new framework is the lack of ERROR messages.
I wished errors were more verbose. I don't care if the error message takes 5 lines. When I'm used to a framework, i'll know from the second word what is the error.
On the other hand, when I don't know the framework, I have no ideas what is assumed and what isn't. Print all the remotely possible culprit. That will give me an idea how it works.
Errors will help me learn and progress.
Agreed. I wish more open source would make it an actual goal to provide awesome error messages. A good example is the Rebus service bus for .NET which has it as an actual goal to have the best error messages - resulting in stuff like:
https://github.com/mookid8000/Rebus/blob/master/src/Rebus/Co...
https://github.com/mookid8000/Rebus/blob/master/src/Rebus/Co...
tldr; it's a satirical cross-section of programming and comedy, and is specifically a play on the classic Louis C K cellphones/airplane rant as it pertains to javascript frameworks: http://www.youtube.com/watch?v=KpUNA2nutbk
Even more specifically, the blog post is an adaptation of the shorter version he told on Conan's show. (linked below the post)
There are two facts about Web apps that few people seem to be able to hold in their heads at the same time:
1. Web apps are incredibly useful and convenient. Web apps are always up to date and pervasive because the Web runtime is everywhere. Some apps only need ever be Web apps.
2. The Web was designed to be a feature-rich hypertext system, not an application runtime and system-wide UI framework. Web apps will never be as good as native apps, something that was rediscovered in mobile devices.
Both are true. Both will be true for a long time to come.
1. Web apps are incredibly useful and convenient. Web apps are always up to date and pervasive because the Web runtime is everywhere. Some apps only need ever be Web apps.
2. The Web was designed to be a feature-rich hypertext system, not an application runtime and system-wide UI framework. Web apps will never be as good as native apps, something that was rediscovered in mobile devices.
Both are true. Both will be true for a long time to come.
Sooo, am I the only one on here who thinks this is really funny? Like laugh-out-loud funny? Like, literally right now there are 110 comments on this page about a light-hearted spoof and not one mention of the word funny.
Like I know you're just dying to tell someone their argument is absurd, precisely backward, badly false, from another reality, or some other hyperlogical sounding construction that no human would ever actually use in normal conversation - but chill OUT. Do you really need to immediately jump into a flame war about BASIC?
Can't you just chuckle at the fact that yeah, we are all kinda entitled turds form time to time when it comes to tech, and then like go about your day and build something and go home?
I mean come on -- "It's going to space, give it a sec." -- that's funny.
Like I know you're just dying to tell someone their argument is absurd, precisely backward, badly false, from another reality, or some other hyperlogical sounding construction that no human would ever actually use in normal conversation - but chill OUT. Do you really need to immediately jump into a flame war about BASIC?
Can't you just chuckle at the fact that yeah, we are all kinda entitled turds form time to time when it comes to tech, and then like go about your day and build something and go home?
I mean come on -- "It's going to space, give it a sec." -- that's funny.
I think that everyone was probably put off that this was a total ripoff of Louie CKs bit. More credit should have been given at the top of the article.
It was better with the credit buried. Those who know, know. There was this delightful, hopeful, uncertainty at first. "Is he going to pull a Louis CK riff? I think he is...yes!"
Then it was a matter of seeing if he was going to drop the ball (there were some fumbles) but maybe "x is awesome and nobody is happy" will be the aristocrats for a less obscene demographic.
So yeah, we can bitch about the 19 location-aware social cloud startups announced each day, but it's also good to get frickin' excited with what you can do for free with some stuff you download onto a laptop while on an airplane.
Imagine going up to your 8-year old self and saying,"You know that Atari 800 you love second only to your dog? Look at my PHONE! It could tell you the weather right where we are, without having to tell it where we were! I could look up what you were doing right now! Um, look at these birds going after these pigs!"
Then it was a matter of seeing if he was going to drop the ball (there were some fumbles) but maybe "x is awesome and nobody is happy" will be the aristocrats for a less obscene demographic.
So yeah, we can bitch about the 19 location-aware social cloud startups announced each day, but it's also good to get frickin' excited with what you can do for free with some stuff you download onto a laptop while on an airplane.
Imagine going up to your 8-year old self and saying,"You know that Atari 800 you love second only to your dog? Look at my PHONE! It could tell you the weather right where we are, without having to tell it where we were! I could look up what you were doing right now! Um, look at these birds going after these pigs!"
I've never met people like this before. Almost everybody who I've heard trash-talk a language or framework was either very new to it and felt frustrated, or just a bad programmer.
Having said that, not all JS frameworks are built the same. ;) And you're entitled to have a preference and not be "Louis CK'd" into loving everything under the sky.
Having said that, not all JS frameworks are built the same. ;) And you're entitled to have a preference and not be "Louis CK'd" into loving everything under the sky.
I started off as a Rails web developer in 2007 and slowly moved to PHP and Javascript. A little before NodeJS got popular I was a full time JS developer mostly writing client side code.
When I started with NodeJS, I was like a kid in the candy store. Before I blinked there were hundreds of npm modules supporting everything including aws management to controlling robots.
I have tried a lot of nodejs web frameworks. They are all amazing and I wish them success but I have realized that there is nothing great to be gained by using JS at server side compared to using say rails.
When I started with NodeJS, I was like a kid in the candy store. Before I blinked there were hundreds of npm modules supporting everything including aws management to controlling robots.
I have tried a lot of nodejs web frameworks. They are all amazing and I wish them success but I have realized that there is nothing great to be gained by using JS at server side compared to using say rails.
> I have realized that there is nothing great to be gained by using JS at server side compared to using say rails.
Web sockets, anything with many thousands of concurrent connections is better in node.js. They each have their strengths, which overlap very little.
Web sockets, anything with many thousands of concurrent connections is better in node.js. They each have their strengths, which overlap very little.
Maybe they're annoyed because even though the frameworks are great, they are still stuck programming in shitty JavaScript and they know there are about 1,000 better programming languages.
Hey, I beg to differ! HTML and CSS are pretty crappy as well!
Our customers demand more of us, we demand more of our frameworks.
It wasn’t long ago that building a site that worked on a mobile was the most fantastic and impressive thing they had ever seen. Before that, there weren’t even ‘mobiles’ to have ‘sites’ on.
If the demands put on programs were the same as they were 10, 20 years ago, I would have my week’s work done in 5 minutes. But it’s not amazing any more, it’s boring and usual and old as soon as it is released. Our customer or boss just saw a new example up on nvd3, so d3’s dead now, and you better have already learned nvd3 (that’s a pretty old example), oh and it still works on a mobile, and fills my retina display, right? Oh and it doesn’t move properly when I scroll on my android tablet. That’s the same as an iPad, right? Oh and John said it’s broken in IE.
Our demands come from our customer’s expectation that this stuff is easy now. And hells yeah it is SO much easier than it used to be, but it’s far from being as easy as they think it is.
We usually only have an hour to get going in a new framework, if it’s not clear after that, we move on, because something newer (better?) just hit #1 on HN.
But let’s remember how exiting all of this is. Programming has changed for the better. It’s cool and in demand now. People are paying us to do the cool things we used to dream about, they just might not be giving us quite enough time, so we blame the frameworks.
It wasn’t long ago that building a site that worked on a mobile was the most fantastic and impressive thing they had ever seen. Before that, there weren’t even ‘mobiles’ to have ‘sites’ on.
If the demands put on programs were the same as they were 10, 20 years ago, I would have my week’s work done in 5 minutes. But it’s not amazing any more, it’s boring and usual and old as soon as it is released. Our customer or boss just saw a new example up on nvd3, so d3’s dead now, and you better have already learned nvd3 (that’s a pretty old example), oh and it still works on a mobile, and fills my retina display, right? Oh and it doesn’t move properly when I scroll on my android tablet. That’s the same as an iPad, right? Oh and John said it’s broken in IE.
Our demands come from our customer’s expectation that this stuff is easy now. And hells yeah it is SO much easier than it used to be, but it’s far from being as easy as they think it is.
We usually only have an hour to get going in a new framework, if it’s not clear after that, we move on, because something newer (better?) just hit #1 on HN.
But let’s remember how exiting all of this is. Programming has changed for the better. It’s cool and in demand now. People are paying us to do the cool things we used to dream about, they just might not be giving us quite enough time, so we blame the frameworks.
I feel like part of the problem is that there seems to be a weird form of commodity fetishism that happens with front-end frameworks where your choice defines you as a developer. While that's always been true for OS, language and text editor, it seems more inane when applied to front end frameworks. They all have their own use cases and the major three are all impressively written
When I detect this attitude in myself it's often because I'm thinking of these things as a means to an end instead of a thing in itself. So I get impatient because I WANT TO GET STUFF DONE RIGHT NOW and pick your framework is in my way. This a great reminder to step back, appreciate, and give props to all the hard work people do out there.
The best thing about JavaScript is jsfiddle and codepen. There's really no equivalent for any other programming environment.
I loved JavaScript during what this calls the "rotary phone" era, and I'll have to say that JavaScript "frameworks" haven't come very far. They just grow as fast as the browsers do.
Browsers have gone far. Browsers are amazing. Frameworks are still boring.
Browsers have gone far. Browsers are amazing. Frameworks are still boring.
My interpretation: javascript is slowly catching up to the rest of the world. It's reach both makes it a lingua franca and slows it down. Maybe one day it will be suitable for real programming, if people who complain after 10 minutes would stop holding it back.
The drive of the hacker is to solve problems and find novel or efficient solutions to problems and the tools used to solve those problems.
It's not surprising that this can be taken to the extreme as we strive to continually optimize our tools, which are especially flexible since they are spun out of almost pure abstraction.
A healthy dose of perspective is helpful to reminds us that at the end of the day we solve problems and make cool things.
Though dealing with poorly designed man-made abstractions can be frustrating, we are fortunate to have the opportunity to improve our tools and environments and it's especially incredible how collaborative the effort is (open source) compared to some other industries.
It's not surprising that this can be taken to the extreme as we strive to continually optimize our tools, which are especially flexible since they are spun out of almost pure abstraction.
A healthy dose of perspective is helpful to reminds us that at the end of the day we solve problems and make cool things.
Though dealing with poorly designed man-made abstractions can be frustrating, we are fortunate to have the opportunity to improve our tools and environments and it's especially incredible how collaborative the effort is (open source) compared to some other industries.
The people who complain about how things work are the people who make things better. If everyone was satisfied with jQuery and felt that JS development could stop after that then we wouldn't be where we are today, and if everybody thinks that where we are now is fine then tomorrow will look exactly the same as today. I, for one, want tomorow to look different (and better) regardless of how rosy it looks today, so I will continue complaining. When I can, I will also do something about my complaints, and I do submit patches when I can, but unfortunately thats not always feasible.
[deleted]
Haters gona hate. You can't make everybody happy, but there are enough frameworks out there you pick one you like and let everybody do the same
"it’s wasted on the crappiest generation of just spoiled idiots that don’t care, because this is what people are like now"
Louis CK sums it up better than I could ever articulate
https://www.youtube.com/watch?v=KpUNA2nutbk&feature=player_d...
Louis CK sums it up better than I could ever articulate
https://www.youtube.com/watch?v=KpUNA2nutbk&feature=player_d...
A million thumbs down for the author stealing Louie CK's stand-up routine (https://www.youtube.com/watch?v=KpUNA2nutbk) and reapplying it to Javascript in a way that just didn't fit. Also nothing substantial was said. Boo!
> A million thumbs down for the author stealing Louie CK's stand-up routine
Note the line at the bottom of the piece:
> Credit: http://www.dailymotion.com/video/x8m5d0_everything-is-amazin...
Note the line at the bottom of the piece:
> Credit: http://www.dailymotion.com/video/x8m5d0_everything-is-amazin...
I didn't see the attribution. But everything I said still stands. The whole thing just didn't work.
Not... really a good enough attibution... I'm supposed to go watch that link at the bottom of the article and then cross reference it with the funny things said in the article? I was expecting the very first link in the heading to point to that routine and for it to be 'the joke'.
If you don't know the routine, it won't be funny anyway.
It's an easy way of excluding people under 40. Like when we talk about being afraid to visit Northern Ireland or getting nuked.
It's an easy way of excluding people under 40. Like when we talk about being afraid to visit Northern Ireland or getting nuked.
No. Wrong. They're not happy because it's not amazing. Because they can sensing something you cannot sense.
Well, only for certain type of apps - static input/output forms -, this maybe true. But none of them is amazing for any further type of apps.
You can be happy because you don't know any further.
Well, only for certain type of apps - static input/output forms -, this maybe true. But none of them is amazing for any further type of apps.
You can be happy because you don't know any further.
"Wow, Catullus, thanks for the chariot ride ... the last time I had to run for a day and a half and .... Recedite! excreta caballus!"
"Wow, beaming to the surface is so much faster than that goddamn shuttle. And ... hey! This shirt wasn't this shade of blue before! Mother$#)!($&!"
"Wow, beaming to the surface is so much faster than that goddamn shuttle. And ... hey! This shirt wasn't this shade of blue before! Mother$#)!($&!"
We're also doing a magnitude more with these frameworks than was ever possible before. Tools are better and bigger, but so are roles and responsibilities. There are different sets of problems that now need to be solved.
> "Well, I can't do any more things now. I can't do any more things."
I just love that. I've encountered that attitude so many times.
I just love that. I've encountered that attitude so many times.
You should give more credit to the original creator of these ideas. Put the link at the top and at least mention him in your article.
Let's not forget about the awesome tooling that is available and actively development for JS web development (yes, Yeoman).
different languages tend to attract different personalities
eg. people from c/c++ are more conservatives and like to know the internals of everything..
Javascript(PHP?) tend to attract people who wants instant reward, without too much work..
to point out that a little more is easy to see that even here at HN.. when a new project come from c/c++/go etc.. the tools are more sophisticated and take more planning, labor and research to see the light.. so this kind of projects tend to endure a little bit more
on the other half javascripters launch are more fragmented and you see a lot of iterations over the same problems already solved by previous framework as just because its a matter of taste combining the technologies one like most..
i cant say this for every developer of course, im sure there are people away from this pattern.. but its a just a feeling from the outside.. i come from other generation i guess.. ut when i was younger pascal, delphy and php were cool and just get things done.. i think its also a question of age.. when you are younger you are more pragmatic, and want everything fast and instant.. Javascript is that platform now.. the one who tends to call the younger and people who are starting programming..
this is not a critic, and not a bad thing at all.. its just more a general observation.. so excuse-me if i was unfair in anyway (thats the problem with generalizations though)
Well the problem with pragmatism its just that... people start doing things with a low critical thinking about the tool they are using.. they tend to experiment less with other languages and the different solutions those languages may point out..
so the problem pointed out by miguel de icaza over the callbacks.. they were spread all around in the code like if they were the solution for everything.. or just _to get things done_
to be fair this is not _just_ a problem of javascript or another language.. its technology in general and the open source..
people should be more cooperative and less competitive.. why create a new blog engine just because you want to use another template system and do not try to help the other project by adding the template system you like..
there are much of ego in technology today.. people want to be the new linus torvalds, or the new steve jobs.. but behind all of those big stars, and what they acomplished, there A LOT of people working in the same project , all together.. so its the real spirit of cooperation behind it, even if they dont tkae the medals.. they deserve it they are also the everyday heros
you can argue that this is may outside of the scope of this post.. but im trying to point what i think are the real reasons, of why those things are happening.. and its not enough to look just at technology.. we need to take a look at the people behind it and how they move..
just my 2 dollars (because this comment its a little big for 2 cents)
Javascript(PHP?) tend to attract people who wants instant reward, without too much work..
to point out that a little more is easy to see that even here at HN.. when a new project come from c/c++/go etc.. the tools are more sophisticated and take more planning, labor and research to see the light.. so this kind of projects tend to endure a little bit more
on the other half javascripters launch are more fragmented and you see a lot of iterations over the same problems already solved by previous framework as just because its a matter of taste combining the technologies one like most..
i cant say this for every developer of course, im sure there are people away from this pattern.. but its a just a feeling from the outside.. i come from other generation i guess.. ut when i was younger pascal, delphy and php were cool and just get things done.. i think its also a question of age.. when you are younger you are more pragmatic, and want everything fast and instant.. Javascript is that platform now.. the one who tends to call the younger and people who are starting programming..
this is not a critic, and not a bad thing at all.. its just more a general observation.. so excuse-me if i was unfair in anyway (thats the problem with generalizations though)
Well the problem with pragmatism its just that... people start doing things with a low critical thinking about the tool they are using.. they tend to experiment less with other languages and the different solutions those languages may point out..
so the problem pointed out by miguel de icaza over the callbacks.. they were spread all around in the code like if they were the solution for everything.. or just _to get things done_
to be fair this is not _just_ a problem of javascript or another language.. its technology in general and the open source..
people should be more cooperative and less competitive.. why create a new blog engine just because you want to use another template system and do not try to help the other project by adding the template system you like..
there are much of ego in technology today.. people want to be the new linus torvalds, or the new steve jobs.. but behind all of those big stars, and what they acomplished, there A LOT of people working in the same project , all together.. so its the real spirit of cooperation behind it, even if they dont tkae the medals.. they deserve it they are also the everyday heros
you can argue that this is may outside of the scope of this post.. but im trying to point what i think are the real reasons, of why those things are happening.. and its not enough to look just at technology.. we need to take a look at the people behind it and how they move..
just my 2 dollars (because this comment its a little big for 2 cents)
People are spoiled easily. And contrary to common belief, programmers are people too.
This is incredible, and oh so true
[deleted]
Congrats Javascript--on almost being as good at data-binding and layout as VB6! Me, I'm going to keep kvetching about javascript frameworks until flexbox is widely supported, the strongly-typed language flavor-of-the week actually is stable, and frameworks like angular don't embrace silent failure modes as a feature.