I wonder how many are like me (old school? Just old??) and eschew platforms and libraries and roll my own most of the time, because most of the time, the needs are simple, and it's quicker to pound something out rather than learn and use Yet Another Framework. Though using jquery is nice sometimes...
That's the approach I took to hand-rolling my personal website. All I care about is delivering my content reasonably well -- the elegance or modernity of the underlying engineering seems irrelevant. (Not to mention that this minimizes website bloat...)
I do that. Web dev is not my main focus, but I have to deal with it all the time. I try to attack the problems with an initial prototype that's a combination of plain HTML+JS and Node.js. Instead of a database, I tend to reuse a simple Javascript class I wrote a couple of years back that provides a minimalist layer of persistence for collections using an append-only file. (It's really just a single file I copy to any new projects when it's time to store something.)
Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it.
So far I haven't regretted not investing time into learning Framework X every few years... Although I'm probably going to start deploying React instead of plain JS soon. The library is very useful for real-world UI problems, even though it's surrounded by a deafening amount of toolchain fetishism which tends to cloud React's fundamental simplicity.
(I'm 36, started writing C in 1990 and HTML in 1995, so I feel somewhat old in this industry already.)
I recommend avoiding React. I have never seen an ecosystem so bogged down at every turn. It also has a bad zealot problem, where Facebook has cleverly brought a lot of people to it who haven't seen anything else and are convinced it is the bee's knees.
> The library is very useful for (?) UI problems...
Components are good. But they didn't come from React and React isn't the only place to get them. Angular 1/2, Polymer, Ember are great in comparison. And so much more simple. React's position on simplicity is that the demos on the site are all 15 lines so that means it's simple right? You can't say it's complicated because it's 15 lines, see? It's "easy to reason about", i.e., "you're not smart if you don't get it".
Once you see the toolchain and ecosystem you will glimpse the price of those 15 lines.
> ...toolchain fetishism which tends to cloud React's fundamental simplicity
This is a very real thing. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
I frankly don't see how you could come to the conclusion that Angular 2 components are simpler than React components.
I mean, in React, a component can be as simple as
const MyComponent = () => <span> some markup nonsense </span>;
Yup that's the argument mentioned: React is "simpler", "anyone can see"...
Brevity isn't simplicity. The simplicity is being easier to install, build, read about, debug, consume APIs with, send data between, talk about to other developers... and yes, "reason" about.
myMod.component('Foo', {
template: '<h1>{{$and.better.templating}} {{see()}}</h1>',
controller: function() {
var and = {this_one: 'does_stuff'};
}
});
This is not easier to reason about than returning jsx IMO... It's only 1 of the ways to build an angular 2 component. The website tutorial is using decorator syntax. Typescript Angular 2 documentation. What's wrong with just learning JavaScript and less Angular specific syntax and tooling.
Maybe I'm wrong but I feel like Angular likes to force projects to become big monoliths where people who don't understand the problem being solved are trying to architect a solution for all of the problems.
React does have jsx shock and JavaScript tooling fatigue. However, now that React is mature JavaScript tooling decision fatigue should be less of an issue. You aren't relying on one company to solve problems. You have a community solving problems for themselves. As they need it they can add it or take it away.
I recommend avoiding React. I have never seen an ecosystem so bogged down at every turn.
It's perfectly possible to just use React on its own, without getting bogged down with all the other buzzword-of-the-week stuff around it.
React itself has been reasonably stable for a long time in Web terms. It is much more tightly scoped and smaller in its interface than most JS frameworks. There are a couple of major design trade-offs, which often seem to get overlooked in React advocacy, but if you have a bit of experience using it and understand the practical pros and cons then you can quickly decide whether the balance is favourable for some new project.
People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
Some people who work with React might. Plenty of others don't.
React is great. But the tooling around it tends to complicate things a lot. Just for example react-redux (not just redux).
When I first started with React, it felt awesome - just React still feels great. But I had just started then and then got introduced to redux (I had been using something similar custom built). That was good too, until I learnt react-redux. I get the concepts, I understand every bit of it and have used it correctly in many large apps - it is useful. But react-redux just feels awkward many times and I consistently feel something is wrong with it - but I don't know what. React-Redux just feels disconnected with the idea of independent web-components.
On a side note - If one is okay moving to Typescript, Angular2 is just amazing.
I find the Redux ecosystem to be one of those areas that sounds great in theory, but that in practice has quite a narrow range where it's a good fit. If the web app's data model is simple enough, it can easily keep track of mutable state directly and just rerender everything on any relevant change with acceptable performance. If the model is complicated enough, the simple data stores provided by Redux and the like lack power and flexibility until you build a lot of other architecture around them, at which point you might well be better off building something catering to your project's exact needs anyway. I can see that there might be a happy zone somewhere in between, where building with tools like Redux and its surrounding ecosystem does pay off, but I've yet to work on such a project myself.
Polymer while I used to like it more isn't better than Web Components and for me was harder to use than both React and Web Components. React offers up more than both Polymer and Web Components spec. With web components it's still just a glop of JavaScript in a file. So I don't quite see the benefit of being "closer to the metal" when you are not closer to the metal. The community simply hasn't embraced Polymer. React is easy for me to understand and I can use it today and Web Components aren't really a necessity at that point nor are they even supported in browsers yet.
"Over 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it."
You might want to spend some introspection time on that statement.
> eschew platforms and libraries and roll my own most of the time
That's what nearly everybody does, when they're one person hacking on a one-off project.
I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code.
Thing is, complex frameworks like Angular tend to allow for 20 different ways to accomplish the same thing, so they don't really solve the underlying problem: team members still need to agree on a common approach and a shared set of idioms and coding styles.
There is a difference though. When there's a big framework involved, discussion will tend towards "Is this the right way to do X in Angular?" rather than "How do we want to solve X?". That may be good or bad, depending on whether you want to build your career around being an "Angular expert" (or a "Rails expert" or "SAP expert" or "COBOL/IMS expert" or any other kind of framework expert).
I don't like Angular 1.xxx that much because in Angular 1.xxx building simple stuff in JavaScript is a no no. Angular doesn't play nicely with JavaScript. Instead you have to do Angularjs way and write the Angular specific code in your 50 Angular specific HTML attributes. Performance of data intensive apps is particularly lousy in Angular. In my opinion it's a framework written for people who like complexity for complexity's sake.
I don't want to be hunting all over my code base just to figure out what is happening in a controller or component.
I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code.
Or we could just adopt good coding standards and build with reasonable software architecture. That's been working for longer than anything like the modern Web has existed, to build software orders of magnitude larger than any web app by any useful metric I can imagine, without the need to resort to huge frameworks to keep growing code bases organised and consistent.
The thing is, producing good software at any serious scale and maintaining it for any serious length of time needs more skill and understanding than you can learn from a 10 minute tutorial video and a couple of blog posts.
There seems to be a new generation of developers who think that 10,000 lines of code is a big program, a web app doesn't need to last more than a year or maybe two at most, and any sort of in-house programming or software design work will be inherently inferior to any external code you can import instead. These people are probably doomed no matter what they do.
There's a certain irony that in the one clear exception to that rule -- if you really are building a throwaway MVP in the expectation that it will either fail quickly or succeed enough be be worth rewriting properly later -- it mostly doesn't matter what tools or practices you follow. As long as you have some basic competence regarding security and you're keeping any important data somewhere safe so it can be transferred reliably to a new system later, the strategy is what it is. However, that also means many of the claimed advantages of frameworks are irrelevant to such projects, because you don't really care about things like longevity or being able to hire more developers already familiar with the framework or keeping growing teams consistent in how they design a growing code base.
> There seems to be a new generation of developers who think that 10,000 lines of code is a big program
This one made my day xD
10kLOC is a top limit for my programs (I say that whatever has higher line
count starts boring me), and those were just small tools for sysadmins since
forever.
Big Web Frameworks aren't there to "keep code bases organized and consistent", they're there to do stuff like render state changes into a complicated DOM without causing jank, without FOUCs, without crashing IE9, etc. Those aren't problems that "adopting good coding standards" can solve.
Web frameworks have architecture to them, but their value lies in solving technical problems, not architectural ones.
Big Web Frameworks aren't there to "keep code bases organized and consistent", they're there to do stuff like render state changes into a complicated DOM without causing jank, without FOUCs, without crashing IE9, etc. Those aren't problems that "adopting good coding standards" can solve.
I respectfully disagree. You don't need a framework to do any of those things.
I do a lot of work with relatively complicated browser-based UIs. In my experience, the DOM/layout thrashing and jank issues that have been getting a lot of attention lately only became a big deal in the first place because the early frameworks were so horrifically slow compared to just doing manual updates of exactly what you needed to change. Even in the most demanding applications -- and not many web apps actually are this demanding -- you could achieve pleasant, smooth results with some modest attention to how you applied updates so you didn't cause the browser to regenerate layout unnecessarily. (This would be an example of a useful coding standard, BTW.)
Flashes of unstyled content/text/whatever are a symptom of serving web pages in chunks and how browsers render incrementally as more of the chunks are available. Again, dealing with these effects just requires some understanding of what causes them and a little care in how your site/app is served and does its initial setup. The frameworks don't do anything magic that you can't do in your own code.
And finally, we were solving cross-browser portability problems with script repositories and then libraries like jQuery a long time before any of the modern frameworks were on the scene, and in a much more varied environment in the early days. IE has certainly had its issues over the years, but for the most part at least the issues were well known and you could just work around them. And again, there weren't really that many horrible issues, and this was an area where having some basic coding standards worked OK even if for some reason you didn't want to just use one of the many utility libraries.
It's not so much a change in technology as it is a shift in focus.
If you or your company needs a basic website, then wordpress will almost always take you as far as you need to go. There's not a huge need for devs and nobody who's good at the web wants to be there because it's a race to the bottom financially. That part of the web (the overwhelming majority I might add) is pretty stagnant with few real changes or advancements having happened in the past decade.
Apps failed in that nobody wants to install your app on their device unless it's a game, a free utility, or one of a few popular apps made by large companies. WebOS got the idea of web technologies right, but the devices were too limited. Today, the idea of a web app that runs everywhere is very appealing and much more accessible to clients. All the new frameworks are really targeting this kind of use. Pounding the square that is web apps through the round hole that is the browser is hard, but still better than the alternatives.
If you're making a website, jQuery and simple JS is usually all you need. If you're making a web app with complex data and complex UI, you need a framework to keep things sane.
Web app with complex data = website that can be done very well with html, css and a server-side language.
It's only the complex UI which requires JS frameworks and libraries, but building such a UI is already a losing proposition and the main reason why web programming is getting "unnecessarily complicated".
Web developers think that web apps can compete with native applications - they still can't and in the process of trying to get them there, they turned the process of building websites into a mess.
Web app with complex data = website that can be done very well with html, css and a server-side language.
Only if you make a baseless assumption about the user's internet connection. Someone whose connection drops out regularly, or who faces periods without a connection at all, is going to hate your server-side app compared to my offline-first progressive web app that they can have cached on their device and that syncs their changes using pouchdb/couchdb.
My app will have a ton of JS that yours doesn't, but that extra code makes it work when they're not online. That's a huge advantage.
Not all progress is designed for added shininess. Some of the changes that are happening are designed to fix real problems that people face.
What work is required to make an app fulfill it's need is mostly very similar regardless of what delivery mechanism you use to get it to the user. Native has a few advantages (performance, build tools, layout libraries, etc), but if all you need is available on a web app platform and the performance is good enough then a web app can still be a very good choice, namely because the code assets easily can be shared with other web offerings and there's vastly more available developers to do the job so hiring someone to write it is much, much easier (assuming you're not outsourcing it).
There are a lot of things that you have to do regardless of how the app is delivered - you need to work out what the app actually needs to do, you need to design the business logic, you need to design the look and feel, you need to get the UX right, you have to throughly test it. On a decent size app, the job of actually writing the code is about 25% of the work required. In my opinion, something that represents a quarter of the project probably shouldn't drive the entire process.
The apis and libraries for an offline app are very different to an online one. If you build an offline app as a html/js app then good like finding libraries for common tasks, like file system access.
I keep seeing this use case of JS heavy web apps but have yet to come across one in production that adds any value when offline. Can you provide an example?
I think that when one is developing a web-based product, a working internet connection is a very reasonable assumption.
If that's not the case, it's pointless to create a web-based product. Just offer the full thing as an app and a simple web UI.
I looked at the WaPo link that you posted and it seems to be exactly this type of product with an identity crysis - my browser already allows me to save pages for later reading and if that won't work, there are a multitude of offline reading apps to choose from, I don't need a WaPo "progressively enhanced" app for that.
There are many web apps that make zero sense to write a native app for. For example, my company's product is an LMS - the administrator side is not something that makes much sense to make a mobile app for iOS and Android, as one has to create/manage courses, manage users, and view useful displays of data (i.e. charts). Instead, we have a web app that degrades acceptably for mobile, losing such features as multiple selections for modification (it has a lot of grids).
For such an app, having a longer load upfront in order to facilitate vastly better UX than using purely server-side rendered pages is a huge win for our customers, and having the time to load & interact being low also adds tremendous value to the customers, to the point that they flock to us over our competitors.
I don't find myself having a problem with frontend web app architecture - most of the problems out there are already solved or solvable with a little time spent on thought, but the knowledge is not widespread, and so we have a lot of people who have never seen what good structure looks like.
I don't know what's best for your customers, I assume the company did usability studies and drew conclusions from that.
There's always cases where it makes sense to make use of particular technologies. It absolutely does not make sense to transform most websites into web apps that are completely broken without JavaScript, which is what's happening right now.
wow this attitude is so sad! React + Redux - changed my whole outlook on web development and it's actually a joy again. Take a little bit of time, read, learn, figure out a simple webpack script, and you're gonna love life.
Most of the web stuff I have to work on is developed once, and then maintained rarely (once a year or so). It's not the kind of project that has continuous development. So whenever I've used a framework or SDK, when it comes time to add a small feature or tweak, I spend more time bringing the project up to date with the latest version of the framework or SDK than I do implementing the feature.
Literally every time I update one of our sites using a Facebook SDK, they've changed around how the whole SDK is designed and I have to rewrite basic things like session management.
I think there's a lot of social pressure from rockstar web developers to build and use JS libraries and frameworks.
Let's face it, classic front-end web development works fine and is well understood. Doesn't get you into conferences or help you sell courses.
So we get the web of today, piles of Javascript and unnecessary complexity all wrapped together with ads and tracking. And excuses about how today's customers expect an app-like experience.
I'm still sort of a newbie but I have found it much much easier for me to quickly build my projects on the very very easy to use Web2py Python framework. The things I like are: defining my DB structure in simple code, no routing (routing is implied by file & function names), Python, HTML views with simple embedded code (including full Python if need/want).
We need to remind ourselves frequently that the web is a terrible platform. Yes, TCP/IP changed the world, but the web is an embarrassment to our field. It could be so much more.
Well yes and no. Javascript problems are what php used to solve before. Its actually necessarilly complicated if you view it from what javascript is attempting to replace.
On top of replacement, theres another question "is the common road the best road?". Something as simple as a html5 video tag can be replicated through a canvas, html5 audio and some ui elements. And as things get more complicated, are we better off pretending complexity is the enemy?
The reality is that these are problems all languages have to deal with. The reason the web is getting the most is because its the most widely consumed abd provided. Why be involved in an ecosystem dominated by coorperate entities that would only pay you just enough so you wont leave when you can be in an environment where insanity is an acceptable road to sanity. Why the hell does coffee script exist? It doesnt matter.
Clientside code execution makes sense. Every last thing that can be offloaded to the client should be. The tooling around this concept may be insufficient or difficult to use, but the underlying premise is undeniably sound.
Not necessarily. The client device may be old, underpowered, slow, and running out of battery. Which isn't to say thick clients are always a bad idea, but they're not the One True Answer™.
Hah I rushed that answer but yes totally agree. When I'm dev'ing for web, I always monitor perf against a crappy old Android phone. Similarly, Chrome devtools makes it easy to simulate a bad network connection. I try to make sure it's tolerable.
Also worth noting that analytics makes it easy to determine what device/OS the majority of your visitors are using. Anyone building an app would be wise to pay close attention to this to guide dev efforts.
Food production is complicated because of scale. But food itself hasn't changed much in centuries. The only real difference is that all the world's spices are available to common folk in Nowhere, TX.
Fine cooking is a combination of simple things. You meld together a sequence of simple tasks that result in a complex recipe, but we still do the basics of cooking that our "caveman" ancestors did. When the simple things become unnecessarily complex, it prevents us from creating a good recipe. We get so caught up in the unnecessarily complex details that we lose site of the goal.
Not sure about that. i just need to twist a know in my kitchen and i get easy controllable heat. I can go down to the supermarket and buy a steak rather than having to go out and hunt and butcher it.
As a novice developer, coming from Java, I was taken aback by how forceful and messy JS's async programming style is (I started with node.js then moved to the browser).
Callbacks, promises, generators are all there to essentially make async code sync, which seems to make the code hard to follow, difficult to scale, modularise and debug.
I think JS took this approach because of the limitation of older browsers, which were unable to use threading, so as to not block IO they forced concurrency using queues requiring async style code.
We must have just stuck with it because it's just been around for long enough and it would be hard to get everyone to change.
it's 2016 and I like being able to use the return values of my methods without sweating. PLEASE, for the love of god, replace JS with something with the same cushy syntax but makes sense.
Then again, I could just be bad at programming and not know what I am talking about - I sincerely hope that is the case.
This kind of hits one of the problems with JS on the head. There are too many different ways to do things, at all levels of abstraction, because it was such a limited, dumpster-fire of a language for so long, implemented in so many mutually incompatible ways by every different version of every browser, and so to do anything much more complicated than wiring up some basic callbacks on a page, you had to roll big chunks of infrastructure that better designed and more mature languages built in. So you end up with a half-dozen different patterns for object-oriented programming, another half dozen patterns for making async code less awful, three or four different patters for defining modules, etc, ad nauseum.
> Callbacks, promises, generators are all there to essentially make async code sync
I think they actually do quite the opposite: they keep async code async. JavaScript doesn't really have a (non-terrible) way to make async code sync.
Note that I'm assuming that by "being able to use return values of my methods without sweating," you mean "get the thing I want out of the return type somehow." Or, in other words, things like getting a value out of a Future. The problem with that approach is that it blocks the calling thread, so what happens if you have 50 connections? Or 200? Or 10,000?
The same reason I like that JavaScript and JavaScript libraries try very hard to keep things asynchronous is the same reason highly concurrent software tends to be event based rather than thread based: it's simply more efficient.
I think it can be a challenge to keep mental track of state in JavaScript due to the nature of async stuff, but it can also be liberating in a way once you figure out the right way to pack away your state for whatever problem your working on. It makes it easy to break things into small components and reason about pieces instead of the whole while maintaining decent efficiency compared to having tons of threads around.
There's also of course the incredible niceness of JavaScript being single threaded in that typical multithreading concerns are not a problem. If you want to update a variable in some callback, you just do it. You don't have to worry about locking or atomicity, etc. I can't tell you how many times I've ended up with a mess of Java code in which I'm not actually sure if it's correct or not. That's likely my fault, but still something I enjoy getting to not think about when doing JS.
In short, I suppose it just comes down to different preferences. I often find myself working on concurrency in Java and wishing that it were more like JavaScript :). Interesting, the JavaScript approach can be pretty easily recreated in Java (and sometimes a very useful tool), but the Java approach is much harder to do in JS, at least with Node.
I like this website to layout an argument nicely. But in the case Web Programming is not well-defined, the argument can just be people doing different things assuming others are doing the same.
Web programming is reaching not only far more people, but far more combinations of people and devices, in far more scenarios -- think of how many more ways you can do computing that don't involve sitting in front of a desktop, which for most non-technical people was a relative rarity in day to day life.
So web programming should be more complicated because the world we now reach is far more complicated. But I don't feel like complexity has grown nearly as much as potential audience. And when things do get frustrating, such as trying to do a heavy client-side app, I just have to look at the PHP Reddit/stack overflow groups to get a reminder of how truly fucking annoying and confusing it was to build a full stack app a decade ago.
I'm up-voting this purely due to finding out about arguman. I had an idea for a website exactly like this about 6 years ago. Kudos to the people who actually implemented it.
Boo hoo. It's not that bad. Knuckle down and learn some shit. Crikey, some of us learned this stuff before a crowd sourced 90,000 word wiki and versioned online code repository was commonplace for a 200 line library. AND get off my lawn!!
There are a few version up there: one has a router, one has a firebase backend, one has Virtual Reality bindings. They all have the same purpose: to get out of your way as fast as possible.
Web development is still that simple if you want it to be. Nothing is stopping you from writing for the web like it's 1991 if that's all you feel is necessary for your site.
While I agree that a genuinely static site should be written as such, I'm not writing websites that were possible in 1991, and I don't see why I should have to, to get simplicity and productivity: we've come a long way since then.
So, I did a little bit of work to simplify my set up(s) and then to make it useful to others.
I'm not making a normative claim, my only point was that the same technology that worked 20 years ago still works today and it's the developer's fault if they don't like the tools they've chosen to use.
Well sure, but while I agree that the length and breadth of the toolchain has become stupidly long, the demands of today aren't the demands of yesterday. Take my VR boilerplate, for an extreme example: what are you supposed to use instead, VRML? :)
Unfortunately the web development profession has decided to shoot itself in the face and make framework-oriented development mandatory. I mean sure, one can still build sane web projects, just don't expect to be able to get a job doing that and do expect to be mocked as some sort of luddite.
I am sort of curious if this pile of complexity will at some point implode, but mostly I am happy that I got out of webdev when I did. Today's web development is making a mockery of the ideas of usability, accessibility and standards.
I mean sure, one can still build sane web projects, just don't expect to be able to get a job doing that and do expect to be mocked as some sort of luddite.
When we build web apps for clients, they generally don't care what tools we use as long as the results are good. There's still plenty of work out there like this and there are still plenty of success stories.
You just have to avoid the parts of the industry, particularly around the startup scene, where most developers have just a few years of experience and are heavily influenced by high profile online commentary. That type of business tends to hire buzzword-compliant people because even their own "senior" developers don't have enough experience to know any better.
You just have to avoid the parts of the industry, particularly around the startup scene, where most developers have just a few years of experience and are heavily influenced by high profile online commentary.
>Unfortunately the web development profession has decided to shoot itself in the face and make framework-oriented development mandatory
Frameworks are commonly used across many programming industries. It's also not any framework's fault that the PM (or you) chose the wrong framework.
>just don't expect to be able to get a job doing that and do expect to be mocked as some sort of luddite.
I've never heard anyone mocked as a luddite for using the simplest solution necessary to meet requirements, that sounds like something programmer's are complimented for (if they can show results). If you want a job where the employer uses a trendy framework... just learn the framework; it's either that or learn the company's hand-rolled framework, at least with a trendy framework you're also investing in potential future prospects.
It's not a jab or a judgement, it's a statement of fact to illustrate the point that technology from 1991 still works perfectly fine today and that nothing about today's technology prevents you from using technology from 1991 or any time if that is the best solution for your project.
For publishers of content plain html and some little css would get you a result that's readable, and responsive (I think a better word for this is adaptive), if the authors are willing to give up their prescriptivisism on the rendering of their content. Compliant use of html and css almost always results in a page which the browser will know to display the best way with regards to the medium. But once one's determined to impose a certain layout no matter what, he takes on the browsers duty, and actually has to work towards implementing an abstraction layer that takes care of the incompatibilities of all different web browsers out there. Now there are libraries for this, so he fetches and uses them to unnecessarily impose his style. Eventually this is a needless burden on both him and the user, as while the megabytes pile up, load speed and performance decrease and Internet bills increase in price. As things skip and grow and shrink on the screen, the UX becomes cumbersome too. But if the primitives of html and css are used, all these issues are irrelevant.
Another factor that complicates web page development is ads. They bring a huge pile of Javascript with them, but they go ignored most of the time and usually are a burden to the user. Ad providers, instead of publishing ads that would indeed get clicked intentionally (like the Deck network), bribe the publishers paying for user actions that aren't actual impressions. Thus they also create exaggerated statistics which they use to lure low quality ads which get the most clicks from accidental behaviour, leading to worse and worse ads that do whatever to catch attention but be actually interesting.
Lastly, it is a fact that coding Javascript is more fun than writing a document. For the web developer, rendering innyeractive graphics with Javascript is certainly more fun than making them with R or gnuplot and insert into the page with an img tag and providing data and code used to generate them.
When it becomes easier for a site to write native iOS and Android apps for clients than it is to write a pretty JS front-end that works on all browsers, it's going to be bye-bye web as we know it.
Except for the fact that installing apps is an unnecessarily annoying process, enough to mean that the majority of people very rarely install anything new on their devices.
Tap link, opens App Store, tap to install, wants me to login but I can't switch to 1Password without cancelling and starting again, enter password, agree to something about TouchID, T&Cs have changed so have to acknowledge them yet again. App installs to earliest screen that has a vacancy, so have to go through and find it.
It's funny how everyone seems to hate "big frameworks" while at the same time complaining about how "everyone uses them". It's sort of like the Yogi Berra line: "Nobody goes there anymore. It's too crowded."
I for one will go against the flow (or am I with the flow?) and say that what I see coming out of Angular 2 looks FANTASTIC. Many of the things I love as a Scala developer are finally becoming mainstream on the client side. Add in the promise of NativeScript (mobile apps) and Electron (desktop apps) and this is an incredible time to be a web developer.
Tbqh what is coming out of Angular 2 is React with a higher learning curve, more Angular specific syntax and not much in terms of a larger benefit. React keeps things simple and easy to reason about. I don't feel like I should need or be using decorator like syntax at all to create a component. I like looking at one file and knowing exactly what that one file is doing but that's just me.
This arguman thing is really cool! It's such a neat idea in fact, that I'm willing to overlook the horizontal scrolling. That's saying a lot!
With that out of the way... I'm firmly in the "but" camp here. I've been doing web programming for 17 years now. I remember the bad old days. Things were simple if all you wanted was HTML and images (CSS was still pretty iffy). But the moment you needed more than a static page? The complexity of getting up and running ballooned really quickly. And worst of all there were so few resources to really learn from. And it was expensive. Granted I was a teenager back then so anything more than a few dollars a month was pricey to me, but if you compare the kinds of hosting offerings of two decades ago to something like Digital Ocean or AWS today then the amount of possibilities is staggering (no more shared environment!) and for prices that are almost too cheap to believe.
My recollection of getting anything up and running that used a database back then was that it was not for the faint of heart. Compare that to today and the process of getting everything set up and connected with Rails, Djano, Express, etc. Yes there's more stuff you "just have to know" in terms of code you write and yes you have a box you have to stay within because of the framework but I'll take that any day over gluing together some Perl scripts and hoping you've got CGI configured correctly.
Maybe I'm conflating two separate things here: actual programming and operations. But I strongly contend that with web programming you can't disentangle those two things in any practical way. You will always be bound to the context of your environment. Anything that makes getting a sane environment easier leaves much more time to focus on the problem you actually care about. And it's not like you have to use all of the shiny new toys if you want to keep your code simple.
The server code has way less problems than the UI part of websites (i.e. web pages). The complexity of putting up a webpage has made a very fast 0-60, where it now may involve several package managers, JS libraries, to-CSS compilers, multiple web browsers (multiple OS' if you want all of them), minifiers, uglifiers, build programs and whatnot. And most web pages from popular online publishers (news portals like the New York Times, blogs like the Huffington Post, etc.) the ratio of content to CSS, JS, and HTML tags goes towards 1/1000 and above. Most of the time features of browser are reimplemented (history, page loading, scrolling...) and standard behaviours hijacked (most often scrolling, clicks). Every website designs and imposes it's own UI paradigm so that clicking around becomes a frightening and challenging thing, as telling what is a link, what is a button, what is a drop-down, etc. is hard, as either these are heavily styled to the point of being unrecognisable or they are reimplemented in JS and the behaviour is unpredictable. This hurts especially when doing critical things like money transactions, various registrations that have become online recently, various rendez-vous, etc. Together with this trends, HTML, CSS, and JS get more and more complex in the specification level, which together with cancrous tooling, make entry to web development (i.e. writing webpages or writing programs that write webpages) harder and harder.
In my early days of programming, things began with realizing that I could use this wonderfully powerful system to solve problems (almost any problem you could model!) and create things (almost anything you could want to simulate!). I just had to figure out how to model the domain problem logically in a useful way, or what aspects of something to simulate, and how to allow the user to interact with it.
That soon changed. In learning about programming, one can't help but to come across the writings of those preaching the gospel of the holy virtues of 'reusable code'. Modular code, libraries, object-oriented code, design patterns, frameworks, plugins, APIs, services, stacks and toolchains!
So programming is now largely about resolving a ton of dependency issues and getting scores of different modules, frameworks, libraries, APIs, etc. to play nicely with each other. Instead of using our brainpower to understand and model the domain problems that are ostensibly the reason for our software, we're using it trying to figure out how the heck to glom together all this generic abstract code and modify the output to vaguely resemble something in the domain, in a way that won't perform so horrendously that customers immediately give up on it.
We write hooks, overrides, and underrides to throw out the work that the reusable code is doing and get it to do what we want (more-or-less). We write translation and adaptation and bridge layers to convert the data structures used by one module to those used by another (and vice-versa) and eventually to something roughly approximating the domain data. We set up elaborate clusters of interdependent modules, submodules, plugins for our plugins, all on top of a generic framework that wasn't even designed with the domain in mind.
As a profession, we've gone way too overboard trying to do everything with reusable code. This is why it can take several hours to do something as simple as change a link (and that can completely break something seemingly-unrelated elsewhere in the system). And it's kind of amusing that we're now adding layers of complexity to manage the layers of complexity.
I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things. For that we need a new doctrine of vertical development that doesn't just religiously say "Throw another layer of indirection and generic abstraction on it! Yay reusable code!" as a sacred solution for everything. Sure, code reuse can be good, but let's be sensible about it, not kid-in-a-candy-store crazy.
I started out doing that. And inevitably I'd wind up refactoring multiple similar projects into reusable code and conventions. Over many years I arrived at this:
Now I can assemble a website that works everywhere and has best practices, by expressing exactly what I want in high level code. When modeling a new app or talking to our developers about architecture, we can use a common language of users, communities, streams, access, realtime pushes and offline notifications etc. People know what I mean when I say "the Patients/account streams should be published by the community and have Patients/photo stream templates for the admin role, related to Patients/gallery category stream published by the logged-in user."
Everything is namespaced, reusable, interoperable and works on every device. It took a long time to make the system but now we can assemble apps like out of building blocks, and have anyone work on anything and know what the conventions are. So yeah, it's paid off!!
When I go to the qbix website, and click on the "for Developers" link, nothing happens. Possibly something would happen if I played with my NoScript options.
Now I have some choices: allow javascript in order to read plain text, or ignore your web framework.
Don't use it if you don't want. We built it for ourselves and it's available to you if you want to use it. If you don't want to turn on Javascript to get started with the platform, that's up to you.
Reusable code, frameworks or plugins are fine, the problem is their cambrian explosion since now anyone can jump in and publish some JavaScript or Go code, especially with the micro-stuff trend. So we end up with zillions of projects competing for traction, and we move from one new cool and shiny thing to the next, for all (micro-)components of the stack.
This is the often-forgotten cost of competition (for all its merits) as opposed to cooperation: it wastes time and energy.
> , the problem is their cambrian explosion since now anyone can jump in and publish some JavaScript or Go code, especially with the micro-stuff trend
I do not buy that this is a problem. It's not an apples-to-apples comparison, but anyone can publish a 'book' on Amazon as easily as publishing an NPM module (and they do), however, no one is complaining that there are "too many low quality books". Why is it easy to ignore books but harder to ignore shitty projects? Similarly there are countless instances of bad poetry online, and very bad fan-fiction, but the sky isn't falling in the literary world. Can someone educate me: why do other people's shitty software projects elicit such strong reactions?
Because books and poetry aren't supported by package managers. They're self-contained, so you can ignore them and no one cares.
They also don't purport to solve a specific problem. (Like left-pad.)
And they're not boosted by a FOSS ideology which their existence a political choice and not just a practical issue.
So basically interdependence. You need at least some external code to finish most projects, and the chances are good it will be somewhere between overcomplicated, unreliable, poorly documented, poorly maintained, and unnecessary.
Maybe package managers need active best-of-breed curation and industry-wide coding and documentation standards. But professional standards are anathema to the move-fast-and-break-things crowd, so I doubt that will ever happen.
I'm not sure how useful analogies are in this case, even so I get pretty upset over a lot of popular poor quality business books (and similar) that have real impact on things.
If you want to make a comparison you can equate things to hardware where things like quality control and yield is instrumental. If you buy a plastic case that after a year self-disintegrates because while it looked the same it wasn't manufactured to spec. When this could potentially happen to every part of your device this quickly becomes annoying.
Yet, this is how software is all the time and is further worsened by a lack of due diligence and quality control. How many developers can get the time to properly verify a technology or library. Not to speak of if it's even fair to expect developers to be able to reach those conclusions.
The aim of reusable parts was to make software components behave like electronic components: purchasable from vendors, standardised, interchangeable, can be fitted together without conflicts. Nobody would consider replacing a NE555 or op-amp with its discrete transistor equivalent.
It sort of succeeded, but only at the data structure layer. Perhaps the high point of reuse is npm-style dependency-orientated programming, where people really do reuse tiny functions like leftpad(). But it's not stable. Because nobody is interested in providing that stability, and there's no money in it. There can't possibly be, because nobody will pay for tiny software components like leftpad. The market doesn't exist.
You can't second-source leftpad(), and that makes it possible for one person to break a lot of random builds across the world.
You are correct. I've come to see it as one of many psychological responses of developers to work they feel is beneath their skillset. People with advanced computer science backgrounds often end up in web development just that's where the jobs are, and most of the work is not in solving difficult problems. Mostly, you are just pulling data out of a database and displaying it in HTML. The thought of doing that for your entire career as a programmer is intolerable to some people, so they concoct any ingenious scheme they can to rise above it. For some people, this results in an obsession with writing modular code they can re-use. Another response is to delve into obscure, hyper-intellectual programming languages. Another is to become obsessed with markers of system robustness like availability and concurrency to the point where all of your decisions as a programmer optimize for those. I've seen all of these (and been guilty of some of them).
The interesting bit is that these people are often very eloquent and convincing in making others believe that they have an objectively better way to program, and that this is THE way to advance in the field, and not just some elaborate game created to stave off boredom. Never mind the fact that you're still just doing things like validating phone numbers and moving buttons slightly to the right. This is nothing less than the future of computer science!
So you end up with a herd effect where greener or less-capable developers follow these "thought leaders" blindly, resulting in the fragmentation we're in now. I find it interesting how "Five Whys" has made its way into dev culture as a line of questioning for business requirements, but never for tech requirements. "It's getting more and more popular every day," or, "It's going to look great on your resume," is often the end of the discussion.
Let me tell you a story. When I do frontend nowadays, I mostly develop with angular js. People like to complain about angular and having to know so many libraries, and frameworks, when the past was simple.
But what is simple, really? Let's look at some past experiences:
1. At a very first gig, when I was doing my very little first steps in this software thing, I had to build a website prototype. Pure static html pages inside a folder, that were linked to each other, didn't need to deploy, it was just a demo. It didn't use CSS. It didn't use a template engine. Really simple. But, every change was a PITA, because the website had a header, so every change, meant you had to open the file, and rewrite the whole header... in all files, manually!
2. In another moment of my past, I had to do some changes in an app was built with JQuery. JQuery is a library, but it's pretty simple. Select dom elements, and apply changes and hook events up. Simple.
Only, following and understanding the flow of the app was hard as hell. Each page had a lot of code and it wasn't obvious at all what was happening. Complex transformations of the dom were daunting. Small changes would break in intractable ways.
3. PL/SQL Stored procedures + tables. Pure SQL + structured programming is simpler than objects, and way simpler than using ORMS. Of course we had no tests, so less stuff to look at. I'm not even going to describe the downsides because you all people surely know that.
My point is, let's always look at the other side of things, and really weight at all the tradeoffs. I get what you mean but when I read a line like:
> I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things.
I feel that it's really a little _naive_. I mean, of course you focus on that kind of things. You need to work on backend, solving some kind of problems. But in some other problems, like for example, visual interfaces, you better be reusing shit.
1. been there, done that. 2. been there, done that. 3. Considered that in a case where multiple systems were hitting the same database but doing inconsistent things - putting the logic in the database would at least make it consistent, but went with REST API instead to solve the problems.
I'm not entirely against code reuse, sure, reuse bits like visual interface if they fit, but the idea that it can solve everything by just sticking existing bits together is a false lead. It takes much longer than expected and it makes an unmaintainable mess.
Must know all the CSS preprocessors, all CMS's, all modern frameworks, all of software engineering, all of the server side in all languages.... Ideally has experience of everything. Must have worked Agile.
Needless to say, 7 years into my actual Web Programming career and I am resigned to being stuck in a bad role. I don't have the confidence to apply to anything since your expected to be an expert in what they announce tomorrow in the next conference (and you had to do it in your own time) and if I do, the pay is garbage.
I personally blame Recruitment Agencies for not having a clue what is being asked for, setting a false market rate (maxium commission = race to the bottom), and making the barrier to entry or even sell yourself impossible.
In short, I hope this year to re-boot my career outside of computing as pretty much everyone I know makes more money than I do.
I don't have much experience with the job market north of the border, but I'd say your situation would be atypical. I'm outside of London and have seen what you've described but the reality is that there is a shortage of people with the skills you've described in that theoretical role. I'd advise you line up 4-5 interviews and just go and see how they work out. With 7 years experience I'd expect you to be able to walk into a lot of positions without fuss which pay much much more than £19k.
Thank's for taking the time to reply Kiksy. I appreciate it as I am a lone developer and don't really have any real career advice. I just know that I never seem to match my experience to any roles and it has been a while.
Also in Edinburgh, part time an on about £10k. Mixture of front end dev, Drupal 7, Ios and Android development. Mind me asking where you work? I'm on my ast semester of uni and 3-4 years experience so isn't too bad, but the recruitment spam is crazy.
I'm curious... It could be different in Scotland but i'm a tech recruiter in the US and every company I know gets paid a % of the base salary of successfully placed developers. Our fee is 20%-25%. So it's in my best interest to get you MORE money. You get a base salary of 100K and i get 25K. You get a base salary of 19K and I get less than 5K.
The only exception is contracting where we charge a bill rate to the client and pay the developer a rate but usually people don't mind when they are making $70+ an hour.
That helps but doesn't necessarily solve the problem. There is a similar situation in real estate. The broker's main financial incentive is to ensure the deal happens.
Keep in mind, if you're getting paid a commission only after a deal happens, would you want to make a deal that day for 5% of $1mil, or wrangle for months and risk the deal to close at $1.1mil?
Now sure, 200k vs 1mil is a big deal, but that kind of difference isn't that common. Typically a recruiter would prefer to get a higher salary for you, sure, but not if it entails far more work or risking the deal.
There is, of course, reputation to consider - a real estate agent who develops a reputation of closing deals far too quickly in order to get a quick payday may start to have trouble finding clients.
I know this sort of situation too well. Lots of companies in the UK seem to want web developers, but far fewer seem to realise that it'll cost more than it does to pay someone to stack shelves.
It's especially the case in regards to agencies, jobs referred by recruiters, etc. And a lot of companies even offer this in places like London, where the rent is far higher.
I think maybe web technologies are now everywhere and where it once took a systems programmer to do certain types of things, now you're expected to do that because "JavaScript is everywhere".
The language does not make the difficult problems easy to solve.
144 comments
[ 91.5 ms ] story [ 3125 ms ] threadOver 90% of the time that prototype turns out to be good enough, either because the problem is abandoned or remains at a level where a rewrite isn't worth it.
So far I haven't regretted not investing time into learning Framework X every few years... Although I'm probably going to start deploying React instead of plain JS soon. The library is very useful for real-world UI problems, even though it's surrounded by a deafening amount of toolchain fetishism which tends to cloud React's fundamental simplicity.
(I'm 36, started writing C in 1990 and HTML in 1995, so I feel somewhat old in this industry already.)
> The library is very useful for (?) UI problems...
Components are good. But they didn't come from React and React isn't the only place to get them. Angular 1/2, Polymer, Ember are great in comparison. And so much more simple. React's position on simplicity is that the demos on the site are all 15 lines so that means it's simple right? You can't say it's complicated because it's 15 lines, see? It's "easy to reason about", i.e., "you're not smart if you don't get it".
Once you see the toolchain and ecosystem you will glimpse the price of those 15 lines.
> ...toolchain fetishism which tends to cloud React's fundamental simplicity
This is a very real thing. People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
Brevity isn't simplicity. The simplicity is being easier to install, build, read about, debug, consume APIs with, send data between, talk about to other developers... and yes, "reason" about.
Maybe I'm wrong but I feel like Angular likes to force projects to become big monoliths where people who don't understand the problem being solved are trying to architect a solution for all of the problems.
React does have jsx shock and JavaScript tooling fatigue. However, now that React is mature JavaScript tooling decision fatigue should be less of an issue. You aren't relying on one company to solve problems. You have a community solving problems for themselves. As they need it they can add it or take it away.
It's perfectly possible to just use React on its own, without getting bogged down with all the other buzzword-of-the-week stuff around it.
React itself has been reasonably stable for a long time in Web terms. It is much more tightly scoped and smaller in its interface than most JS frameworks. There are a couple of major design trade-offs, which often seem to get overlooked in React advocacy, but if you have a bit of experience using it and understand the practical pros and cons then you can quickly decide whether the balance is favourable for some new project.
People who work in React spend way more time fixing toolchain stuff and trying to mix 10 artisanal-crafted "easy to reason about" libraries in order to accomplish tasks which are either solved or not even issues in other component frameworks.
Some people who work with React might. Plenty of others don't.
When I first started with React, it felt awesome - just React still feels great. But I had just started then and then got introduced to redux (I had been using something similar custom built). That was good too, until I learnt react-redux. I get the concepts, I understand every bit of it and have used it correctly in many large apps - it is useful. But react-redux just feels awkward many times and I consistently feel something is wrong with it - but I don't know what. React-Redux just feels disconnected with the idea of independent web-components.
On a side note - If one is okay moving to Typescript, Angular2 is just amazing.
Define "meaningful".
You might want to spend some introspection time on that statement.
That's what nearly everybody does, when they're one person hacking on a one-off project.
I like to hate on Big Web Frameworks as much as anyone, but it should be understood that their value isn't replacing your hand-rolled code, their value is to let big 20-person projects avoid having 20 different flavors of hand-rolled code.
There is a difference though. When there's a big framework involved, discussion will tend towards "Is this the right way to do X in Angular?" rather than "How do we want to solve X?". That may be good or bad, depending on whether you want to build your career around being an "Angular expert" (or a "Rails expert" or "SAP expert" or "COBOL/IMS expert" or any other kind of framework expert).
https://github.com/johnpapa/angular-styleguide
We didn't need an expert.
I don't want to be hunting all over my code base just to figure out what is happening in a controller or component.
JPs styleguide is awesome!
Or we could just adopt good coding standards and build with reasonable software architecture. That's been working for longer than anything like the modern Web has existed, to build software orders of magnitude larger than any web app by any useful metric I can imagine, without the need to resort to huge frameworks to keep growing code bases organised and consistent.
Now that I think about it, the zeitgeist here really does feel like those cheesy "Learn C++ in just 20 minutes a day!!!!!" books
There seems to be a new generation of developers who think that 10,000 lines of code is a big program, a web app doesn't need to last more than a year or maybe two at most, and any sort of in-house programming or software design work will be inherently inferior to any external code you can import instead. These people are probably doomed no matter what they do.
There's a certain irony that in the one clear exception to that rule -- if you really are building a throwaway MVP in the expectation that it will either fail quickly or succeed enough be be worth rewriting properly later -- it mostly doesn't matter what tools or practices you follow. As long as you have some basic competence regarding security and you're keeping any important data somewhere safe so it can be transferred reliably to a new system later, the strategy is what it is. However, that also means many of the claimed advantages of frameworks are irrelevant to such projects, because you don't really care about things like longevity or being able to hire more developers already familiar with the framework or keeping growing teams consistent in how they design a growing code base.
This one made my day xD
10kLOC is a top limit for my programs (I say that whatever has higher line count starts boring me), and those were just small tools for sysadmins since forever.
Web frameworks have architecture to them, but their value lies in solving technical problems, not architectural ones.
I respectfully disagree. You don't need a framework to do any of those things.
I do a lot of work with relatively complicated browser-based UIs. In my experience, the DOM/layout thrashing and jank issues that have been getting a lot of attention lately only became a big deal in the first place because the early frameworks were so horrifically slow compared to just doing manual updates of exactly what you needed to change. Even in the most demanding applications -- and not many web apps actually are this demanding -- you could achieve pleasant, smooth results with some modest attention to how you applied updates so you didn't cause the browser to regenerate layout unnecessarily. (This would be an example of a useful coding standard, BTW.)
Flashes of unstyled content/text/whatever are a symptom of serving web pages in chunks and how browsers render incrementally as more of the chunks are available. Again, dealing with these effects just requires some understanding of what causes them and a little care in how your site/app is served and does its initial setup. The frameworks don't do anything magic that you can't do in your own code.
And finally, we were solving cross-browser portability problems with script repositories and then libraries like jQuery a long time before any of the modern frameworks were on the scene, and in a much more varied environment in the early days. IE has certainly had its issues over the years, but for the most part at least the issues were well known and you could just work around them. And again, there weren't really that many horrible issues, and this was an area where having some basic coding standards worked OK even if for some reason you didn't want to just use one of the many utility libraries.
If you or your company needs a basic website, then wordpress will almost always take you as far as you need to go. There's not a huge need for devs and nobody who's good at the web wants to be there because it's a race to the bottom financially. That part of the web (the overwhelming majority I might add) is pretty stagnant with few real changes or advancements having happened in the past decade.
Apps failed in that nobody wants to install your app on their device unless it's a game, a free utility, or one of a few popular apps made by large companies. WebOS got the idea of web technologies right, but the devices were too limited. Today, the idea of a web app that runs everywhere is very appealing and much more accessible to clients. All the new frameworks are really targeting this kind of use. Pounding the square that is web apps through the round hole that is the browser is hard, but still better than the alternatives.
If you're making a website, jQuery and simple JS is usually all you need. If you're making a web app with complex data and complex UI, you need a framework to keep things sane.
It's only the complex UI which requires JS frameworks and libraries, but building such a UI is already a losing proposition and the main reason why web programming is getting "unnecessarily complicated".
Web developers think that web apps can compete with native applications - they still can't and in the process of trying to get them there, they turned the process of building websites into a mess.
Only if you make a baseless assumption about the user's internet connection. Someone whose connection drops out regularly, or who faces periods without a connection at all, is going to hate your server-side app compared to my offline-first progressive web app that they can have cached on their device and that syncs their changes using pouchdb/couchdb.
My app will have a ton of JS that yours doesn't, but that extra code makes it work when they're not online. That's a huge advantage.
Not all progress is designed for added shininess. Some of the changes that are happening are designed to fix real problems that people face.
There are a lot of things that you have to do regardless of how the app is delivered - you need to work out what the app actually needs to do, you need to design the business logic, you need to design the look and feel, you need to get the UX right, you have to throughly test it. On a decent size app, the job of actually writing the code is about 25% of the work required. In my opinion, something that represents a quarter of the project probably shouldn't drive the entire process.
https://developers.google.com/web/fundamentals/getting-start...
As it is though, the API for file system access in JS might not be standard yet (and might never be) but it works well in Chrome: https://developer.mozilla.org/en-US/docs/Web/API/File_System...
If that's not the case, it's pointless to create a web-based product. Just offer the full thing as an app and a simple web UI.
I looked at the WaPo link that you posted and it seems to be exactly this type of product with an identity crysis - my browser already allows me to save pages for later reading and if that won't work, there are a multitude of offline reading apps to choose from, I don't need a WaPo "progressively enhanced" app for that.
For such an app, having a longer load upfront in order to facilitate vastly better UX than using purely server-side rendered pages is a huge win for our customers, and having the time to load & interact being low also adds tremendous value to the customers, to the point that they flock to us over our competitors.
I don't find myself having a problem with frontend web app architecture - most of the problems out there are already solved or solvable with a little time spent on thought, but the knowledge is not widespread, and so we have a lot of people who have never seen what good structure looks like.
There's always cases where it makes sense to make use of particular technologies. It absolutely does not make sense to transform most websites into web apps that are completely broken without JavaScript, which is what's happening right now.
Literally every time I update one of our sites using a Facebook SDK, they've changed around how the whole SDK is designed and I have to rewrite basic things like session management.
Let's face it, classic front-end web development works fine and is well understood. Doesn't get you into conferences or help you sell courses.
So we get the web of today, piles of Javascript and unnecessary complexity all wrapped together with ads and tracking. And excuses about how today's customers expect an app-like experience.
Yes. If anyone has evidence of this I'd love to see it.
On top of replacement, theres another question "is the common road the best road?". Something as simple as a html5 video tag can be replicated through a canvas, html5 audio and some ui elements. And as things get more complicated, are we better off pretending complexity is the enemy?
The reality is that these are problems all languages have to deal with. The reason the web is getting the most is because its the most widely consumed abd provided. Why be involved in an ecosystem dominated by coorperate entities that would only pay you just enough so you wont leave when you can be in an environment where insanity is an acceptable road to sanity. Why the hell does coffee script exist? It doesnt matter.
Also worth noting that analytics makes it easy to determine what device/OS the majority of your visitors are using. Anyone building an app would be wise to pay close attention to this to guide dev efforts.
Compare food nowadays to centuries ago, I'm glad things got unnecessarily complicated.
that's when the recipe shows up on Pinterest...
I'm just glad I don't have to hunt every day.
Callbacks, promises, generators are all there to essentially make async code sync, which seems to make the code hard to follow, difficult to scale, modularise and debug.
I think JS took this approach because of the limitation of older browsers, which were unable to use threading, so as to not block IO they forced concurrency using queues requiring async style code.
We must have just stuck with it because it's just been around for long enough and it would be hard to get everyone to change.
it's 2016 and I like being able to use the return values of my methods without sweating. PLEASE, for the love of god, replace JS with something with the same cushy syntax but makes sense.
Then again, I could just be bad at programming and not know what I am talking about - I sincerely hope that is the case.
</rant>
I think they actually do quite the opposite: they keep async code async. JavaScript doesn't really have a (non-terrible) way to make async code sync.
Note that I'm assuming that by "being able to use return values of my methods without sweating," you mean "get the thing I want out of the return type somehow." Or, in other words, things like getting a value out of a Future. The problem with that approach is that it blocks the calling thread, so what happens if you have 50 connections? Or 200? Or 10,000?
The same reason I like that JavaScript and JavaScript libraries try very hard to keep things asynchronous is the same reason highly concurrent software tends to be event based rather than thread based: it's simply more efficient.
I think it can be a challenge to keep mental track of state in JavaScript due to the nature of async stuff, but it can also be liberating in a way once you figure out the right way to pack away your state for whatever problem your working on. It makes it easy to break things into small components and reason about pieces instead of the whole while maintaining decent efficiency compared to having tons of threads around.
There's also of course the incredible niceness of JavaScript being single threaded in that typical multithreading concerns are not a problem. If you want to update a variable in some callback, you just do it. You don't have to worry about locking or atomicity, etc. I can't tell you how many times I've ended up with a mess of Java code in which I'm not actually sure if it's correct or not. That's likely my fault, but still something I enjoy getting to not think about when doing JS.
In short, I suppose it just comes down to different preferences. I often find myself working on concurrency in Java and wishing that it were more like JavaScript :). Interesting, the JavaScript approach can be pretty easily recreated in Java (and sometimes a very useful tool), but the Java approach is much harder to do in JS, at least with Node.
Big threaded reactor style designs can be, but those aren't exactly event driven.
Small events generally are the opposite of performance, increasing concurrency and synchronisation dependencies between threads.
If you meant responsiveness or latency, maybe you have a point, but current UI frameworks have been event driven since about forever.
So web programming should be more complicated because the world we now reach is far more complicated. But I don't feel like complexity has grown nearly as much as potential audience. And when things do get frustrating, such as trying to do a heavy client-side app, I just have to look at the PHP Reddit/stack overflow groups to get a reminder of how truly fucking annoying and confusing it was to build a full stack app a decade ago.
I made some boilerplate to solve this problem. If you are familiar with react, it shouldn take a few minutes of `git clone && npm i` to get started.
https://github.com/Jon-Biz/simple-static-react
There are a few version up there: one has a router, one has a firebase backend, one has Virtual Reality bindings. They all have the same purpose: to get out of your way as fast as possible.
So, I did a little bit of work to simplify my set up(s) and then to make it useful to others.
I am sort of curious if this pile of complexity will at some point implode, but mostly I am happy that I got out of webdev when I did. Today's web development is making a mockery of the ideas of usability, accessibility and standards.
When we build web apps for clients, they generally don't care what tools we use as long as the results are good. There's still plenty of work out there like this and there are still plenty of success stories.
You just have to avoid the parts of the industry, particularly around the startup scene, where most developers have just a few years of experience and are heavily influenced by high profile online commentary. That type of business tends to hire buzzword-compliant people because even their own "senior" developers don't have enough experience to know any better.
This is a great piece of advice.
Frameworks are commonly used across many programming industries. It's also not any framework's fault that the PM (or you) chose the wrong framework.
>just don't expect to be able to get a job doing that and do expect to be mocked as some sort of luddite.
I've never heard anyone mocked as a luddite for using the simplest solution necessary to meet requirements, that sounds like something programmer's are complimented for (if they can show results). If you want a job where the employer uses a trendy framework... just learn the framework; it's either that or learn the company's hand-rolled framework, at least with a trendy framework you're also investing in potential future prospects.
Starts off nice...
>Nothing is stopping you from writing for the web like it's 1991 if that's all you feel is necessary for your site.
Then you get that little jab in there.
Another factor that complicates web page development is ads. They bring a huge pile of Javascript with them, but they go ignored most of the time and usually are a burden to the user. Ad providers, instead of publishing ads that would indeed get clicked intentionally (like the Deck network), bribe the publishers paying for user actions that aren't actual impressions. Thus they also create exaggerated statistics which they use to lure low quality ads which get the most clicks from accidental behaviour, leading to worse and worse ads that do whatever to catch attention but be actually interesting.
Lastly, it is a fact that coding Javascript is more fun than writing a document. For the web developer, rendering innyeractive graphics with Javascript is certainly more fun than making them with R or gnuplot and insert into the page with an img tag and providing data and code used to generate them.
The process can be quicker or longer than that.
I for one will go against the flow (or am I with the flow?) and say that what I see coming out of Angular 2 looks FANTASTIC. Many of the things I love as a Scala developer are finally becoming mainstream on the client side. Add in the promise of NativeScript (mobile apps) and Electron (desktop apps) and this is an incredible time to be a web developer.
With that out of the way... I'm firmly in the "but" camp here. I've been doing web programming for 17 years now. I remember the bad old days. Things were simple if all you wanted was HTML and images (CSS was still pretty iffy). But the moment you needed more than a static page? The complexity of getting up and running ballooned really quickly. And worst of all there were so few resources to really learn from. And it was expensive. Granted I was a teenager back then so anything more than a few dollars a month was pricey to me, but if you compare the kinds of hosting offerings of two decades ago to something like Digital Ocean or AWS today then the amount of possibilities is staggering (no more shared environment!) and for prices that are almost too cheap to believe.
My recollection of getting anything up and running that used a database back then was that it was not for the faint of heart. Compare that to today and the process of getting everything set up and connected with Rails, Djano, Express, etc. Yes there's more stuff you "just have to know" in terms of code you write and yes you have a box you have to stay within because of the framework but I'll take that any day over gluing together some Perl scripts and hoping you've got CGI configured correctly.
Maybe I'm conflating two separate things here: actual programming and operations. But I strongly contend that with web programming you can't disentangle those two things in any practical way. You will always be bound to the context of your environment. Anything that makes getting a sane environment easier leaves much more time to focus on the problem you actually care about. And it's not like you have to use all of the shiny new toys if you want to keep your code simple.
That soon changed. In learning about programming, one can't help but to come across the writings of those preaching the gospel of the holy virtues of 'reusable code'. Modular code, libraries, object-oriented code, design patterns, frameworks, plugins, APIs, services, stacks and toolchains!
So programming is now largely about resolving a ton of dependency issues and getting scores of different modules, frameworks, libraries, APIs, etc. to play nicely with each other. Instead of using our brainpower to understand and model the domain problems that are ostensibly the reason for our software, we're using it trying to figure out how the heck to glom together all this generic abstract code and modify the output to vaguely resemble something in the domain, in a way that won't perform so horrendously that customers immediately give up on it.
We write hooks, overrides, and underrides to throw out the work that the reusable code is doing and get it to do what we want (more-or-less). We write translation and adaptation and bridge layers to convert the data structures used by one module to those used by another (and vice-versa) and eventually to something roughly approximating the domain data. We set up elaborate clusters of interdependent modules, submodules, plugins for our plugins, all on top of a generic framework that wasn't even designed with the domain in mind.
As a profession, we've gone way too overboard trying to do everything with reusable code. This is why it can take several hours to do something as simple as change a link (and that can completely break something seemingly-unrelated elsewhere in the system). And it's kind of amusing that we're now adding layers of complexity to manage the layers of complexity.
I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things. For that we need a new doctrine of vertical development that doesn't just religiously say "Throw another layer of indirection and generic abstraction on it! Yay reusable code!" as a sacred solution for everything. Sure, code reuse can be good, but let's be sensible about it, not kid-in-a-candy-store crazy.
http://qbix.com/platform
Now I can assemble a website that works everywhere and has best practices, by expressing exactly what I want in high level code. When modeling a new app or talking to our developers about architecture, we can use a common language of users, communities, streams, access, realtime pushes and offline notifications etc. People know what I mean when I say "the Patients/account streams should be published by the community and have Patients/photo stream templates for the admin role, related to Patients/gallery category stream published by the logged-in user."
Everything is namespaced, reusable, interoperable and works on every device. It took a long time to make the system but now we can assemble apps like out of building blocks, and have anyone work on anything and know what the conventions are. So yeah, it's paid off!!
Now I have some choices: allow javascript in order to read plain text, or ignore your web framework.
Guess which one I picked.
This is the often-forgotten cost of competition (for all its merits) as opposed to cooperation: it wastes time and energy.
I do not buy that this is a problem. It's not an apples-to-apples comparison, but anyone can publish a 'book' on Amazon as easily as publishing an NPM module (and they do), however, no one is complaining that there are "too many low quality books". Why is it easy to ignore books but harder to ignore shitty projects? Similarly there are countless instances of bad poetry online, and very bad fan-fiction, but the sky isn't falling in the literary world. Can someone educate me: why do other people's shitty software projects elicit such strong reactions?
They also don't purport to solve a specific problem. (Like left-pad.)
And they're not boosted by a FOSS ideology which their existence a political choice and not just a practical issue.
So basically interdependence. You need at least some external code to finish most projects, and the chances are good it will be somewhere between overcomplicated, unreliable, poorly documented, poorly maintained, and unnecessary.
Maybe package managers need active best-of-breed curation and industry-wide coding and documentation standards. But professional standards are anathema to the move-fast-and-break-things crowd, so I doubt that will ever happen.
If you want to make a comparison you can equate things to hardware where things like quality control and yield is instrumental. If you buy a plastic case that after a year self-disintegrates because while it looked the same it wasn't manufactured to spec. When this could potentially happen to every part of your device this quickly becomes annoying.
Yet, this is how software is all the time and is further worsened by a lack of due diligence and quality control. How many developers can get the time to properly verify a technology or library. Not to speak of if it's even fair to expect developers to be able to reach those conclusions.
1: http://www.nature.com/news/there-are-fewer-microbes-out-ther...
It sort of succeeded, but only at the data structure layer. Perhaps the high point of reuse is npm-style dependency-orientated programming, where people really do reuse tiny functions like leftpad(). But it's not stable. Because nobody is interested in providing that stability, and there's no money in it. There can't possibly be, because nobody will pay for tiny software components like leftpad. The market doesn't exist.
You can't second-source leftpad(), and that makes it possible for one person to break a lot of random builds across the world.
The interesting bit is that these people are often very eloquent and convincing in making others believe that they have an objectively better way to program, and that this is THE way to advance in the field, and not just some elaborate game created to stave off boredom. Never mind the fact that you're still just doing things like validating phone numbers and moving buttons slightly to the right. This is nothing less than the future of computer science!
So you end up with a herd effect where greener or less-capable developers follow these "thought leaders" blindly, resulting in the fragmentation we're in now. I find it interesting how "Five Whys" has made its way into dev culture as a line of questioning for business requirements, but never for tech requirements. "It's getting more and more popular every day," or, "It's going to look great on your resume," is often the end of the discussion.
But what is simple, really? Let's look at some past experiences:
1. At a very first gig, when I was doing my very little first steps in this software thing, I had to build a website prototype. Pure static html pages inside a folder, that were linked to each other, didn't need to deploy, it was just a demo. It didn't use CSS. It didn't use a template engine. Really simple. But, every change was a PITA, because the website had a header, so every change, meant you had to open the file, and rewrite the whole header... in all files, manually!
2. In another moment of my past, I had to do some changes in an app was built with JQuery. JQuery is a library, but it's pretty simple. Select dom elements, and apply changes and hook events up. Simple.
Only, following and understanding the flow of the app was hard as hell. Each page had a lot of code and it wasn't obvious at all what was happening. Complex transformations of the dom were daunting. Small changes would break in intractable ways.
3. PL/SQL Stored procedures + tables. Pure SQL + structured programming is simpler than objects, and way simpler than using ORMS. Of course we had no tests, so less stuff to look at. I'm not even going to describe the downsides because you all people surely know that.
My point is, let's always look at the other side of things, and really weight at all the tradeoffs. I get what you mean but when I read a line like:
> I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things.
I feel that it's really a little _naive_. I mean, of course you focus on that kind of things. You need to work on backend, solving some kind of problems. But in some other problems, like for example, visual interfaces, you better be reusing shit.
I'm not entirely against code reuse, sure, reuse bits like visual interface if they fit, but the idea that it can solve everything by just sticking existing bits together is a false lead. It takes much longer than expected and it makes an unmaintainable mess.
Seeking Junior Developer 19k.
Must know all the CSS preprocessors, all CMS's, all modern frameworks, all of software engineering, all of the server side in all languages.... Ideally has experience of everything. Must have worked Agile.
Needless to say, 7 years into my actual Web Programming career and I am resigned to being stuck in a bad role. I don't have the confidence to apply to anything since your expected to be an expert in what they announce tomorrow in the next conference (and you had to do it in your own time) and if I do, the pay is garbage.
I personally blame Recruitment Agencies for not having a clue what is being asked for, setting a false market rate (maxium commission = race to the bottom), and making the barrier to entry or even sell yourself impossible.
In short, I hope this year to re-boot my career outside of computing as pretty much everyone I know makes more money than I do.
The only exception is contracting where we charge a bill rate to the client and pay the developer a rate but usually people don't mind when they are making $70+ an hour.
Keep in mind, if you're getting paid a commission only after a deal happens, would you want to make a deal that day for 5% of $1mil, or wrangle for months and risk the deal to close at $1.1mil?
Now sure, 200k vs 1mil is a big deal, but that kind of difference isn't that common. Typically a recruiter would prefer to get a higher salary for you, sure, but not if it entails far more work or risking the deal.
There is, of course, reputation to consider - a real estate agent who develops a reputation of closing deals far too quickly in order to get a quick payday may start to have trouble finding clients.
It's especially the case in regards to agencies, jobs referred by recruiters, etc. And a lot of companies even offer this in places like London, where the rent is far higher.
The language does not make the difficult problems easy to solve.
More: http://medium.com/@velmu/on-ubiquitous-javascript-and-the-un...