Hacker News new | comments | show | ask | jobs | submit login

The trick to being successful with JavaScript is to relax and allow yourself to slightly sink into your office chair as a gelatinous blob of developer.

When you feel yourself getting all rigid and tense in the muscles, say, because you read an article about how you're doing it wrong or that your favourite libraries are dead-ends, just take a deep breath and patiently allow yourself to return to your gelatinous form.

Now I know what you're thinking, "that's good and all, but I'll just slowly become an obsolete blob of goo in an over-priced, surprisingly uncomfortable, but good looking office chair. I like money, but at my company they don't pay the non-performing goo-balls." Which is an understandable concern, but before we address it, notice how your butt no-longer feels half sore, half numb when in goo form, and how nice that kind of is. Ever wonder what that third lever under your chair does? Now's a perfect time to find out!

As long as you accept that you're always going to be doing it wrong, that there's always a newer library, and that your code will never scale infinitely on the first try, you'll find that you can succeed and remain gelatinous. Pick a stack then put on the blinders until its time to refactor/rebuild for the next order of magnitude of scaling, or the next project.




In my experience using last year's darling framework instead of this year's is an excellent way to go. The codebase is stable and full-featured, the plugin ecosystem is rich, the documentation is extensive, and stackoverflow is already filled with accepted answers.

It's a myth that new languages and frameworks offer better productivity. Mostly it's just the flavor that's different, not the calories. Sometimes you get a genuine improvement, like react, but the vast majority of frameworks are completely optional when it comes to getting stuff done. I'm always reminded of this when I observe the Delphi team at work. Still lapping any web developer when it comes to shipping features.


Delphi lapping the web has less to do with delphi and more to do with the web. Web development sucks and all the frameworks and javascript engines and css preprocessors are just plaster and paint over that fundamentally broken structure.


Right. Because the web is fundamentally a document delivery system that has, due to its easy interface and popularity, grown far from those roots.


I do wonder what would happen if modern adaptive development practices ("agile") were coupled with older high productivity dev platforms like Delphi. I suspect it'd be a good combination.


Disagree -- the web platform itself is pretty solid. Websites made decades ago are still accessible. The tooling that exists today will probably last much shorter.


Right. Apart from Flash, Java applets, and the old MS alternative. Those websites aren't accessible in practice, the technologies they're based on are dead or dying.


Those weren't accessible to begin with, not even back then :)


CSS preprocessors is something I don't want to get into (ex web dev jack of trades 5 legged pony): install gulp, node, npm, git pull, etc. just to build/compile a stylesheet ? Erk. So now I have to work around CSS hacks and the processing quirks, etc. /ranting


Delphi developer here - nice to be noticed :-)

Still thinking about moving to the fire monkey framework but no need to rush these things


As long as last year's darling framework ain't ExtJs...


Question: what's wrong with ExtJS. Granted, I haven't used it in several years and at the time found that it produced a lot of difficult to track down bugs, but at the same time it seemed like a reasonable choice for a certain type of app. If you need to build something that emulated a desktop app in the browser, say for an internal dashboard, why would Ext be a bad choice today?


The last time I used ExtJS was a few years ago, so it may have changed but: Its tables all the way down. Horrible html generated from a really clunky declarative library. If you only ever _just_ want to make a windows 2000 deskop-like experience for older browsers, than yes it is serviceable. Also very painful to extend / create custom work when you're dealing with that level of nesting. ExtJS solves an old problem that you very likely will not run in to today. Better to use modern-ish libraries and use SASS or LESS to get that good 'ol early 2000s desktop look.


ExtJS has two modes, modern mode is based on sencha touch and uses CSS-based layout, classic mode is based on the older ExtJS rendering model and uses tables for layout. You get a richer feature set in classic mode, but the end goal is to achieve parity and then phase it out.


They're a pretty isolated eco system, although it seems they're working to improve that. Right now they use their own ant-based build system, have their own ES6-incompatible class system and you're pretty far removed from HTML/CSS. So it's really hard to leverage "regular" JS frontend skills there.

Which might be fine if the system would work properly, as Ext would not directly compete with more "bare metal" component systems, but work as some kind of browser-based GUI DSL (which was what got a lot of people into it back in the days when DHTML was young).

Sadly, they seem more focused on introducing new features than fixing bugs or making all those elements work together (recent example: Conflict between new two-way binding and old statefulness of grid column sorting/order/filtering).

