11–20 of 43 posts
As soon as he did that tab closed. But Im sure this is typical for js programmers who dont know anything, just make it up and expect us to fawn over your incompetency.
Some pretty strong opinions that contradict current trends in front-end world. I actually waited for someone to break the mould and start questioning the status quo. Especially regarding the use of DSLs and logic in templates.
I'm really interested how people here react to the "Picking your tools" part in the introduction. Some pretty strong opinions that contradict current trends in front-end world. I actually waited for someone to break the mould and start questioning the status quo. Especially regarding the use of DSLs and logic in templates.
Tools where you build the app by writing code in
JavaScript files, not by trying to declare too much of
your app logic in your HTML (no AngularJS, sorry).
The DOM is simply a view of the state and reacts to
changes in the model layer.
that said, this:
People who already know JavaScript should be able to
work on the app without lots of knowledge about a
specific tool or framework.
I'm really interested how people here react to the "Picking your tools" part in the introduction. Some pretty strong opinions that contradict current trends in front-end world. I actually waited for someone to break the mould and start questioning the status quo. Especially regarding the use of DSLs and logic in templates.
I've been using ExtJS since 2008, so I can give some experience here. What he says is absolutely true. The DSL of ExtJS does slow down ramp-up for new developers and requires an investment in learning the framework before you can use it.
However, I would like to point out there is a reason for the DSL. The DSL abstracts away the low level details of HTML so you can think at the level of ui elements. HTML's controls are very basic. Instead of comboboxes it has selects, which are quite inflexible. Instead of grids it has tables, which are also quite weak. The date field is minimal and in fact missing in older browsers. The list goes on and on. HTML is simply not rich enough to express desktop-level ui's elegantly. You can deal with that in two ways: embrace it and dumb down the ui (hence the trend towards minimal ui), or work around it and build a DSL on top of HTML. The core theory behind the rich DSL of ExtJS is that by bumping up the abstraction level developers can be more proficient. It is OO encapsulation at the UI level.
That is the theory. In practice it is a mixed bag. You have the same problem with ExtJS on top of HTML as you have with an ORM on top of a SQL db. You need to understand both what happens underneath and what the tool does on top of that. The cognitive load is higher, not lower. Some people thrive in that and are more proficient in the DSL than they would be in a raw templating view-driven environment. Others struggle with the larger amount of layers involved and are slowed down by the approach, and then some people fall in between and see no productivity difference. YMMV.
Update: one additional thing that I'd point out is that being opinionated and investing deep with a framework is not a bad thing when you're building a large long-lived codebase. If you're going to be living in a codebase for years, it makes sense to have as much application backbone (pun intended) as possible before you start building code on top of that. If you assemble a hodge-podge of smaller modules you're essentially constructing your own big framework anyway, so you might as well bite the bullet and choose a consistent one. The notion that you're ever going to switch js frameworks on a large single-page-app codebase is silly. The cost will always outweigh the benefits.
I've a question for HN on one of the opinions in this book: "use Browserify". There is only 1 single reason I don't currently use Browserify for client-side web apps: debugging. If Browserify turns all my files into one big file, all the time, and that's the only way, then how am I going to debug without going insane?
I know about source maps, but I use many compile-to-JS languages (TypeScript and React's JSX, in my case), and they provide source maps already. Afaik, Browserify doesn't re-map those source maps, or something like that.
Can I conclude that people who use Browserify simply never use compile-to-JS languages? Am I really forced to choose one of:
* Avoid Browserify (and similar tools)
* Write only vanilla JS
* Deal with having to in-browser-debug a single 20000 line JS file
* Finally spend time to contribute source map remapping to Browserify
I'm really interested how people here react to the "Picking your tools" part in the introduction. Some pretty strong opinions that contradict current trends in front-end world. I actually waited for someone to break the mould and start questioning the status quo. Especially regarding the use of DSLs and logic in templates.
Now I'm forced to use Angular and frankly, I'm frightened. There is no room for designing the architecture of my app - it's been taken care of - yet I'm still going to be held responsible for this architecture shortcomings, if I happen to stumble upon some of them.
Of course, codification of some conventions may be convenient and so I'm not against frameworks in general. But I know that sooner or later I will need an escape hatch to do something less than conventional and I want my framework to just get out of my way for a while. That's what Pyramid does and what Django starts to support in recent versions. I'm not yet familiar enough with them, but I suspect Angular, Ember and some others are not that great in this respect.
In short, while I never was very interested in front-end development, I did build some single-page apps, and I - after skimming a few chapters of this book - always worked similarly to what the author proposes. I really do hope that this approach will become dominant (once again, everything old becomes new again and all that), if for no other reason then because I just enjoy designing and writing in this style more.
[PS. It's nice to see you're still alive :)]
I really like opinionated books like these. I've a question for HN on one of the opinions in this book: "use Browserify". There is only 1 single reason I don't currently use Browserify for client-side web apps: debugging. If Browserify turns all my files into one big file, all the time, and that's the only way, then how am I going to debug without going insane? I know about source maps, but I use many compile-to-JS l…
I really like opinionated books like these. I've a question for HN on one of the opinions in this book: "use Browserify". There is only 1 single reason I don't currently use Browserify for client-side web apps: debugging. If Browserify turns all my files into one big file, all the time, and that's the only way, then how am I going to debug without going insane? I know about source maps, but I use many compile-to-JS l…
Just pass {debug: true} to build function.
I really like opinionated books like these. I've a question for HN on one of the opinions in this book: "use Browserify". There is only 1 single reason I don't currently use Browserify for client-side web apps: debugging. If Browserify turns all my files into one big file, all the time, and that's the only way, then how am I going to debug without going insane? I know about source maps, but I use many compile-to-JS l…
I'm not sure if there's something different about TS and React but I'd imagine if they have source map support it should work similarly?