Mindshare isn't as good as with almost any other lib (some guy had the same problem you have with 6.2 with version 3.4, no solution ever posted), and due to it not being open source, there's not exactly a large community working on it, fixing things, adding new components etc.

And for all that, you have to pay a pretty stiff fee.


ExtJS was never the pretty/handsome prom date.


Backbone all day.


We pulled a Backbone app up out of storage along with some others. Then we wrote a few more versions in modern frameworks. It's an internal comparison app. Two things of note. 1) We always start from the Backbone app, it's the easiest to convert to other frameworks. 2) It ran right out of the box, no problems. No library muck and no fixes. That being said I did eventually move on to writing new stuff in Angular2x, but I stand by Backbone as good and reliable.


Literally this. It still does everything I need and not a thing more and is entirely grokable whilst being extendable. Amazing little piece of software.


Agreed here. Backbone is brilliant, and minimal.

Check out the annotated source here: http://backbonejs.org/docs/backbone.html


I trip out every time I look at the source of it and Underscore. There's nothing there, it's all so simple, it's like the bare minimum amount of code that can be there to do the things it does.


Backbone aka. Memory leaks as a service

Which is the reason Marionette exists in the first place (well that and boilerplate code).


If you create a bunch of stuff then don't dereference/unlink/whatever you want to call it in JS-land it you're going to have a bunch of references to stuff laying around. I don't fault Backbone for that.


Yeah, I cut my teeth on Backbone and I'm super glad for the experience. And as git-pull mentioned, the source code is nicely annotated (and concise), so it makes debugging easy.


Udacity teaches Knockout as their front-end framework in their Front-End Nanodegree. I would guess it's because it's extremely simple to learn (no Babel or anything) yet also very powerful in teaching code organization concepts (such as ViewModel).

It certainly isn't "modern," and doing anything remotely complicated will have you clawing at your eyes, but Udacity teaches it not as a framework to use, but as a framework to learn from. If I hadn't learned the basics of code organization by creating a simple app from Knockout, I'd be writing a _lot_ of logic in the render function of my React components (rather than computing them in a `mapStateToProps` selector), and I see a lot of beginner programmers do this.

Not to say that React is _bad_ for a beginner to learn, but it makes it very easy to do things the wrong way without letting you know it's wrong. With Knockout, you literally _can't_ put any logic in the View layer without it looking ugly, which is a beautiful pattern for a beginner.


> In my experience using last year's darling framework instead of this year's is an excellent way to go. The codebase is stable and full-featured, the plugin ecosystem is rich, the documentation is extensive, and stackoverflow is already filled with accepted answers.

I'm slowly coming round to the idea of committing to Angular for these reasons, just as HN commenters seem to be increasingly talking about React as the current Big Thing.


React and Angular1 are the same age :).


"When the goo is placed on a chair it becomes the chair..."

You are the Bruce Lee of Modern Javascript programming and I salute you.

https://vimeo.com/3191188


That was lovely, thanks for that. Made me chuckle.


I am a vb6 developer and I approve this message.


And if you hop on the new things too quickly rather than staying gelatinous, you may just end up with a text cursor consuming 13% CPU.


But at 60 fps, at least it's buttery smooth.


That was a pleasant read.

A version optimized for being read out loud would make for a very satisfying guided meditation audio.


> The trick to being successful with JavaScript is to

delegate.


"So what does the actual work?"

"Nothing. It's delegates all the way down."


That sounds like some really bad posture.


Yeah. It's just a matter of time before that disc at C6-C7 vertebrae slips a bit and you're in agonizing pain for months.


You should be a motivational speaker (or demotivational speaker); I already feel a lot of better about myself (well, I feel worse about myself, but am more comfortable with it).


"Hey! You can't do it. You don't have what it takes. But that's okay because there's plenty who do, so don't feel like you're letting anyone down."

How's my (de)motivational speaking?


...at my company they don't pay the non-performing goo-balls.

Whoo, look at this guy with the "performance" and the hoola hoops and transistor radios.


Well said! I wish I had discovered this truth few years before. In fact while it's especially true for JavaScript it's also true e.g. for Ruby ecosystem ~5 (?) years ago, with all the endless stream of test, factory, workers gems etc.


It took me far too long to realize this.


Me too. Found myself trying to work out a pattern behind it all, something on the edge of discovery but just too far out of reach... But then I decided to let javascript be javascript, and focus on the documentation of libraries to further my understanding, which in turn developed my understanding of JavaScript. Some things you just need to let go.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: